I had each slave PLC move the clock time value for seconds into a register in the read data. If the master saw the same value in that register after three data reads it would trip an alarm.
Also the way I do it.
I had each slave PLC move the clock time value for seconds into a register in the read data. If the master saw the same value in that register after three data reads it would trip an alarm.
I seem to recall being able to successfully send MSG read and MSG write instructions to Rockwell PLCs that are not in run mode. Am I remembering wrong?Definitely not for messaging, the PLCs need to be in RUN or Remote RUN.
I seem to recall being able to successfully send MSG read and MSG write instructions to Rockwell PLCs that are not in run mode. Am I remembering wrong?
The PLC executing the MSG obviously wouldn't be able to do anything if the PLC was in PGM mode, but the target PLC would respond regardless of what mode it is in. Communications takes place regardless, just no logic executes.
The PLC executing the MSG obviously wouldn't be able to do anything if the PLC was in PGM mode, but the target PLC would respond regardless of what mode it is in. Communications takes place regardless, just no logic executes.
The PLC executing the MSG obviously wouldn't be able to do anything if the PLC was in PGM mode, but the target PLC would respond regardless of what mode it is in. Communications takes place regardless, just no logic executes.
This gave me the idea to test whether a controller’s Wallclock object remains active in any mode. If so, then controllers can just read each other’s elapsed milli/micro-second counters. I’ll see if I can conjure an answer from a Logix platform.
This gave me the idea to test whether a controller’s Wallclock object remains active in any mode. If so, then controllers can just read each other’s elapsed milli/micro-second counters. I’ll see if I can conjure an answer from a Logix platform.
The Wallclock is an OS task that is always active. The problem is that no-one else can read its data.
To date there is no way a third-party can see it - perhaps it will come...
Message the unit’s Wallclock object directly. It’s just a CIP object, after all.
Not a documented class number, that I've seen. Would you happen to know? And can share? (Attribute #'s too, please?)