Momentary Pushbutton latching ON

[quote=“Carl.Gould”]Ok guys, so first of all it will always be true that without any PLC logic, a momentary button implemented in a software system will be open for the potential for latching on.

The reasons for this should be obvious: a “soft” momentary button isn’t a physical switch, it’s two separate write commands. It isn’t hard to concoct a situation where the second write command doesn’t happen: power down the entire scada system and boom - latched bit. Given this, the advice earlier in the thread about avoiding momentary buttons is good advice.

That said, I think it is certainly fair to say that under normal conditions, momentary buttons should just work. That is: we shouldn’t hide behind a general “momentaries are bad” advice to skirt around the real issue here, which is that there seems to be a race-condition affecting the momentary button.

We think we have this narrowed down (like all race conditions, it’s tricky to pin-point because it’s hard to verify 100% that you’ve fixed the issue if you can’t reliably reproduce it). We’ll re-work the section in question for 7.5.5 and I’ll post back here when progress is made on this ticket.[/quote]

Carl,

the solution is simple. If the loss of focus on a momentary button is lost for what ever reason, the bool referenced by the button should be returned to its previous state.

[quote=“Curlyandshemp”]Carl,

the solution is simple. If the loss of focus on a momentary button is lost for what ever reason, the bool referenced by the button should be returned to its previous state.[/quote]

I don’t even know how to respond to this. I hope you were being sarcastic.

If not, please just trust me that you aren’t fully appreciating the complexity involved here. The problem here isn’t quite so “simple”, in fact, it isn’t even a problem with the momentary button at all (which does indeed act like a momentary button that you so aptly described). Our current hunch is that the problem lies in a race condition in some Gateway-side logic that is under rare circumstances reversing the order of two OPC write commands.

[quote=“Carl.Gould”][quote=“Curlyandshemp”]Carl,

the solution is simple. If the loss of focus on a momentary button is lost for what ever reason, the bool referenced by the button should be returned to its previous state.[/quote]

I don’t even know how to respond to this. I hope you were being sarcastic.

If not, please just trust me that you aren’t fully appreciating the complexity involved here. The problem here isn’t quite so “simple”, in fact, it isn’t even a problem with the momentary button at all (which does indeed act like a momentary button that you so aptly described). Our current hunch is that the problem lies in a race condition in some Gateway-side logic that is under rare circumstances reversing the order of two OPC write commands.[/quote]

Sorry Carl if you thought my post was sarcastic, that was not the intention. I thought I had a defintion of the solution to the problem. We all know in software, first you need to identify and replicate the problem, then define a solution, then implement and test that solution.

You must understand that it is we the users of your product that get the panic phone calls from end users when the product does not behave in a way that it was intended. It is me, the user of your product that must absorb the cost of a warranty trip to job site for something that has happend completely out of my control.

I definitely agree with your point on identifying and replicating the problem. This is a tricky one indeed, as most race conditions are! We’ll keep you posted on the progress of this issue. For the time-being, you may want to use the aforementioned workaround using one-shot buttons or something similar.

I fully appreciate this, and have been on that end of the equation before. We are working to address this in 7.5.5, hopefully we can get it nailed down.

We were able to replicate a situation where you could get the momentary button to latch the bit on. It involved pressing the momentary button again immediately after the momentary button was released (pressing it while it was clearing the bit). This has been fixed for 7.5.5.

It doesn’t matter which SCADA/HMI you use you will always have this problem.

What I always do is put logic in the PLC that provides me with a pulse for every button action.
The HMI writes a 1 to the PLC Start_X. The plc provides a Start_X_pulse for x milliseconds. At the end of the pulse the PLC then writes a 0 to the Start_X bit. The PLC clears the bit once it has ack. Receipt of the cmd.

You are guaranteed not to have timing or communication issues. The HMI can use the bit as a status to know the cmd has been issued.

Heh, I feel like we’re beating a dead horse here.

Yes: it is always the best idea to put logic like that in the PLC. But the fact remains that we consistently have customers who simply refuse to do this, insisting on tying an HMI button to PLC logic that was written for a physical pushbutton.

Like I said, this will always involve some danger. But when it is a fault in our software like it was in this case, we should fix it even if this style of design is against best practice.

Hey guys, someone told that some issue regarding the Momentary B. was fixed in the 7.5.5 version.
I’m working with the 7.7.3 rc1 and this issue show up some times in my project.
All other implementation of the PLC in the company does not reset the bit, so don’t like the idea to make it different in my case.
Some recommendation how to deal with?

Claudio

How are you able to get it to latch, and is it reproducible? Some quick testing I did suggests it’s working ok.

Hi James,
Sorry but I could not reproduce it. I tried many times hit the button, by different frecuence to found out when it happens, but the issue did not repeat. Now I’m using 5 ms instead of 1000 (default) for Min Hold Value and since some hours of operation it does not appear any more, but I don’t know if this is the solution…

Claudio

Please let us know if you find a way to accurately reproduce this issue.

Could it be possible that the button is pressed and before the ‘off’ signal is sent the window is closed? This will cause your momentary button to be stuck on.

Pat,

I could see that as a possibility. I tested the theory on a momentary button and placing a mouseReleased event on the momentary button that would close the client runtime. If I performed a press and release, not a press and hold then release, the bit became latched.

Greg - If you place a Momentary Button in a popup window, bind it to a Tag and set the Min Hold Time to say 10 seconds, then if you click the button and close the popup window within 10 seconds then Tag doesn’t get updated with the button released event. I’m assuming this is because the button released event is tied to the window (not the client) and since the window is no longer there that event doesn’t fire.

Pat-

That would be correct

Hi folks. Was this ever conclusively addressed? I’m still seeing it occur in 7.9.7.

Best way to get around this is to have the PLC code unlatch the bit.
I do this all the time now .

I’m testing a new momentary “I/O” pushbutton component that will reliably manage button release in the gateway, protecting against gateway-client comms failures, window closure while pressed, and GUI freezes. I’ll post an update here when it’s ready. It will be part of my Ethernet/IP module, as there is no way to handle TCP/IP comms failure in an OPC driver. Only an I/O protocol with native error detection will suit (just like a real remote I/O chassis).

Alright then, I’ll do that. It’s a bit disappointing because in normal operation this is happening VERY often (~2% of the time). It’s a relatively low-power panel PC I’m running my gateway on. It seems more prone to freezes/glitches than previous machines so maybe this is just one of them.