LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

while loop & non-accessable stop button

I have a while loop inside a few casestatements.  I think I isolated the problem down to the while loop.  When the program enters the while loop, I am unable to use the exit 'stop' button, as well as the data field which the data is being received.  This seems like a pretty simple problem, and maybe I'm over looking something, but I've tried a bunch of different configurations and no luck.
 
I tried changing the button mechanisms, I've tried changing the sampling rate of the while loop (giving the cpu more time to recognize a button depress), but still nothing.  Setting the button to a false state before entering the loop will allow the program to run once, then loop back to the start of the case statement, where it waits for the user to choose whether or not to read (so I guess I know that the signals coming from the button work).  The problem is simply having access to use the button.
 
Without the button, my program stays in reading state, reading data off the TCP connection.  Honestly I have no idea why this won't work.  I attached a picture of my diagram, highlighting the problematic areas.
0 Kudos
Message 1 of 4
(3,073 Views)
Your code looks really well written! The style looks great, and believe me that's important...

Regarding your issue here, you are likely experiencing the problem that LabVIEW is locking the front panel until the event case completes, which is the default behavior. Unfortunately, your event case is set to run indefinitely, meaning the front panel will be locked indefinitely.

Read up a little on caveats and recommendations for using event structures. I know it doesn't sound like it, but the first item in the list corresponds to your situation. You can turn off front panel locking to avoid this problem, but a better scenario would be to simply trigger the code to start in your event case, but not wait for it to complete. The Producer/Consumer design pattern is great for this. It basicly involves a second loop (the consumer loop) that your event structure loop (the producer loop) sends commands to to do all the heavy lifting and processing. Meanwhile the producer loop always stays responsive to front panel interaction.
Jarrod S.
National Instruments
0 Kudos
Message 2 of 4
(3,066 Views)
You might not encounter this problem in your program... but is something that gave me a headache with the event structure. Especially be careful of it once you unlock that front panel... you might be queueing events, and not knowing.... which will execute on the next time that VI is re-entered.

Again... just throwing this out there.... trying to save as many people this headache as possible.

See what I mean here, for example VI.
0 Kudos
Message 3 of 4
(3,055 Views)

Thanks for all the tips.  I finally got the stupid thing to work.  After trying some of the queue'ing techniques, I finally went to check on locking/unlocking the front panel.  I found the location of this...

Right Click the Event Structure > Edit Events > 'highlight each event,' Unlock

 

Ahhh and everything works.  That was a day well spent.  Thanks again for the help.

Message 4 of 4
(3,040 Views)