I/O modules not responding blinking on Compactlogix L32C

[qwemx]

I have been having this error on the CPU Compactlogix L32Cwhich says that
I/O are not responding . I checked in the minor faults and cleared everything however I am unable to find out which I/O it is that is not responding and how can it be fixed.

https://www.dropbox.com/sh/1rq6j52j460tpgk/AAA4xtWXBreieVv1AP53pM8ya?dl=0

 

[Yacineg]

I noticed that you are in the program mode. What happens when you change to run mode? Is the I/O local or remote?

Have you checked in the I/O tree?

The I/O tree will show the exact I/O not responding with a small yellow triangle.

 

[Ken Roach]

Thanks for those photos and screenshots !

All of the I/O for that CompactLogix is remote from the chassis, connected on ControlNet.

The browse you showed in RSLinx Classic shows 11 remote network modules, a mix of FLEX and POINT I/O platforms, connected to that ControlNet segment.

You need to more carefully examine the "I/O tree" section in RSLogix 5000 while online to see if there are indications of which modules are not communicating. Maybe it's all of them, maybe it's just one or two. There will be a more detailed error code and an icon indicating the module(s) that are not communicating.

I noticed the presence of another CompactLogix, and the word "backup" in the program. Are both controllers intended to run at the same time, or is one a "cold backup" to be turned on if the other fails ?

 

[qwemx]

I noticed the presence of another CompactLogix, and the word "backup" in the program. Are both controllers intended to run at the same time, or is one a "cold backup" to be turned on if the other fails ?

There are two controllers- only one will run at a time. Last time when I checked in the I/O tree - There was a small yellow triangle but it will vanish and appear on another module and then I could not find it anymore - when it was not visible anymore I could not investigate more.

 

[Ken Roach]

Intermittent faults that move around between nodes... sounds like damaged ControlNet cables.

There are some diagnostic counters available for those interfaces, and some specialized diagnostic equipment too.

At the minimum, you should set up logic in the program to capture failures of those connections using a GSV instruction to examine the EntryStatus of the Module object, to figure out exactly which devices are faulting and how often.

 

[TheWaterboy]

You didn't show the IO rack but poor placement of the Power Supply in a long rack of IO modules can do this. Don't know if that applies here but thought it worth mentioning

 

[thefatcontroller]

The IO not responding indicator can means that something configured in the connections is not communication or not present.
As others pointed out, you expand the "I/O Configuration" section, any issues should be highlighted with the error symbol.
ControlNet can be tricky to diagnose problems. Probably termination or power supply issues. You may need to check RSNetworx to find issues.
And the GSV Module status is a good idea to capture faults for each module on comms. Paste the below logic in a rung. "ModuleReference" is the actual module. I have this logic in AOI with ModuleReference InOut Type "Module". "ModuleEntryStatus" Type INT.

GSV(Module,ModuleReference,EntryStatus,ModuleEntryStatus); MEQ(ModuleEntryStatus,61440,16384)[TON(LinkActive_Tm,?,?),XIC(LinkActive_Tm.DN)OTE(LinkActive)];
XIO(LinkActive)[MOV(CommFlt_Time_ms,Alarm_Tm.PRE) TON(Alarm_Tm,?,?),XIC(Alarm_Tm.DN)OTE(Alm_CommFlt)];