This is not a good idea. One of my customers got bit by doing this. It turned out the watch dog routine in the PLC was timing out because it didn't see the bit change. The problem turned out to be the PLC was polling the bit synchronously to the bit changing off then back on so the PLC did not see the bit go off.Watch dog pulse between two devices.
It is best to increment a integer and check to see if the integer changes.
This is my preference too, the kicker being that if the third party system I'm interfacing has someone stubborn and not open to make a rolling counter, I don't have to change my logic to match his code.
I'll keep incrementing and point him to the LSB.
I prefer to use a "bit-chase"....
In PLC1....
XIC PLC2_Bit OTE PLC1_Bit
In PLC2....
XIO PLC1_Bit OTE PLC2_Bit
The bits will just keep on toggling, at the comms rate. It is easy to use a simple grace timer in both PLCs if it ever stops.
Doesn't this put you in a similar situation highlighted by Peter N.? Though with a small chance of happening?
Not at all - the bits have to keep toggling, because of the XIO inversion in one PLC - either will do.
It can't get synchronous, because there's no inherent timer. If the bits stop toggling, the message instructions aren't working, for whatever reason - eg. PLC Died, in Program Mode, Powered Down, etc., or the comms system is "broken" in some way.
Daba - that was my standard also for precisely the same reasons. Each end had two timers one enabled by the on condition and the other by the off condition. Preset of each to a reasonable time, 2 seconds for example. If either times out the communications have stopped.
In my limited knowledge of Rockwell stuff and how the data update works, it is possible that the data is updated and the code hasn't run... unlike situations where the data is read at the beginning of the cycle and written at the end.
Obviously these would be quite limited and you had to go out of your way to make it happen, but there's a potential for it, no?
Or am I completely wrong?