push button problem

[thentangler]

Hi all,

I have a peculiar problem with my push buttons on my front panel. I have set it up so that when the button is pressed, the readings get saved in a file. I have set up the mechanical action as Switch until released. It works fine until sometimes, it gets stuck and stays in the pressed state. When i click on the button in the pressed state, it becomes un-pressed as long as the mouse button is pressed, and then becomes pressed back when the mouse button is unclicked. Even when I abort the program and rerun it, it stays in the pressed state. I have to close the VI and reopen it for it to reset. 

Any idea what might be causing this problem or how to go about this?

Thank You

[P@Anand]

It would be better if you can post the code. You should have set your push button status as ON by default so thats why when you run the code it keeps on in the ON state and when you click that it goes to the Un-pressed state. Make it OFF(Un-pressed) and set that value as push button's default value your problem will get solved.

Good luck

[GregFreeman]

Let me guess, you have local variables for that button in your code. Am I correct? If so, you have a race condition, which we can't help with if we don't see the code.

[Norbert_B]

---

@thentangler wrote:

[..]Even when I abort the program and rerun it, it stays in the pressed state. I have to close the VI and reopen it for it to reset. [..]

---

You shouldn't abort your program, it could lead to unexpected future behavior.

You can press the button once during edit time (VI not executing) to "toggle the button".

Possible sources of the described behavior:

- Using event structure, but button is not part of its event case

- Using property nodes/variables

- Having a timing issue in the code (aka race condition) which prevents the UI from updating properly from time to time.

Norbert 

[RavensFan]

Are you sure "Switch Until Released" is the mechanical action you want?

That means it is only down while the person is actively holding it down.  That is an unusual behavior for a button intended for saving things to a file.  It would be more typical of a motor control application where you want it to behave like a jog button.

For a file save function, I would use "Switch When Released".  There you press the button once to turn it on.  Then it will stay on.  Then you press the button again to turn it off.  Then it will stay off.

[mc_vibraphone]

I'll echo the 'show the code for best results,' but broadly, take a look at every other place you might write to a local variable or property node linked to that button, and see if there's any alternate or parallel code path that could hit at the same time as you're managing the button state for your read file functionality.

- Tom

[thentangler]

Hi all,

Thank you for all the responses and suggestions. I did not add the code because it contained many subVis from an instrument driver, but i did take a snapshot if the affected code anyways and attached it. 

I know I can un-press it in the edit mode, but I am converting it to an exe and using it in a machine that does not have labview so I cant go into edit mode. Before you think that, that might be the problem, I have faced this situation even while doing check runs in the computer im programing on. And then I go into edit mode and un-press it.  

I havent used any timing, nor have i used a local variable for that button. However, as Norbert suspected, I have used it in an event structure. So the structure waits for the button to be pressed, and the moment its value changes, it exectues the associated code within the structure. I have also wired the button to come out of the while loop and exit the program. So the Button does two things. The moment it is pressed, it saves the file and then exits the program.

Now I suspect that this might be the problem and you are free to shoot it down if you think it silly:

The instrument generates almost 500 to 600 datapoints, and that is being fed into the write to spreadsheet vi. Since I have coupled both the saving and the exiting to the same button, do you think that the program is exiting before it can save that huge amount of data to the spreadsheet?

If so, what is an elegant method around it? I want the program to save the file and then exit when i click the save button.

[GregFreeman]

Unfortunately it's still hard to say from the picture you showed. Just attach your code without the subVIs and drivers; most people here can probably help without actually running it, they just need to see it all. The program can't exit before the file write is complete. This contradicts dataflow. The case of your event structure will not exit until everything in that event case is done executing. So, there is no way the loop can exit until that event case is done running (unless you are hitting abort). If you have no local variables, for this situation I would suggest using "latch when pressed" instead of switch. See if that fixes your problem. The latch function is what a user would expect to see anyways.

[thentangler]

ok here goes 🙂

I know its messy, and there is probably a LOT I could have done to make it more effecient. But I have no background of labview and I had to learn and write this program in 2 weeks. Actually I owe most of it to you guys, since without your help I would not have been able to finish my program. 🙂

[RavensFan]

One problem you have is that you have 2 event structures occurring in the same while loop.  And some of these are set to lock front panel until event case completes.

Your while loop can't iterate again until an event from each event structure has occurred.  So until an event from structure A has occurred, and an event from Structure B the loop won't run again.  You do have a data dependency which means an event from A has to occur before the event from B can execute.  But the problem is that additional events from B can keep getting queued up even though B is not yet in the path of execution.

On top of that, the cases in B lock the front panel until they complete.  Which means you might never be able to do what you need to do to trigger an event in Case A.  Now you have a catch 22.  B can't run because A hasn't completed, but A can't run because B has captured an event and locked the front panel.

You just need to step back and rearchitect your program.  Most programs can fit within a state machine architecture.  And make sure you only have 1 event structure in the while loop.

I'm sorry to say, but what you have right now is a mess and it is just pure luck if it ever runs correctly for you.

Why the program locks up is that when you press down, it triggers the event, can't execute yet because its not in the path of execution, and when you let go, it never detects that because the front panel is locked.

(Plus like I said, you should probably have Switch When Released as your mechanical action rather than Switch Until Released.)

 Caveats and Recommendations when Using Events in LabVIEW.