RSLogix5000"s MSG instruction

[unsaint32]

My question is regarding RSLogix5000"s MSG instruction.

I am an automation tech. Our "Start_Command" bit turns on a motor. At one point, the motor was turning on without anybody triggering the Start_Command bit.

It turns out, the "Start_Command" bit was a destination element of a MSG instruction from another PLC... incorrect IP address issue.

By looking at the PLC project, was there a way for me to tell the bit was being written by another PLC through the MSG instruction?

 

[harryting]

No.

This is why it's best practice, when possible, to do a MSG read instead of MSG write. If this MSG write can't be avoided, one can also name the tag in more descriptive fashion: DATA_FROM_OTHER_PLC[0]

 

[ASF]

Harryting is spot on. Whenever I do comms in any capacity, I read instead of write wherever possible, and always buffer the data at both ends using tags named CommsIn_From_xxx and CommsOut_To_xxx. Then I use XIC-OTE or COP instructions to copy it to the regular tags. Makes it infinitely easier to trace.

Doesn't help you with pre-existing, bad-practice code, unfortunately!

 

[MichaelG]

I agree with the Read for however this is not the most effective use of the network bandwidth
When the network bandwidth is a limit then it is better to use event driven (Change of state) writes

 

[RonJohn]

and always buffer the data at both ends

+1

 

[unsaint32]

I can't believe this is allowed. What could be the idea behind allowing for a tag to be written by another PLC and the tag having no indication of that. Sounds extremely dangerous.

Someone should submit an IEC standard request to make this illegal.

Thank you for all replies.

 

[Tharon]

I can't believe this is allowed. What could be the idea behind allowing for a tag to be written by another PLC and the tag having no indication of that. Sounds extremely dangerous.

Someone should submit an IEC standard request to make this illegal.

Thank you for all replies.

There is nothing inherently more dangerous about that than any other method of control.

This is why Safety circuits and control circuits are for the most part two separate things (excluding larger Safety PLC systems, in which they are combined). If it's unsafe for a PLC to turn something on, then it should never be able to happen, even if the PLC is trying. This is where proper risk analysis and safety level selection comes into play.

No.

This is why it's best practice, when possible, to do a MSG read instead of MSG write. If this MSG write can't be avoided, one can also name the tag in more descriptive fashion: DATA_FROM_OTHER_PLC[0]

On my systems where I need to have MSG instructions, I usually choose a central controller as the "brains" and have it Read/Write to each other controller. I have "Data_To_Controller_X[0]" and "Data_From_Controller_X[0]" Arrays. I find it easier to handle when only one controller is handling the MSGs, rather than having them divided up all over the place.

Tags and data files are named and commented accordingly.

Much like the usage of Set/Reset/Latch/Unlatch, poor programming practices shouldn't force you to limit your controller tool sets. The tools are there, and can be used properly.

 

[unsaint32]

There is nothing inherently more dangerous about that than any other method of control.

I was thinking it would make it safer to have a certain indication that a tag is a destination of a MSG instruction, for the same reason a forced output is indicated in red.

 

[Epy]

I can't believe this is allowed. What could be the idea behind allowing for a tag to be written by another PLC and the tag having no indication of that. Sounds extremely dangerous.

Someone should submit an IEC standard request to make this illegal.

Thank you for all replies.

Lol. I've always thought it was kind of dumb to by default make all tags R/W for anything that accesses the PLC. Not just AB either, that's pretty standard...

 

[AustralIan]

There's no way to flag this that I know of.
If you suspect something is writing to an address, you can narrow it down to a list of suspects by navigating to the webpage of your ethernet card and showing a list of connections.

Aside: Does someone want to opensource a deep packet inspection tool that generates a table of what data is being sent between which controllers / PCs on a network?