I understand Momentary Pushbuttons are not a good idea however what I am looking for the button to stay pressed when I click and hold and unpress when I let go. Right now it will not release when I let go or it will highlight the text on the button. This seems like a pretty simple ask but I cannot seem to find any solutions here.
I’ll start the debate. 
There is nothing wrong with them, I use them all of the time for jog functions. But, I protect myself in the PLC for potential issues.
1 Like
Yes, there are pitfalls, but momentary buttons are fine where they add useful functionality if you’re aware of the pitfalls and program accordingly.
Click-n-hold keeps a button down till I let go in Perspective. And it will also set/reset a bidirectionally bound value on a custom property via onMouseDown/Up event scripts on press/release (this method does NOT account for any of the pitfalls; I’m not recommending it).
Can you give us some more details on exactly what’s not working as desired for you?
1 Like
I have a multi-touch panel. Right now one of two things occur, either the button will not reset once I let go or the button won’t press and instead it highlights the text on the button.
A single touch driver will likely work better for this. If you need multi-touch, there may be others here who’ve figured out how best to work with it.
1 Like
Agree on specific driver for long press and hold. You typically can’t use what comes with them, at least all of the ones I have purchased all required a different driver.
How have you gotten this to work in perspective? I’m trying to utilize the mouse down and mouse up events to write a tag true/false on mouse down/up, respectively. It’s not working for me, though.
Nevermind… I’m stupid and just had a typo in my tag path. What I did works just fine.
How do you accomplish that? Just curious for my own learning purposes.
It depends. But, my goto is to immediately unlatch/reset if anything other than jogs. I don’t have any PLC software handy, but using Studio 5000 as an example… the button will be XIC and following that will be OTU. So, no chance to get a ‘stuck’ bit. On top of that I may have other conditions following, like auto/manual state. For things like jog, where the signal may be high for a little while, I won’t unlatch immediately as then it wouldn’t work at all, but I may use conditions like ‘in/at position’ to unlatch or a timer to reset. For jog I typically reset if in conditions like running in auto, running a sequence, etc.
@pturmel has gone in depth on how he handles things. In my opinion, it really depends on the project and what may come from any safety survey. I don’t think there is a one-size-fits-all approach on this.
1 Like
Hey everyone,
Sorry to revive the topic again after a couple of years of silence.
- Does anyone still experience issues with latched momentary pushbuttons? IA was working on this problem, and I wonder if it was fixed.
- Did anyone try using the INT value for the momentary pushbutton vs BOOL?
Thank you.
Really? Where did you hear/see that?
Phil,
You are right, I have exaggerated the IA software engineers responses from other topics.
Ironically, I don't see any replies from them since 2015.
I guess, this issue is still the case.
Anyway, Phil, you seem to understand the issue better than anyone else on the planet,
Sorry for maybe a silly question, do you think using the INT variable vs BOOL for pushbuttons would make a difference in this case?
No, not for Perspective. The incrementing-integer approach to producing a reliable "still pressed" indication only works in Vision because it uses Vision's local gui thread. If anything chokes that, the increment dies, and the PLC can deal with it.
Perspective has no way to reliably run javascript for this purpose, where it would stop incrementing on button release.
There simply is no way to reliably ascertain button press/release in Perspective. I hope to eventually figure this out for my EtherNet/IP module (as a companion to its Vision MomentaryIO button), but there's a bunch of stuff ahead of it in my queue. And I'm not entirely certain I can do it robustly enough for my standards. It is a browser.
{ Do note that my Vision MomentaryIO button only works with that module's Class1 I/O buffers, not with arbitrary OPC devices. That will be true for any Perspective equivalent, if/when I figure it out. }
2 Likes
For most things, I find jog to position or jog for x time is superior to a simple jog button. In both cases, PLC handles all the logic with HMI just requesting start, and sometimes making a limited range of set jog time available to adjust from HMI. End limit sensors are also included in PLC.
For applications that really need a momentary jog button, a physical pushbutton is likely justified. However, beware that even physical pushbuttons stick sometimes. For physical start/run buttons, we make a stuck button fault and commands executed on rising edge standard. In case of lit toggle start/stop buttons, rising edge starts/stops, and stuck button also stops. Momentary jog prevents catching stuck button issues in less than max expected jog time, so consider stuck button failure mode in overall design decisions.
4 Likes
What are your thoughts, for momentary buttons, about using a ValueChange event handler on the momentary tags that writes the value to False whenever it changes to True? Ideally I'd want to delay the tag write to False by a second to make it more reliable. I still don't like it though... but if you can't modify the PLC logic...
From a PLC side, this method has a chance for the PLC to miss the True value before it's had a chance to use it in the logic, so could lead to operators having to press the button more than once (however I saw operators push a button in the audit log the other day 20 times, so maybe that's not an issue 
)
Then it isn't "momentary" at all. A "momentary" contact in the pushbutton world is a circuit that is on when held down and off when released. That is the behavior that simply cannot be done reliably with typical HMIs and typical SCADA. For Ignition, not at all, in Perspective. And not "out of the box", in Vision.
The terminology we use is:
- Momentary: On-short-delay-Off
- Jog: Push and hold On (could be held for 10s of seconds), release Off.
I guess techincally they're identical, but I'd say a momentary On state is short lived, just long enough for the PLC to do something with it in a one shot. Whereas a jog is a sustained "do something while pressed".
Out of interest though, how would you handle the delay here?
1 Like
Well, you may, but that is different from what the makers of physical pushbuttons have used for decades. Your usage confuses the topic and misleads inquirers.
I strongly disagree.
I would avoid the need for it. I prefer signals that require no delay. An increment to a short integer can provide a robust event that requires no reset and no acknowledgement.
Booleans written from one direction, with acknowledgement booleans in the other direction, are also robust, and require no timing. They can be as fast as the messaging involved.
Any form of sleep is a flaw, of one kind or another. If not of many kinds.
1 Like
If you aren't able to modify the PLC though and the code is from an OEM, this is usually how they're coded; the HMI will both set and reset the same tag on press/release. It's certainly not great, but sometimes a necessity to get it working given the limitations.