Logix 5000 MSG Best Practices / Discussion

[AMarks95]

What's the best way to use lots of MSG instructions in the same program? Both multiple messages with the same device, and other devices. I've read the manual a bit and I think I have a decent understanding of the Connected/Cached Connections. Basically, if you have multiple messages with the same device you want to only have one active per scan, and use the Connected/Cached Connection option to keep the connection open between messages. You can also have up to 32 open connections with different devices (in general, with modern hardware. I think this is actually hardware dependent).

What I've seen in some programs is a super short timer (100ms) with the EN rung consisting of an XIC(MSG.EN) for each MSG instruction used. Then, a CTU every time the timer elapses, and each MSG instruction has an index, in addition to the XIC(MSG.EN). Like so:

https://imgur.com/a/i6LuNjL

My only issue with that approach is that the TON rung becomes super long and has to be maintained as messages are added/removed, as well as the CTU preset.

I tested another method the other day, and it seems to work. Instead of using a counter and an index, the next message, just references the previous message. As soon as one is done, it moves on to the next one, and then eventually restarts when it gets to the end of the list. Like so:

https://imgur.com/a/lgPKKTZ

This way, each message has it's own line that's identical, there's no timer so the MSGs execute as fast as possible, adding a message to the end is relatively simple and intuitive, removing a message is not too bad either.

Does anybody have thoughts on the pros/cons of each? Any other approaches people use?

 

[JeremyM]

XIO Msg.EN is the minimum you need to message reliably.

You can add timers to respect specific remote endpoint limitations. Namely, some PowerMonitor models will only respond on 200ms message intervals.

Messaging local controller objects are pretty much asynchronous service calls. No timers are needed.

That’s basically it for one-off messaging.

Now, there’s more complicated messaging that can be done, particularly when it comes to the Socket services. You’ll need a general sequence and control flow when things don’t go your way. What if SocketCreate fails, for example?

In general, I have had nothing less than success when setting up messaging with the following patterns:

Ladder:

XIO Msg.EN MSG(Msg)

XIC SomeCondition XIO Msg.EN MSG(Msg)

ST:

if (SomeCondition & (Msg.DN OR Msg.ER OR NOT Msg.EN)) then
   MSG(Msg);
end_if;

In ST, the Msg.EN bit is set after its first call and remains set. So the “OR NOT Msg.EN” exists to handle the initial condition. Everything that happens after MSG() is either Msg.DN or Msg.ER.

 

[AMarks95]

I think that's ok for a limited number of messages, but will network performance degrade as more messages are added? Also, with that approach, if there are multiple messages to the same device, you don't take advantage of the cached connection ability.

 

[JeremyM]

Network performance where? On the controller? On a switch? The device?

You can measure 5x80 controller MSG impact on its Tasks webpage. Modern switch port utilization for IO and message traffic together will barely register a blip.

Devices are basically case-by-case, but I generally send no more than one or two messages at a time to each; to expand on that, most messaging is cyclic reading, but on occasion during all that, you’ll have an updated parameter to send to the device.

I try to encapsulate as much return data as possible in a message response. Generally, CIP packets are ~500 bytes in size, so anything up to that is going to have the same impact, whether it’s 1 byte or 500 bytes returned.

That part should inform what CIP service you prefer first. GetAttributesAll or iterative GetAttributeSingle?

 

[JeremyM]

I think that's ok for a limited number of messages, but will network performance degrade as more messages are added? Also, with that approach, if there are multiple messages to the same device, you don't take advantage of the cached connection ability.

I cannot recall an instance when I manually cached a connection on a 5x70 or 5x80.

 

[OkiePC]

Things to consider:
1. If you use the super simple enable the MSG every time it isn't enabled, you will bombard the recipient as fast as you can and some recipients won't like it.

2. If your connection to the device is broken and the MSG waits for the ER bit before moving on to the next step, you're likely to be waiting a while depending on what port you are using and the value of the Your_MSG_Element.UnconnectedTimeout.

3. If you have a situation where you are polling multiple devices and one of them needs to be skipped for some valid reason, what do you do?

 

[JeremyM]

Agreed with OkiePC.

For points 2-3, the boolean result of a GSV for a Module’s EntryStatus can directly inform your message logic:

   XIC Sts_Connected XIO Msg.EN MSG(Msg)

 

[AMarks95]

Things to consider:
1. If you use the super simple enable the MSG every time it isn't enabled, you will bombard the recipient as fast as you can and some recipients won't like it.

2. If your connection to the device is broken and the MSG waits for the ER bit before moving on to the next step, you're likely to be waiting a while depending on what port you are using and the value of the Your_MSG_Element.UnconnectedTimeout.

3. If you have a situation where you are polling multiple devices and one of them needs to be skipped for some valid reason, what do you do?

All fair points, and they all point to using the timer method to move between messages. Sure, you're not cycling through all of the messages as fast as possible, so there will be some added delay, but I think the added reliability and robustness is probably worth it.

I can also modify it slightly and map the EN flags of the messages to the bits of a DINT (or LINT) and just use EQU(0) instead of checking each bit individually.
In addition, create a temp counter that starts at 0 each scan and just add one to that tag for each rung that has a MSG instruction.

https://imgur.com/a/F2oP541

 

[AMarks95]

https://imgur.com/a/F2oP541

One small edit that is not reflected in the screenshot, the TON also needs an "OR" MSG_TON.TT and not MSG_TON.DN so that the timer is allowed to elapse after each MSG and resets itself.

 

[5618]

Here's the start and end of some message sequencing I did that turned out pretty nice. I skipped some repeated structure rungs in the middle. This is for wireless radios to roof units. Each unit has a write message and a read message of DINT arrays. If the write message succeeds, we do the read message. If it's not connecting, a timeout moves the sequence on to the next unit. WriteTrigger fires when changing settings so we don't have to wait for the next sequence to update the HMI.

In the code, the rung structure repeats from the second unit to whatever is the last unit. The number of units varies among radios, so the last used MRx.Stage.# varies for different message counts.

Occasionally, radios lock up until a power cycle. That happens much less with decent sequencing than it did with the horrible pile of expletive provided by the vendor. Now I fire a relay automatically to cycle power.

An earlier, slightly less refined version of this would stop working with no reason found in V30. The logic would just hang and look like it should be working, but stuff wasn't changing. I don't recall all the details. Flashing to 32.14 fixed it. I don't think it was the recently announced online edit downloaded problem. It would be working for a while, then one day I would find it hung. That's the motivation for the powers unknown reset.

 

[PCMusicGuy]

Just be careful with lots of MSG instructions and their error handling. If you have a ton of them failing and retrying, it can lead to some very slow and/or odd behavior in the PLC, especially when only using continuous tasks and sockets or with a ton of data traffic instantiated by an external module. The PLC has an internal message queuing system that we've been able to overwhelm on a number of projects. There are ways to increase the depth of this queue, but I've not found any way to actually monitor how close we are to its limit.