Detect Communications Loss

I have an Ethernet connection between an SLC 5/05 and a CompactLogix PLC and I have logic that toggles a bit back and fourth between the processor as my watchdog but depending when I unplug the cable my watchdog bit may be high or low.

Right now I am looking at the watchdog dog bit and if it's low for 10 seconds I stop the equipment and set an alarm horn but sometimes when I unplug the Ethernet cable it leaves the bit high because that was the last write and there are no comma to change it.

What's the best way and cleanest way to code it to look ok for a change of state from high to low on the watchdog bit and if no change of state is seen for 10 seconds the set the comms fault alarm?

The COS logic and the watchdog is in or will be in the SLC.

Try this:

I use a different method than ASF's example. In the example, what happens if your Heartbeat syncs with your read/writes where the Heartbeat is always true every time you perform a read/write? Your comms will be going through, but your logic will say they aren't. This becomes more of a concern when the time between read/writes gets long, for instance say you're only reading/writing once every minute, it's completely possible that your Heartbeat bit will be in the same state twice in a row.

What I do is keep a bit that is always On in the Slave PLC, when a read/write is performed the Master PLC will see that bit as On. In the Master PLC I reset the bit to off after two seconds. If the bit is Off for more than X seconds then there is a comm alarm.

Personally I use a counter. The slave constantly reads the value of the counter in the Master PLC. If the current reading = previous reading for time, then I'll alarm.

The counter resets after a certain high number like 9999.

Paully's5.0 said:

Personally I use a counter. The slave constantly reads the value of the counter in the Master PLC. If the current reading = previous reading for time, then I'll alarm.

The counter resets after a certain high number like 9999.

Click to expand...

This right here.

Tark said:

I use a different method than ASF's example. In the example, what happens if your Heartbeat syncs with your read/writes where the Heartbeat is always true every time you perform a read/write? Your comms will be going through, but your logic will say they aren't. This becomes more of a concern when the time between read/writes gets long, for instance say you're only reading/writing once every minute, it's completely possible that your Heartbeat bit will be in the same state twice in a row.

Click to expand...

Valid points - I've never had need to set up an application that isn't reading data more or less constantly, so that particular one has never been an issue for me.

As for the heartbeat syncing with your read/write - well, obviously you have to set them up with that in mind. If I have a 0.5s/0.5s heartbeat that I can't change, then I'll set up my MSG instruction to read/write every 750 or 1250ms. Or conversely, If the MSG instruction is triggered every 1s and that can't be changed, I'll give myself a 750ms/750ms heartbeat

Tark said:

What I do is keep a bit that is always On in the Slave PLC, when a read/write is performed the Master PLC will see that bit as On. In the Master PLC I reset the bit to off after two seconds. If the bit is Off for more than X seconds then there is a comm alarm.

Click to expand...

This is another good method - I use a variation on this for detecting comms losses to VSD's or other ethernet devices that don't have a heartbeat

I've tried several methods, and settled on transmitting the counter .acc value to the master. Foolproof.

Paully's5.0 said:

Personally I use a counter. The slave constantly reads the value of the counter in the Master PLC. If the current reading = previous reading for time, then I'll alarm.

The counter resets after a certain high number like 9999.

Click to expand...

+1.

Since your heartbeat counter will be in the SLC, I'd suggest using the S:4 (internal clock) register. No need to create a separate counter, nothing to reset.