I have 1756-ENBT/A card on a controllogix chasis (with a 1756-L62) messaging with a bunch of other PLC's in the plant. It has been running fine for years but lately been having big problems with communication. The ControlLogix is reading and writing to SLC 5/05's and reading from them too. Also the same SLC 5/05 are writing to and reading from this controllogix processor. While there is no communication problems with the SLC's reading and writing to the ControlLogix, the read and write MSG Instruction in the ControlLogix to the SLCs keeps on giving an error. The Error code (0001-- 0204 Unconnected message timeout). I looked at the 1756-ENBT/A card in the I/O config of the controlLogix and found that the under the module info tab the Internal State is not run mode, it says intead (16#0060) unknown. Also under the port configuration tab it comes up with module not found. Its very weird because I can go online with the controller, its talking to the SLCs and HMI, all the LED's on the 1756-ENBT/A are green. I have attached screen shots of the ENBT. may be some kind soul can help me out here
Any time I see the word "bunch" used with any kind of AB msg instruction I get nervous.
There is limited space in the message queue, and limited numbers of connections available in the comm card itself.
you might want to see if you can reduce the number of messages that are active simultaneously.
most people either run the msgs in continuous mode, or constantly cycle them on and off. this generally results in the fastest updates, but does nothing to deal with potential full queue issues.
I usually program the msg instructions so the message done bit of one triggers the next msg instruction if I have a lot of msgs.
Incidentally, with ethernet msg instructions, I believe the done bit only means the message has been sent. unlike with DH+ and DH485 where the done bit comes on after the remote station has acknowledged receipt of the message. Its generally a good idea to have some kind of feedback when you are writing to a remote station, like a heartbeat counter to make sure it is really being received. I usually just write a free running timer accum value out and read it back. the difference in time of this value between successive reads tells me how long the communication scan time is, and if the value does not change I know there was a missed message.