Ive had a couple occasions where using a momentary button tag where the tag would turn on the bit but wouldnt set it back upon release.
If you search the archives you’ll find this topic popping up many times. There’s no pure-Ignition solution, as there’s no way to guarantee that the release event in a client occurs, nor that the OPC write on release succeeds.
The correct answer varies by situation, but always requires some heartbeat or validation or fallback on the PLC side.
if is an absolute critical function, such as momentary button to start a process, always best to have the PLC unlatch the bit once the start function has been activated.
We had the same problem that started few weeks ago. And i find out that was related to the tag group Rate (Scan class).
I’ve create a Tag group for momentary button and set the rate to half the minimum hold time of the push button and it seem to have resolve our problems. Momentary Buttons are set with a min Hold time of 1000 ms, so the rate of the tag group should be 500ms.
With the rate a 1000ms i could make the plc contact latch almost every time by pressing the button again just before the min hold time was ending.
For a momentary button, you could probably use the tag activated bit to activate an OTE within the PLC logic that acts as the actual command bit in the PLC program. Then, put a corresponding OTU for the tag activated bit one rung above the OTE, so that each PLC scan unlatches the command bit. Placing an ONS in line with the OTE would probably be helpful as well.
Edit: Added Example Picture:
Example with ONS for added safety:
Momentary buttons can be dangerous, and should never be relied upon. No matter how robust you've made the timing on the Scada side, there is always a chance due to some external reason that a release event doesn't arrive at the controller. The rate of your Tag Group may have made your issue more prevalent, but I seriously doubt that it was the root cause.
See this thread for the reasons why.
This is still the correct answer if a momentary button must be used.
Personally, I avoid them.
1 Like
After some consideration, I realize that the PLC command should probably be written this way with the unlatch bit below the command bit:
Unlatching in the PLC means that bit is being written by both Ignition and the PLC. Writing anything from two directions has inherent race conditions with OPC subscriptions. Use separate bits, or better, use an incrementing short integer.
FWIW, I have never had any issues with unlatching commands in the PLC. I have been doing this practice for years and not just with Ignition… Wonderware, FactoryTrash, etc.
Can you give an example of a race condition on this? If the HMI writes, once the PLC sees it, it clears. What race condition can exist here?
Sigh. As noted elsewhere, I've been harping on this for years. Because, while rare in most cases, small disruptions can make it extreme:
https://forum.inductiveautomation.com/search?q=tag%20write%20race%20user%3Apturmel%20order%3Alatest
The most likely race is when the PLC resets the bit immediately (same scan) instead of waiting for a timeout.
The race is not applicable to many HMI's that have naïve write algorithms with direct PLC connections. OPC server's subscriptions (and similar technologies) with report-on-change make the race possible.
Also, your example:
is not a momentary button behavior. That's a simple button sending a single write. The momentary button behavior where the signal is to be maintained while pressed is the vulnerable one. (There are other handshakes that are vulnerable, too, which is why my advice is more generic.)
Wasn’t my example, reread the posts. You responded to example PLC code and stated there could be a race condition. I asked how. Sigh.
The sample PLC code in this topic both breaks the maintained behavior of a momentary button and uses a pattern that is vulnerable to races. Sigh.
Meh 
1 Like
When I read this, I envisioned something like a simple start, stop, or reset function. I was not envisioning something like a jog function.
My apologies
You guys 
5 Likes
You are right, it’s probably not the main reason we had this problem. But the Ignition HMI is working on this production line for more than 2 years, and it’s the first time we are having issues with the momentary push button… Any way I have made an AOI in the PLC to reset the Button after a preset time. That should be the long terme solution.