Why do 'Switch Until Realease' buttons sometimes latch on?

[Adwex]

---

@Dennis Knutson wrote:
I'm pretty sure that there is no bug in LabVIEW or a problem with your computer. Though I haven't found where the exact problem occurs. I suspect that it's being caused by your overuse of local variables. You probably have some sort of race condition happening. I would suggest that you try to use the event structure for all of your front panel controls and a shift register or two.

---

I am having the exact same problem, and I'm not using any local variables, so no race condition exists. I too am using the button in an event structure, but I don't see how the implementation of the button (short of using locals) could affect its mechanical action. This looks like a bug.

[Dennis_Knutson]

I'll repeat what the others said and that's you need to post an example. If there is a bug, NI will need to see it and be able to reproduce it.

[Adwex]

---

@Dennis Knutson wrote:
I'll repeat what the others said and that's you need to post an example. If there is a bug, NI will need to see it and be able to reproduce it.

---

Here is an LLB with my top level vi and some sub-vi's. The buttons in question are the 6 "jog" buttons. They are the only buttons set to "switch until released".

I believe this is a bug simply because if we examine the phrase "switch until released", we expect the button to not remain "switched" when it is "released", when in fact the button (intermittently) remains switched after it is released. The implementation of the button (short of using locals) should not reverse the logic of the button, or alter it's mechanical action.

Adam Wechsler

[Adwex]

I just spoke to NI Application Engineering tech support....I was told that this is a confirmed bug.

[tca-adam]

I am also seeing this latch effect in V8.20

Does anyone know if it has been fixed yet?

thanks

Adam

[bburress]

Hey Adam,
    Would you mind posting a VI that replicates this behavior in 8.2?  Was this VI originally created in 8.0, or was it created in 8.2?

[tca-adam]

Hi all,

It is amazing what a few hours away from a PC can do for you! It suddenly hit me last night what the cause of my problem may have been and I was right.....

In my event structure I was waiting for a MOUSE DOWN event on a boolean button (switch until released), then wanting to loop that event code until the button was released. The button was getting stuck down as I looped and kept checking the value of the boolean button.

The problem.... you must turn off LOCK FRONT PANEL UNTIL THE EVENT CASE FOR THIS EVENT COMPLETES otherwise the fornt panel won't release the button.

Shame it took me so long to work it out!

Adam

[Vaibhav]

I have the similar issue, on "complex" program, but not on small programs that I made today.

From the discussion it seems it WAS an issue, which has been resolved, probably.

I am using LV8.6.

I am also resolving it by using local variables, and advices/responses on this and many other newer threads, suggest that it is the "proper" way to switch back to default (although the name doesn't suggest that - "Switch Until Released", I mean it should be automatic, and it happens on small programs).

Contrary to that advice , the current thread says that using many local variables actually "cause" this problem, and the explanation by Dennis Knutson convinces me more.

But, in my program, even after removing all the local variables for a boolean control, I still don't get it switched back after releasing. Why would that happen?

Also, as someone said above, by highlighting execution, I could see that the Value Change events are executed twice, first with NewValue True and then with NewValue False (which could be due to "switching it back" by the very nature of the control's properties), but I think it should not execute twice (like this, I do some activity twice, instead of once) and also, if it executes second time with false value, why it doesn't then turn it to False?

Using local variables to turn to False shouldn't be triggering the second time of this event, because for that we should have passed the value to Val(Sign) property, right?

why then?

Posting the code would be a little bit difficult, since it's a big code. It would be great if there is already an explanation for this, as this is not a new issue now. Otherwise, I would try to reduce the code to post here.

Thanks ahead!

Message Edited by Vaibhav on 09-12-2009 07:29 PM

[altenbach]

Whew, that's a confusing post.... (You talks about mechanical actions, using local variables, not using local variables, using value(sgnl), using switch until released (why???), events, ...) It is difficult to tell what you want, what you don't want, what you observe, what you like to observe.

The correct mechanical action to use is "latch when released" This will turn it TRUE until the code reads the value. Once the value is read, it will automatically switch back to FALSE without triggering a new event. The only requirement would be that the terminal is in a part of the code where it is in the dataflow after it turns TRUE, typically inside the associated value change event.

[Vaibhav]

🙂

Someone had to say that (it's confusing)!

Part I (about my first comment's confusion)

My objective: The boolean button should turn false (default) after its value is read (and the event should be performed once only).

My selection: Switch Until Released

Reason: It allows use of Local Variables

Problem: The button doesn't turn back to false naturally

Solution: I use Local Variable to turn it back to false

Question: Is the usage of LV the solution (to turn back to normal) or is it the cause (it generates some kind of race condition)? If it is the solution then why the mechanical action called Switch Until Released. It seems more like a cause of the problem.

Contradiction: Even after not using the LVs (the suspects), the control doesn't turn back to false.

Observation: The event of this boolean control is executed two times upon single click (perhaps by the very nature of the control's mechanical action which says "switch until released", i.e. switch back afterwards, i.e. value change again).

Contradiction: If the event is performed twice (undesirably, just due to the action) why wouldn't the control turn back to false (due to the same action). Seems like the evil side-effect happens, yet we don't get what we want.

Part II (based on your suggestion)

---

altenbach wrote:

The correct mechanical action to use is "latch when released" This will turn it TRUE until the code reads the value. Once the value is read, it will automatically switch back to FALSE without triggering a new event. The only requirement would be that the terminal is in a part of the code where it is in the dataflow after it turns TRUE, typically inside the associated value change event.

---

Sometimes we do things in complex ways that we forget the easy normal way. Yes, latch when released is the better way to use, when I don't need local variables for other purpose. I changed all of my boolean buttons to latch when released mechanical action. This also solved the issue of two-times execution of events.

Kudos for this!

But (as usual a "but"), there are 3 boolean buttons with similar function of Exit (end the application) and I have to click them two times to end the application.

Actually, I have several loops, and there is a local variable called "End" to end all the loops. On value change events of each of these "exit" booleans, I pass True to End and it should end all the loops eventually. 

Highlighting the execution shows that on first click, the value True is passed to End, and it is passed to the loop ending also. But it doesn't end the loop. And I click again, and it ends everything. Strange. It didn't happen when I had Switch Until Released.

The terminals are inside their respective event blocks.

I don't need to click twice for other boolean controls, just this "exit" types. I have several of them because the user sees several pages at different times. But they all are capable to turn End flag ON, meaning triggering the loop ending process.

To solve this situation, I now update the End variable outside this event structure, but inside the parent loop. So the End variable is now updated only at one place, but could be from either of these buttons' events. Works fine! But don't know why it didn't work if I update End variable inside any of these events. There must not be any race condition, neither should it be waiting for updation from several controls. Value passed to it at any point should be sufficient. And if it required updation from all the locations, it wouldn't get updated upon 2 times clicking the same control.

Confusing again?