Logix 5000 MSG - Detect Local/Remote Changes

[AMarks95]

Hello everybody,

I have a vendor system that has some remote monitoring (read only) and remote control (read/write) data that is available via MSG instructions. I've got the reads down for all of this data, but I'm having a hard time trying to figure out how to detect the difference between local setpoint changes and remote setpoint changes. If I compare the local and remote setpoint and they're different, how do I decide which one has changed?

 

[AMarks95]

I was messing with this a bit on my own and found something that works rather well.

I have a UDT that all of the data is reading into from the MSG instruction(s). I added a "to_Write" and a "to_Write_Last" member for each setpoint that is able to be set remotely, as well as a "write_required" member. This required me to edit my UDT COP instructions to start at the first member and use a length equal to only the read data (first 35 elements), rather than just use the entire UDT with a length of 1.


Then, I have logic to check the to_Write vs the setpoint read from the MSG instruction, after the read has completed. If they're different, the to_Write is checked vs the to_Write_Last to determine if it was local or remote that changed. If it was a local change (i.e. to_Write and to_Write_Last are equal), simply update the to_Write tag. If it was a remote change (i.e. to_Write is not equal to to_Write_Last), set the write_required flag.

If write is required, write the CIP message. Un-set the write_required flag only once the read and to_Write setpoints are all equal. Also, update the to_Write_Last value once the read has been done, and a write is not required.

Would love to hear any other approaches people have used.

 

[TheWaterboy]

That is the "Two Generals" problem and I have never found a good enough solution when the latency is high like over Radio link.
Read from remote, compare to local, overwrite local if changed, then write to remote was the method I used.

 

[AMarks95]

That's what I'll end up using, and the local value on the display will just connect to the same data value as read from remote. Basically, read and write back what was read, every time, regardless of changes. Then a change at the local behaves exactly as if it was made at the remote location. Just have to catch it at the right time

 

[TheWaterboy]

THATS the issue, its always a logic race. But its a RARE occurrence so tolerate it... it's not good juju but haven't found a better way.

 

[OkiePC]

At each end of the setpoint data loop, use the outgoing value for HMI display and entry and with the PLC logic. This way, if comms are completely broken at least you are controlling what you can with each HMI at each location.

At each PLC, check the incoming data against a reference and if different, then write it to the outgoing data (and the reference).

That basic strategy works unless you get a failed message (common with radio links) where you can get into a race situation where the incoming data and the outgoing data are both changing at both ends. This can also happen if you have two people editing the same setpoint to different values at both ends within the same poll cycle.

To mitigate (not totally eliminate) that problem, only run the logic that updates the working setpoints (outbound data) immediately after a successful message completes. I typically begin these blocks of data with a "heartbeat" value that is a copy of the free running clock. The receiving PLC can tell based on a change in that number that the data has arrived and can be assured that the PLC it came from is in RUN mode.

 

[TheWaterboy]

Ahh but a successful send does not equal a successful receive which is at the root of the 2 Generals problem. Even multiple back and forth to ensure completion doesn't work because you never know that the last message arrived.

 

[OkiePC]

Ahh but a successful send does not equal a successful receive which is at the root of the 2 Generals problem. Even multiple back and forth to ensure completion doesn't work because you never know that the last message arrived.

The recipient is watching for the heartbeat to change which does prove a successful receive, and the sending PLC doesn't have to care because it, too, is waiting for the heartbeat from the other PLC before taking action on any changed setpoints it receives back.

You can still get in a race condition if the right sequence of setpoint changes combined with failed messages occurs but it will be much less likely.