Doug,
We also handle our own Heartbeat & Handshaking on one of our systems and it has a similar nett result but achieves this via a different process to what you have described. In our case the two systems are interlocked as in The PLC process is not allowed to restart until some Operator intervention (selection) is made at the PC HMI end. As our system is basically a glorified downtime data logger we didn’t want the Process to be “unable to start” if the PC HMI end was inactive for any reason.
Heartbeat
We use two “Int” Tags for the heartbeat (one in and one out) the PLC just copies the “in” tag to the “out” tag on change. No change for a 3 sec period= no heartbeat. At the PC end we use if(({[.]Out}&255)>99,0,({[.]Out}&255)+1) to write to the “in” tag - this is done in the same transaction group* as the Handshake/Logging of the PLC value we want to track.
*we use stored procedure groups and do most of our data manipulation at the SQL server as the same procedure is called from many Groups in our system.(our SQLServer is hosted on a separate Machine to the Ignition Gateway)
Handshake
This is pretty much the same as the heartbeat but it is not manipulated before it is returned IE out -> in tags. The response is only sent after the PC end has successfully processed the “changed” data.
The point, I guess I am trying to make is that by requesting a specific Heartbeat or Handshake handling “feature” within Ignition, there will always be some who want it to function differently. The IA Guys have a great system here & I wouldn’t like to see it become bloated with “features” that are hard to quantify.
I’d be curious to see what methods others are using when they need to include a Handshake and/or Heartbeat