I/o Not Responding

I am working on Allen Bradely PLC 5000 (RSLogix 5000).
If I see "I/O not responding" blinking (green light), what can cause this happen? Please answer me with all possibility even extremely low possibility.
Thanks.

The most common reason, is the processor has a communications module configured in the I/O configuration tree, that has no actual I/O attached.

Most commonly, would be an Ethernet module. If it's only there for comms, it should not be in the I/O tree. Other comms gateway modules can do the same, DHRIO, CNB, anything that doesn't actually have physical I/O on it.

rdrast has it, but while online with the PLC look in the I/O tree, the offending module should have a yellow triangle over it.

i/o not responding error

Have 5 1756-L72S GuardLogix 5570 Safety Controllers on independent machines in one room. Using Stratix wireless access points. Wanting to produce/consume bits back and forth.
1. Do I add the other PLCs under the WAP on the I/O tree?
2. I have added the other PLCs under the EN2T module, but I get intermittent I/O Not Responding Error.
3. I can pass a bit back and forth, but not reliably and with various delay.

What should I try please?

wireless access points. Wanting to produce/consume bits back and forth.

Click to expand...

Go find whomever told you this was a good idea.

Slap them in the face.

The come back and create another thread that describes exactly your switch and wireless architecture and folks might be able to suggest some configuration and troubleshooting tips.

Edit: I'm kidding, a little. Wireless is notorious for dropping packets and being unreliable. The first thing you have to do is find out if your wireless system is carrying floods of safety or I/O data that it doesn't have to, and that's going to take some protocol analysis. We should first decouple it from this fossilized thread and consider the technologies and techniques from a fresh start.

LOL @ "Slap them in the face". Ok, will start a fresh thread (if I can figure out how).

Produce/Consume wirelessly generally isn’t a good idea as Ken was not so subtly alluding to. However it might be possible to reduce the number of dropouts (and even maybe eliminate them all together) by increasing the RPI’s for the consumed tag. I’d change it (the RPI) to as long as possible and as long as the application will tolerate. Having said that given that it’s a safety controller that might not be a good idea and you might be looking at getting all of the needed equipment onto a LAN (hard wired).