PLC Messaging Toggling Bits for Ack/Handshake Messages?

[theColonel26]

Does anyone else toggle bits, or increment words as a messaging technique?


To start a sequence or process I will hold a bit true (To avoid accidental starts), but usually for statuses and the complete confirmations (Acks) I uses a changing value (toggle a bool) and watch for it to change.

I do this to avoid race conditions, or at least greatly reduce my risk of race conditions.

I know a lot of people just use a timer to hold a bit true for like 5 seconds at the end of sequences for a complete signal, but that to be is not a solution is is just a cheap band-aid.

With toggling bools you can still run in to race conditions but in most situations it is not an issue are fine. I have started using incremented INT/DINTs in some places now. That is the most race condition proof technique I can think off. but it also uses a lot more data.


Lastly I always put timeouts on a sequence to alert the User that something went wrong and then let them reset and try again.



Thoughts?

 

[Phrog30]

Yes, and depending on the process, I might do a state machine. No race conditions when doing that. If you signed up for ICC 2021 there was actually a short webinar that discussed this.

I typically use words as triggers, that way if I timeout and want to try again I just increment, easier than toggling.

 

[janner_10]

Not really. More and more I've used EQU and MOV for Sequences even for bog standard simple things, we got a young apprentice and it's easy to display whats going on.

Or if it's a momentary from the HMI, it unlatches that bit when it's started to do what it needs to do.

EDIT: Should of read what you had written properly. Yes I do.

 

[Peter Nachtwey]

Does anyone else toggle bits, or increment words as a messaging technique?

Yes, I did for a long time. I ran into problems with a difficult customer who wouldn't admit his missed the toggle.


I also use to use ACK bits but that too is a problem if someone sends you a message and they look for the ACK bit immediately before the message is received and clears the ACK bit while the message is being processed. If you can get the other device to wait for a rising edge on the ACK bit then everything will work fine.

Thoughts?

The problems occurred when the bit got toggled off and then on again but the other device did not see the toggle.
Now I/we use TNS ( transaction sequence numbers ). This is much more reliable because then you know what message is being acknowledged.

 

[JeremyM]

Honestly a good idea, Peter. I could use an errant sequence number to determine and accumulate missed message counts.

 

[Phrog30]

The problems occurred when the bit got toggled off and then on again but the other device did not see the toggle.

The other device should be in a holding pattern waiting for it, it should know to look for it. While I'm not a fan of discrete handshakes, if done correctly they will work. It sounds like in your case it wasn't done correctly. Because, the sender turns the bit on, the receiver turns it off, nothing to miss in that case. You could have a terrible network, and it still work.

 

[jstolaruk]

Yes, I prefer it. Incrementing a INT/DINT for interlocking / messaging instead of just a bit adds an extra level of confidence. Replying with the same INT-DINT value seals the loop.