That's nice and clean. Only downside I see is that if the local PLC is doing a read for the heartbeat bit (instead of the remote PLC writing to it), it may still show a high heartbeat bit if the remote PLC was not in run mode. Unless I'm missing something.
Sounds like you might. One, you should always do reads, a lot easier to troubleshoot. Two, if the remote PLC isn't running then the heartbeat will not transition, that's what heartbeat means. If you don't have a transition in the time the timer is set for, it will time out. A timeout is loss of comms.
Sounds like you might. One, you should always do reads, a lot easier to troubleshoot. Two, if the remote PLC isn't running then the heartbeat will not transition, that's what heartbeat means. If you don't have a transition in the time the timer is set for, it will time out. A timeout is loss of comms.
If the local PLC is reading the "heartbeat bit" and the remote PLC faults after setting its heartbeat bit, what keeps the local PLC from always reading a high bit from the faulted PLC and resetting the timer?
I misspoke, I typically use a one shot, not the unlatch. It depends on how you manage the data, if you use a message, then it's probably best to use a one shot. But, by using a one shot, it doesn't matter if it's stuck high. It has to see transition.
The statement "PLC manufacturers don't have an inbuilt health status between networked PLC's in the config options." is not true.
Rockwell have connection status in controllogix platform in Prod/Cons. The older SLC use Message have message.ER bit, which in my opinion is sufficient.
Obviously, you can add additional check logic as needed.
I agree with this approach. It doesn't require additional logic. If the message instruction cannot connect, the error bit will go high, meaning communication has stopped for whatever reason. A timer is needed to trigger the msg, of course.