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

[altenbach]

Switch until released should turn false when you release it (similar to a car horn). If it does not, you probably have some race condition with local vaiables. Again, attach some code that show the problem and we will tell you want you are doing wrong.

---

Vaibhav wrote:

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?

---

Please attach a simplified version of your code. It seems you are doing all this way too complicated.

What is the mechanical action of the END boolean? (hopefully not "switch until released"!). If you have event structures, you don't even need locals. You can have multiple events listeing to the same boolean (see e.g. Stopevent.vi discussed here).

[Vaibhav]

As I wrote, even after removing all the local variables, the Switch Until Released didn't turn back to false.

End is not a control, it's a boolean indicator, just to creat a local variable.

Yes, I don't need local varaibles for those boolean controls. I thought I needed, to check status, but in fact, I have indicators whose status I check.  

Agree with your idea of using event structures in different loops to end them. Another trick. But I don't need it now, as I cannot put event structures in all these loops, because they have different processes and putting event structures would just make them unnecessarily bigger. I had several event structures in different states of my state machine, which I just combined into one.

so here I am just updating one indicator, and its local variable is passed to these loops to stop them.

Simplified code...? hmm.. lemme try.

[Vaibhav]

Ok,

I have simplified the code to show the bugging behaviour. The front panels are not beautiful, neither is the BD, but they are clean enough to see the data flow.

The three VIs show the three types of behaviour that I have discussed in the messages above. Their names are enough descriptive to have an idea.

1. Client_Switch_problems shows that Switch Until Released do not bring back the state of the boolean controls. There is no Local Variable used for the boolean controls.
2. Client_Latch_problematicExit shows that after converting into Latch bahaviour, the program does not end upon the first click. You have to click two times, any of the exit buttons, to end the program. 
3. Client_Latch_correctExit is the corrected behaviour after I put End variable out of the event structure.

Looking forward to hear the comments.

Although I have got a workaround, I want to know "the reason" so putting this effort.

[altenbach]

---

Vaibhav wrote:

2. Client_Latch_problematicExit shows that after converting into Latch bahaviour, the program does not end upon the first click. You have to click two times, any of the exit buttons, to end the program. 

---

Sorry, I am only on a laptop, so there is no way to really debug your code, which needs a much bigger screen. I need to constantly scroll around just to switch between cases.

Here's an eay one for point 2.

The local variable at (2) gets read in parallel to the event structure, i.e. before the code at (1) writes the new value, meaning that the loop will only stop at the next iteration. To avoid the race condition, you need to make sure that the loop condition gets the updated value after the event structure has executed.

The image show one of the cases. You can delete most locals and wire from inside the event structure as follows.

In case 1 with the switch action, the problem is probably similar.

Message Edited by altenbach on 09-13-2009 02:22 PM

[Vaibhav]

Exactly that's what I have done, in the 3rd version above, and that works fine.

Thanks for the confirmation that it was the proper way to do it!

Sorry for the big loops. In hurry I missed to shrink it. I am using two screens, a laptop + a 1280x1024 LCD, combined to work on this code. But if you just keep that event structure on your screen, that should be sufficient on the laptop screen.

For the 1st case, looking only at the event structure is fine, because in the first state of the outer loop, some initialization happens which you may need to scroll down to, but main part is in that event structure.

Curious for the 1st case, as that was the main issue.

[Vaibhav]

Hi,

Could you look into the 1st case (Client_Switch_problems)?

[altenbach]

---

Vaibhav wrote:

Could you look into the 1st case (Client_Switch_problems)?

---

It's exactly the same problem.

1. use a plain "switch when pressed" mehcanical action. (Since there is no guarantee how long the user will be pressing the button with "switch until released", there is no guarantee if the lower loop ever sees a TRUE.  
2. fixt the dataflow by eliminating unneeded locals as before
3. Reset the boolean after the lower loop has completed.

[Vaibhav]

---

altenbach wrote:

It's exactly the same problem.

1. use a plain "switch when pressed" mehcanical action. (Since there is no guarantee how long the user will be pressing the button with "switch until released", there is no guarantee if the lower loop ever sees a TRUE.  
2. fixt the dataflow by eliminating unneeded locals as before
3. Reset the boolean after the lower loop has completed.

---

1. If we change the mechanical action, then the question ends, because we are talking about why Switch Until Released wouldn't function as expected.

2. There are no locals for the booleans in question.

3. You are suggesting this due to Switch when Pressed action selection. But if we use Switch Until Released, we shouldn't need to reset explicitely.

Ok, I would explain where is the problem. Please follow these steps (they look big in text, but they are quick, I promise):

• If you run the program, Client_Switch_problems.vi, and click on START in the first page.
• If you have Datasocket server running on your computer (or if you pass url of a remote DSserver in the string in block diagram), then you should see the 3rd page which has Connect and Exit buttons.
• If you press Connect, you should see next screen where there is Disconnect.
• Now if you press Disconnect, you should see the previous page (with Connect button) again, but you see the state of Connect button is "pressed" which should be unpressed or unswitched.
• Again, click on Connect (it will become false now, but Value change event will take place as it should), it will show you that Operation page again with Disconnect button.
• Notice the state of the Disconnect button. It is still the same "pressed" since you clicked it last time.
• Click on it and you should see Connect button, this time Off (because of the last click there).

Clicking several times on Connect/Disconnect, you should see the faulty behaviour I am talking about.

One more thing, the Value Change Event occurs twice upon each single click. This IS A problem or perhaps I am missing something.

I liked your suggestion about Latching. I already implemented it for cases where I don't need to use Local variables. But what abt Switch Until Released?

I would post it for Bug detection, but thought to discuss it first. Perhaps I am missing something.

Message Edited by Vaibhav on 09-17-2009 05:42 PM

[Rocko2k7]

I am currently working on a project that interfaces with an oscilloscope, and have recently ran into this problem.

I have about 6 buttons on my front panel and whenever a button is pressed, it will stay pressed even though its mechanical action is "to latch when released". I have no local variable reads for the buttons. Anyone found a way to get the buttons to "unpress" after they complete the action?

Each button is tied to a different "event" in my event structure.

I'd appreciate any help.

Thank you.

[RavensFan]

Do you have the terminals for those buttons in the event case that is associated with them?

Latch action buttons don't return until their terminals are read in the code, which means you want them to be in the event case that is handling the button press.