Heart beat signal

[Phrog30]

KISS

1 PLC has a 10 sec timer, 1 plc resets it. If .dn then you have lost comms.

+1.

The previous example, while it may work, is a bit much.

 

[rupej]

KISS

1 PLC has a 10 sec timer, 1 plc resets it. If .dn then you have lost comms.

But that doesn't work if comms fail when the "reset" bit is high- it would get stuck and keep resetting the timer. A bit more complexity is needed.

 

[Phrog30]

But that doesn't work if comms fail when the "reset" bit is high- it would get stuck and keep resetting the timer. A bit more complexity is needed.

One shot or immediately clear. He didn't specify in his example, so good point. Even with the one shot it's still simple.

 

[JTCat]

One shot or immediately clear. He didn't specify in his example, so good point. Even with the one shot it's still simple.

Can you build and paste an example?

 

[pturmel]

I generally implement message heartbeats with a single rung of three instructions, monitoring an SINT:

Originally posted here:
https://forum.inductiveautomation.com/t/plc-to-pc-server/49062/10?u=pturmel

 

[Phrog30]

Can you build and paste an example?

Shows two different two options, I would use the unlatch. If the timer times out, you lost comms. It will recover automatically. No need for a reset.

Edit, most programs have flashers, something you would use to blink lights, for example, so I use a flasher as the heartbeat to other systems.

 

[rupej]

Shows two different two options, I would use the unlatch. If the timer times out, you lost comms. It will recover automatically. No need for a reset.

Edit, most programs have flashers, something you would use to blink lights, for example, so I use a flasher as the heartbeat to other systems.

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.

 

[Phrog30]

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.

 

[rupej]

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 agree about doing reads whenever possible.

 

[Phrog30]

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.

 

[Tmm2112]

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.