Communication loss in REmote IO PLC-5

We are still facing a problem regarding communication loss in PLC-5/40L with 1771-ASB Adaptors (8 chassis and with single slot addressing we have racks 2 to 17 in REmote IOs) as described below



NATURE OF PROBLEM

1- The systems goes to faulted state frequently

2- The major error code we receive is S:12=83 “Watchdog timer error”. And the bits S11 gets status 0000-0001-0000-0000 (this inidicates only watchdog timer error)

3- All the Remote IO communication module loss communication as soon as this fault occurs.

4- This fault is removed as soon as we recycle the power.



TROUBLESHOOTING ACTIVITES DONE:



1- The scan time of PLC-5 was increased from 500ms to maximum (due to this frequency of fault has decreased but it’s still there).



2- The fault routine was developed in which as soon as this fault occurs the system goes to this fault routine and find the status of error . If error code matches the fault code 83

The system removes the fault . Due to this now as soon as this fault comes the PLC don’t go in fault state but the Remote IOs goes in non-responding state again. This is

recovered at once only by recycling power.



3- All the Remote IO cables were checked and if there was some error in cables then the system must not get OK at once after power up.



4- The configuration of Remote IO adaptors is changed from manual startup to Auto Startup after fault.

But still the problem is same. Is there any remedy for it?

can i have an expert's view???

You have an infinite loop in the program which is causing the watchdog to time out. Once in the loop, I/O is no longer serviced.

Dous is probably correct. If you can post the logic, we can probably help you find it.

You should search the whole file for JMP and label instructions to find out if you are conditionally jumping backward causing a loop...

It doesn'y have to be an infinite loop in the case of a PLC, just a loop that prevents the program from ending for a duration greater than your watchdog setting.

Paul

Also, if there are any DII instructions, make sure they are not on a block-transfer module. (been there, done that, have the tee-shirt)

Now the nature of problem is like that
1- After several hours suddenly in last racks of Remote IO 1771-ASB adaptors shows all LED OFF (means no communication). Other 1771-ASB adaptors have ACTIVE LED blinking

2- If we just recirculate power of any one of them (not of PLC only chassis power supply of any one rack) the REmote IO network gets ok at once and all the IO data gets the same as before

3- Now i have increased the watchdog time........PLC dont go into fault any more,,only that Remote IO network link drops once in 8 to 10 hours. As soon as i recirculate chassis power of any one of the Adaptors with NO LED blinking , my network gets OK (as PLC is not faulted so the Remote IOs gets same status as before).

4- It seems some REmote IO date traffic problem. Do we have to ground the shield of 1770-CD belden twisted pair cable???

Is there any other cause of it

OkiePC ...how to upload logic here???can u give me link of ur email adress?

Check to see if your logic has file move instructions where maybe the length of the file move was inadvertently changed. I have seen in the past where the length of a file got changed from 3 to 999 and since there was enough memory available in the data table after the file in question the PLC-5 moved 999 words instead of 3 and wrote over the files following without faulting. Some of those files happened to be the configuration files for the PLC-5 channels where the I/O racks were connected. Everything was fine until that one file move instruction was energized and overwrote the I/O files. The racks were then dead like you describe with no communication light until we cycled power, then all was OK again. Took several hours to find that one, of course in the middle of a production day.

If this is a timeout problem, it can be proven, one way or the other, by examining S:77, the infamous 'time slice additive' register.

A CLUE!
The fact that the poster is asking about the shield on the remote I/O is an indication that perhaps there are wiring issues here.
Eeryone who has used AB Remote I/O knows that the termination of the entire network is very critical, and that Rockwell's recommendations must be followed, regardless of whether you agree with them or not. This includes the number and locations of the end-of-line resistors, etc. MANY an installation has be plagued by open shields on the RIO cables. Don't forget that environment counts as well...is it possible to check the cables, end-to-end for continuity?

Not mentioned, but certainly of interest to those here, would be the powerful questions: "What event preceeded all these problems? What was the system condition the last time it all worked well? What has changed?"

No move instruction like this i have checked

Well yes i have changed the routing of Remote IO cable and have put another terminal resistances (its 82 ohm in 230 KPS speed) ,.,
u aske me the last situation before this hpppes..........this happens very irregularly and sudden ........every thing is working fine......we run the plant production for sevral hours (by activating all the functions of line) and then in the middle of it it trips..there is certainly not an IO value causing it
Well after reading Remote IO cabling i have done few amendments......also i have changed IO status file of PLC-5 (it could be corrupted) now the plant is running fine for last 16 hours.....lets c its solved yet or not