Best Practices for Communication Loss Detection

Hey all,

I'm working on a big Allen-Bradley Ethernet system and I'm looking for opinions on the best way to detect communication failure between the master PLC and secondary PLC's . Master PLC is a CLX5K.

PLC5/05 (MSG)
Micrologix (MSG)
CompactLogix (P/C)
CLX5K (P/C)
MODBUS Device

I've been brought up old school and have been using "heartbeat" logic in both ends. Is there a better way to do this?

Self-propagating handshake bits is what I use....

In PLC1 - XIC PLC2_HS OTE PLC1_HS
In PLC2 - XIO PLC1_HS OTE PLC2_HS

Then put a watchdog on the bits going static (in both PLCs)...

TON HS_Watchdog

Reset the timers at change of state of either bit....

XIC PLC1_HS ONS RES HS_Watchdog
XIO PLC1_HS ONS RES HS_Watchdog

If the timer times out, comms failure...

This way there is no danger of the "heartbeat" going synchronous to the message timing.

What makes the heartbeat not good enough for your application?

It very good idea Daba.

Sergei Troizky said:

What makes the heartbeat not good enough for your application?

Click to expand...

A "heartbeat" that goes on and off under its own timing can be read by the other PLC repetitively when it it is "high" or "low".

Using my logic the bits must toggle in both PLCs, and is synchronous to comms transfer rate, so can never suffer the problem of being read continuously in one state.

A heartbeat only takes one bit, but sometimes a rolling integer, or long integer is called for.

It can be used as an index pointer so that missing packets can be eventually transmitted when comms are restored, and it also is easier to visualize when there are intermittient comms.

The PLCs exchange a long or INT.

When they are equal, one device will increment its value (and queue up the next transmission, if applicable). When they are not equal, the other device will increment its value.

So you get a heartbeat plus a couple of numbers from which can be derived the number of missed transmissions, and the rate is easier to see on SCADA or HMI screens.

You still have to "strap on" some timers to check for stalls, just like the heartbeat logic.

And, depending on the type of channel in use, the timer DN bits can be used to disable messages.

Monitoring the number of connections and buffer levels is something I don't see enough of either. I still find programs at my new job in which the OEMs didn't even assign diagnostic channels in A/B PLCs, and they had plenty of memory...

Assigning diagnostics (and using the results in ladder code) can also be a good practice.

With ethernet and SLC/Micrologix, you definitely want to be careful how you load them with comms, even over ethernet, and the way that the MSG instruction functions varies slightly among the different families you're using, so the logic structure to handle errors will need to be carefully scrutinized.

Thanks Daba,

This is the same way I do my heartbeat. The problem that I'm running into now and then is that I don't always "own" both PLC's; that is the second PLC is programmed by someone else. So you need to integrate this with someone else's product, which isn't always easy; especially if their stuff is already installed.

What I am looking for is something that doesn't require setup on both ends. Something like a GSV call for remote IO.

How about reading a clock or other continuously-changing tag on the other PLC?