If your Push Button is on the Front Panel of code running on a cRIO, then the "mechanical actions" you are trying to implement make no sense since code running on a Real-Time Target (such as a cRIO) don't have a User Interface -- the Front Panel is only used to pass in or out (static) variables from a calling routine (although you can run the RT code in Development Mode, that is, while creating and testing the Software, allowing you to "push Buttons" and/or enter numeric/string values.
[Hmm. Maybe I'm not 100% correct about what I just said. I just opened a Real-Time Project of my own, where I use Boolean Controls (but mostly Indicators), and assumed I couldn't put down a Stop Button, which has a Latch property. Well, I can, but I don't know that it will "work as I expect" at Run-Time.]
The "trick" to implementing a Latch behavior is that code needs to monitor the Switch behavior to know when the Latch "expires". In "regular" LabVIEW, which does not have "real-time" expectations, its is OK to have little "demons" with little millisecond timers or some sort of interrupt structure that monitor these Boolean controls and implement the Latches. But in a Real-Time OS, you don't want extraneous processes using up Clock time, particularly if the User never "pushes the button" except when running in Development/Debug mode.
So I'd say "Don't worry about implementing this function -- you can't use it when you deploy your code to the Real-Time Target and run it as a true LabVIEW Real-Time Project (from the Host).
Thanks everyone for answering. I just solved the problem. Just to be more clear, it's correct that the code will be run on a cRIO real time hardware but it will upload as "run as startup" and a monitor and mouse will be connected to the cRIO to have the possibility to interact with code in real time. The solution that i found is very simple and faced my problem perfectly. I configured the mechanical action of the boolean control as default (switch when pressed) so by using an event structure i cautch the moment the mouse will be up or leave the control, in this way via a local variable and a boolean constant, I forced the signal to go down. Following there is a capture of the code used.
Thanks all for the help and support.
. Following there is a capture of the code used.
Pictures are not code and whatever you show here seems a bit silly. 😮
Why would you need a second loop and why do you have a wait and a timeout in the upper loop? Wouldn't it be sufficient to have a mouse-down event and eliminate the lower loop entirely? Why does the upper loop have a stop butting while the lower loop cannot be stopped? Why isn't there an event for the stop?