A good Engineer always questions things...
zacslade said:
So I'm working on a project where I need to communicate with a PLC which is being programmed by a third party.
The third party requested that our PLCs exchange/monitor heartbeats according to the following format...
rdrast said:
Point 1. ...but there are no other methods of doing this heartbeat if it is so specified by the customer...
Point 2. ...Why do we always over complicate things?
I don't want to seem too argumentative here, but I disagree on both points, and for good reasons, I feel.
Point 1. There was no mention of a customer specification. A third party, programming another controller, does not imply customer. So anything they request, and you agree upon, is as a courtesy to them, or a mutual agreement. Unless they are working off a customer specification, then that is different, but still questionable from the OP's perspective.
Third party, in this case, sounds more like another integrator who seems to use the Wall Clock Time for a Heartbeat. This method looks overcomplicated for a Heartbeat. If I were dealing with them, I would be questioning their reason for using this method, as all good Engineers, Programmers, Integrators should do. If they have a valid reason for using it, such as "killing two birds with one stone", or such, well then you've learned something new. No harm done. But if they just use it because that's the best they have come up with, then you should have every right to question its use, especially once you know of better, or simpler methods of creating a communications watchdog Heartbeat.
Point 2. We were not trying to overcomplicate this. We were actually trying to simplify it. Perhaps you mean overcomplicate in that we are straying from what was asked, but sometimes what was asked was not the correct question. Or the answer to what was asked is not the best solution. By providing the OP with other options, which they seem appreciative of, they are in a better position to question the proposed method...
zacslade said:
...I'm glad I'm not the only one who thinks that doing the heartbeat this way is a little ridiculous...
Exactly, you are thinking correctly. But...
zacslade said:
...Looks like I'll be using WallClockTime...
Why settle for something you are, for good reasons, not happy about? Ask them why do they do this for a Heartbeat. If no valid reason is given, other than that's their way, end of, then you can suggest simpler methods. You are perhaps just a little inexperienced and afraid to confront them. That's understandable. But remember, a good Engineer is inquisitive, and second guesses many things they don't like the look of.
Having to read out the WCT, and then arrange the separate DateTime DINTs for XH:MM:SS into 1 DINT, to send to another controller, is in my opinion, convoluted for a what should be a simple Heartbeat.
If you have been tied to some pre-arrangement, or customer specification, of which you have not mentioned, then you are still within your rights to query this, politely. Customer specifications should be open to questioning where something does not look fundamentally correct.
Again, no argument here. I just felt that perspective important to put forward.
If you need to get the Wall Clock Time from one Logix controller to another, to set the WCT in the other controller, then that is a different story. You would not need to manipulate the DateTime DINTs in the first controller. Use a GSV instruction to read out the DateTime attribute into the 7 DINTs, as Ken outlined. You can then either Message the required DINTs, or use Produce/Consume to the other controller. Then use an SSV to set the DateTime attribute of the WCT in the second controller.
This is all on the proviso that we are talking about two Logix controllers here.
This also suggests further complication in this method...
zacslade said:
...4 second timeout with no updates from other PLC causes fault...
If you have to read, manipulate, and send WCT data, for which I assume they monitor in the "other PLC" for 4 seconds, then what are they sending to you from the "other PLC" to timeout after 4 seconds when there are "no updates"? Their WCT time in the same format? If so, that would be two different WCT data values being read, manipulated, and passing each other for monitoring a connection. Data that includes the WCT hours and minutes, of which are totally unnecessary for a 4 second watchdog time.
If so, this is highly convoluted indeed for a Heartbeat.
By definition, a Heartbeat is a "pulse".
In the computing world, a Heartbeat is defined as "a periodic signal generated by hardware or software to indicate normal operation".
A Heartbeat need only be a simple toggling over and back between controllers. That is all it needs be at its core. Anything else is not a Heartbeat.
It never hurts to ask...
Regards,
George.
p.s. For those interested, this is the logic I outlined earlier...
