Comms Good / Heart Beat Logic

[BobB]

Send a heart beat from one PLC to the other over the network - say a 1 second pulse - 50% on and 50% off. At the other end have a timer that is reset by the pulse - if the timer times out there is trouble.
I have utilised this in the old days with great success - these days my PLC of choice has heaps of options in monitoring bits for mode (run or not), in the data link, not in the data link, active or inactive - you name it. For comms failure for example I use the in data link bit - pull out an Ethernet cable, program mode, fail or whatever and the bit turns off - really simple to use.

 

[Ones_Zeros]

Can you guys post a sample of your Logix
That you use for your heart beat pulse to
Monitor the communications between
The two compact Logix plc’s?


Thanks for helping

 

[Ken Moore]

Simple one sec pulse, in PLC1, monitor in PLC2, if no change in 3 sec., problem.

 

[Ones_Zeros]

Ken,
to send pulse to PLC2 would you have to create a MSG instruction?

thanks,

 

[widelto]

In my case, I have two compact logix PLCS , in order to ensure they are always working properly I use a safety relay that send a signal to each plc and plcs must respond to safety relay, if there is no response from one plc we shut down the whole thing.

 

[Ken Moore]

Ken,
to send pulse to PLC2 would you have to create a MSG instruction?

thanks,

Yes

 

[Firejo]

This is being made way more complicated than it needs to be. You don't need a heartbeat. Both "Produce/Consume" and Message instructions provide tools to monitor the health of the connection. With Produce/Consume simply use a GSV instruction to monitor the "EntryStatus" of the Module (that is the other controller producing the data). This should work for the drive connection as well. However, given that your boss won't let you use P/C between the controllers, a Message instruction provides status bits of the message I.E. an Enable bit, a Done bit and an Error bit. The Error bit will tell you when the message timed out. You can even tie the Done bit and Error bit to counters to see how healthy the connection is (I.E. if for every 5 Done bits you get 1 Error bit, your connection is marginal however if you get 1 Error bit for every 500 Done bits your connection is good). Don't over complicate things. Someone somewhere down the road is going to have to decipher what you're doing today and the simpler the process the easier it will be to troubleshoot in the future.

P.S. To give credit where credit is due, Ken R. pretty well covered this already.

 

[rupej]

^ problem with your method is if the other PLC faults or otherwise is not in run mode, the connection still looks good.

 

[Firejo]

^ problem with your method is if the other PLC faults or otherwise is not in run mode, the connection still looks good.

Yes except that you can also use the connection status feature for the tag (or tags) being produced and consumed. All moot given he can't use P/C.

 

[rupej]

Does the connection status go bad if the other PLC is in program mode? I've never tried it.

One advantage of rolling your own is that you can set the exact length of time before calling it a bad connection. Sometimes this is very helpful for plants with spotty networks. Any idea on how long the connection status waits before deciding it's a bad connection?

 

[Firejo]

Does the connection status go bad if the other PLC is in program mode? I've never tried it.

One advantage of rolling your own is that you can set the exact length of time before calling it a bad connection. Sometimes this is very helpful for plants with spotty networks. Any idea on how long the connection status waits before deciding it's a bad connection?

There are two bits in a Connection Status tag, "RunMode" and "ConnectionFault". I don't remember the exact details of what does what except that when the tag is being updated "RunMode" is set to "1" and when it's not it's set to "0". I believe that if the producing PLC is not in Run mode or faults the "ConnectionFault" bit sets to "1". You could tie that to a timer and then set the amount of time that it's in fault mode before setting an alarm.