Micrologix Messaging

Is there a "right" way to setup messaging between two ML1400 PLC's? Over the years we've done it several slightly different ways and usually get them to work.

We've done timers with the done bit triggering the message, we've had the done bit of one message trigger the next, we've had the error bit in parallel with the done bit, sometimes we use one-shots, and probably a dozen variations.

Does anyone have their tried and true bulletproof method they would like to share?

Largely depends on the application and how often you want to transfer the data.

this is a document for Logix 5000. page 23 is what you want to look at, you should be able to translate it for Logix 500

https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm012_-en-p.pdf

This is the most robust way to messages I have found.

Firejo said:

Largely depends on the application and how often you want to transfer the data.

Click to expand...

^ This

I segregate the messages into groups like immediate, cyclic, and on demand.
I try to avoid immediate messages, but sometimes I need both PLCs to react to an event. When I do those, I don't allow the other messages to enable unless the immediate message instructions are done/idle. Old habit from 1500s, lol
The cyclic messages I set up to run after startup and just have a loop of them with the dn bit enabling the next message.
On demand when a value changes, so basically a neq and ons to trigger the message.

For the actual line logic I've done it a bunch of different ways and never noticed a change in performance or function.
I usually just default to three branches for consistency's sake:
Event (ons, dn from previous message, etc)
XIC msg dn -- XIO msg er -- XIO msg dn
XIC msg er -- XIO msg en -- XIO msg dn

penend said:

this is a document for Logix 5000. page 23 is what you want to look at, you should be able to translate it for Logix 500

https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm012_-en-p.pdf

This is the most robust way to messages I have found.

Click to expand...

I do it similar to the above, except I never sequence the MSGs, I keep them independent with usually their own 250msec timers to keep the MSGs from firing faster than necessary to keep traffic down. The reason I don't sequence them is because I've seen some connection issues cause like 10 seconds to trigger the message to error out (.ER bit). In the case of the above logic, that one failed MSG now takes out all of your other MSGs since they are waiting for it to finish before starting themselves.

You can change the timeout of the MSG so it will not hang, its set pretty high as default.

^never noticed that... will have to check it out. Still, I've not found sequencing to be necessary with timers firing the messages individually. The other advantage is its easy to add another MSG instruction online without risking causing issues with the existing ones if you keep them separate and not sequenced.

Also, even if you set the timeout value low with it sequenced, one failed MSG is still holding up the rest, even if just slightly, and repeatedly until the connection is fixed. May or may not be a problem, but something that comes to mind.