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.
I have a beta of the Ethernet/IP module with the reliable Momentary I/O Button component available here. The embedded user manual has a few paragraphs on how to use it.
2 Likes
Unfortunately, I can confirm and replicate this issue on 7.9.7, with either no min/max hold time or default times. It takes an average of 30-60 button presses before it latches on, but it consistently does. And as mentioned earlier, it seems to be a race condition caused by clicking the button at an erratic pace. I am using a standard momentary button component within a template.
I would hope this issue could be resolvedā¦ either that, or perhaps the momentary button should not be an offering at all?
Phil, thanks for your contributionā¦. I will DL and take a look at it.
I'll be issuing a new beta shortly -- found some bugs. /-:
To whom it may concernā¦
I have experimented with different settings on the Scan Class associated with my Momentary button template. After several failed attempts, I finally copied the Default Scan Class (Direct, 1000ms, Subscribed) and checked the option for āOPC Read After Writeā. In testing, I have (as yet) been unable to cause the bit to latch after well over a thousand mouse clicks whereas I was able to easily cause a latch after just a few dozen clicks without the OPC Read After Write option selected.
Perhaps a workaround, perhaps just a coincidence? If used make sure you are in a test bed and not a live environment. We are using for pre-FAT at the moment, so we will have a much better grasp of the work-ability after another week or so of testingā¦ but, so far, so good.
Fingers crossed.
Steve