LabVIEW
Latch Until Released Behaviour
Solved!
The behaviour of the latch-until-released behaviour of switches seems a little strange to me and I was wondering if anyone would shed some light on a question I have about it.
As a quick experiment I created a very simple VI containing just a while loop with an event structure, a couple of latch-until-released boolean controls, and a numeric indicator.
What I expected was that the indicator would display "2" while one of these boolean controls was depressed and "1" after releasing it. What I found was that it displayed "2" after pressing the button but remained that way after releasing it as well.
Using the event inspector window, I verified that this event case was firing both when I pressed the button and when I released it, but in both cases it seemed to be reading the button as "true". I find this really odd - wouldn't it make more sense for the button to be read as true in one case and false in the other?
To get the intended behaviour, I had to do something pretty ugly:
Since the button seems to be in the same state in both executions of the case, there's no way of differentiating between press and release events except by keeping state external to the event structure. My question is basically: why have the LabVIEW developers chosen to design it this way? What's the logic behind it?
@CoastalMaineBird wrote:
Your event recognizes a VALUE CHANGE.
The definition of WHEN the value changes is defined by the mechanical action you set.
If you set latch-until-released behavior, you are asking the button to retain its TRUE state until the next READ after the mouse releases it. (look at the MECHANICAL ACTION icons for pictures of this). In other words, it is the READ of the TRUE state (after the mouse release) which CAUSES the button to pop out.
wouldn't it make more sense for the button to be read as true in one case and false in the other?
Not if the READ is the CAUSE of the transition. They do it this way so you won't miss a transition (especially back in the days before EVENTs - you had to poll the buttons to respond to them).
I have never used the latch until released, only latch-when-released for regular DO IT actions, and sometimes switch-until-released for pushbutton type (DO IT WHILE I PUSH) actions.
You mention having to do something ugly to "get the intended behavior", but I'm not sure what your intent is.
> The definition of WHEN the value changes is defined by the mechanical action you set.
> If you set latch-until-released behavior, you are asking the button to retain its TRUE state until the next READ after the mouse releases it. (look at the MECHANICAL ACTION icons for pictures of this). In other words, it is the READ of the TRUE state (after the mouse release) which CAUSES the button to pop out.
That's correct, but the issue here isn't so much when the value changes (the value changes in the way I expect), but the choice LabVIEW is making about when to sample the control's value and generate an event. When I press the button and generate an event, does LabVIEW update the state of the control and then generate a Value Changed event? That would make sense and it seems that's what's happening when I press the button. However, when I release the button, it seems to be generating a Value Changed event and then changing the state of the control.
This diagram might make this all clearer:
> Not if the READ is the CAUSE of the transition. They do it this way so you won't miss a transition (especially back in the days before EVENTs - you had to poll the buttons to respond to them).
If that's the case, is there a way that I modify the program so that I can read the control as false when I'm releasing it (which would be more intuitive and make the program a lot simpler to write)?
> You mention having to do something ugly to "get the intended behavior", but I'm not sure what your intent is.
My program is ugly because I have to keep boolean values going through shift registers and switch their values within the Value Changed event case. I have to do this because I read a boolean control as "true" both when pressing and releasing it, and therefore I have no way of differentiating which situation is happening within the event case itself - I need to maintain external state to "remember" if the button is currently pressed or depressed to figure out how I should update the numeric indicator.
My intent is just to update a numeric value to one particular value when a button is pressed, and another value when it's released.
@Bob_Schor wrote:
I think the explanation is that Value Changed refers only to value changes that take place by interaction with the Front Panel, such as pushing the button. The Latch property means that when the button is read, it "clears itself", but like any programmatic change to a Control, this is not registered as a Value Change.
So Up is initially false. You push it, it becomes True when you release it, and triggers the Event. You read it as True, which travels in the wire and selects 2 -- the act of reading also changes the value to False.
I tried to write a tiny VI to illustrate this, but ran into the issue that you can't create a Local Variable from a Latched Control, nor can you use the Value property. Oh, well ...
BS
I'm not sure if you're correct - the reason being that two Value Changed events are generated, once when pressing the button and then again when releasing it. This can be verified with the Event Inspector window. I don't think the value change associated with releasing a latched boolean control is classified as "programmatic".
Up is initially false. I press the button (and keep it pressed), and an event is generated during which time Up's state is read as true. At some later time I release the button, generating another event in which Up's state is again read as true.
@CoastalMaineBird wrote:
In your event structure, you have an OLD VALUE and NEW VALUE supplied to you. You can do logic with those if you need to further distinguish the transition.
Consider using just the SWITCH UNTIL RELEASED mechanical action,
That generates a VALUE CHANGE event on press and a VALUE CHANGE event on release. You use the NEW VALUE to distinguish which.
> In your event structure, you have an OLD VALUE and NEW VALUE supplied to you. You can do logic with those if you need to further distinguish the transition.
With the "latch until released" mechanical action, these values are the same for both the press and release case, so you can't make a distinction.
> Consider using just the SWITCH UNTIL RELEASED mechanical action,
Thank you! I hadn't looked at the switch mechanical behaviours closely enough because I assumed that all switch actions 'permanently' changed the control state (i.e. made it so the user would have to click the button twice to get it back to its original state). I ought to have looked closer at the diagrams. This gives me the behaviour that I expect.
Edit: Looking back I noticed I missed you write "...and sometimes switch-until-released for pushbutton type (DO IT WHILE I PUSH) actions." Sorry about that.
And for the sake of it, here's a simple, working solution now that I've configured the buttons with switch-until-release behaviour.
