Allen bradley PLC MSG help

heatfireash

Member
Join Date
Jul 2015
Location
PA
Posts
7
I have a network with 4 PLCs PLC1 is controllogix and PLCs 2-4 are compactlogix and they all need to communicate. The current way I have this setup is PLC 2 has 2 MSG instructions set by timers to message PLC 1, about once a second. PLC 3 and 4 are setup the same way. I'm having issues with periods of data not being updated on PLC1. I thought doing it this way would be okay using ethernet as these messages don't contain much data (2o int array) but maybe all the messages are overloading PLC1s buffer? Is my best solution just to do all the ethernet messageing from PLC1 instead of having the other PLCs do it?
 
Last edited:
Do you have the messages executing with simple repeater logic (basically re-triggering every time they complete) or do you use a simple timer to re-trigger them once every X milliseconds ?

The other mechanism for exchanging data among these controllers is "Produced / Consumed Tags". PLC1 can set up an array or UDT of data to be consumed by all three other controllers, and each of them can also set up an array or UDT of data to be consumed by PLC1. All the exchange is done at I/O speeds using I/O protocols and I/O subsystem resources.
 
A rule of thumb is to only use read messages. This isn't set in stone, the goal is to make it possible to determine where a tag is being modified -- with writes, the modifying code is harder to track down; especially with multiple controllers.
 
A rule of thumb is to only use read messages. This isn't set in stone, the goal is to make it possible to determine where a tag is being modified -- with writes, the modifying code is harder to track down; especially with multiple controllers.
I understand that, I guess I'm still just surprised that this is causing random 1min drop outs without updating data. Maybe thats just why best practices are best practices?
 
Using writes rather than reads is not causing the issue. Having them repeat every second regardless of the outcome of prior attempts might be leading to issues, although what you are doing is very reasonable.

You might want to wait for a DN or ER bit from each MSG before resetting its timer. I would also inspect the MSG to see whether it is set up as an unconnected message in which case, you can edit the UnconnectedTimeout value (in microseconds) so it doesn't wait forever to generate the ER bit. If the MSG is going to succeed, its likely to happen in less than a second.
 
Thanks for the screenshot and explanation. Most Logix PLCs are certainly able to handle two messages from three peer devices on average every 1.2 seconds, so it's *unlikely* that you're running out of buffers or bandwidth. Obviously I can't tell how heavily loaded your controllers are on memory and utilization.

If I were troubleshooting this system, I would probably take two initial approaches.

The first is to figure out what kind of failure is happening from the perspective of the PLC2, PLC3 and PLC4 controllers that are initiating the messages. That means capturing the .ER bit, and the .ERR and .EXERR codes in logic. Sometimes I put them into an array with a timestamp, sometimes I send them to an alarming subsystem (like with ALMD and PanelView 5000), sometimes I just use a counter and come back to look at it frequently.

And I would try to use the receiving controller a role in the diagnostics too. I would add another element to the data block you're sending to PLC1 and make that a Watchdog value that increments by one every time the MSG is sent, or even one that contains a timestamp. Then logic in the receiving controller can monitor that value to see exactly how long the data goes without being updated, and precisely when it occurs.

My colleague OkiePC mentioned a couple of other things you could do with this logic, including setting the Unconnected Message Timeout value to something less than its 30 second default, or checking the box to be sure you're using a Connected message. You can also add a manual timeout timer; if the .EN bit is true (but the /DN and /ER bits are both false) for X milliseconds, the timer manually sets the .TO bit for the MSG control block, which has the same effect as the MSG naturally timing out because it didn't get an acknowledgement from the other controller.

You might have a noisy network. You might have a bad network cable. You might have a switch that's connected to a power supply that browns out every time the main compressor comes on at the same time as more than one microwave in the lunchroom but that comes right back up as soon as the burrito is warm and the accumulator tank is back up above 90 PSI.
 

Similar Topics

Hello, I am new here. I am trying to find good places to sell some surplus items that I have that isnt through ebay. Does anyone have any sources...
Replies
6
Views
427
Hi good day Everyone, I have a cimplicity v10 project with 7 to 8k tags communicating with AB PLC through OPC and Rslinx classic. I have this...
Replies
3
Views
219
I am using Allen Bradley PLC 1756-L81E and EIP module 1756-EN2TR for Ethernet/IP communication. My communication works fine but in Get-Attribute...
Replies
2
Views
203
Hi Everyone, I am currently trying to communicate ControlLogix PLCs via EtherNet/IP with Delta V DCS. There is a VIM2 card configured for...
Replies
1
Views
281
Hi everyone. I have an issue with an Allen Bradley PLC model 1769-L30ER. This PLC had a previous program with a different IP address but when I...
Replies
4
Views
525
Back
Top Bottom