Very strange: Front panel freezes in while loop and case structure sometimes

[pji]

I encountered a strange problem: when I run a while loop inside an event structure, the front panel freezes. I have been using similar structure many times, and they all worked fine. So I stripped the program down to bare minimum, and it still doesn't work. But when I stripped down a previously working program, it still works. I cannot figure out what might have happened. I run them on the same computer, same version of LabVIEW (I tried both 2013 SP1 and 2016, and got the same results).

Attached are 2 virtually identical simple test programs. After they are executed, the "Big loop" counter will start running. Then when you press "Run", the program starts the waiting loop until the "SET" is pressed. In the working program, the panel is working while waiting for the "SET" button to be pressed (for example, you can still change the A and B values. In the other program, the panel freezes, you cannot change A and B values, but the wait counter is running.

Any idea why such strange phenomenon happened? Thank you very much!

[aeastet]

THe first thing I see is that you have a loop inside of a loop. This is not a good idea. I made a few changes to your design and you can make it work this way.

[pji]

Thanks for your reply, Tim.

This sample program is a very stripped down version. The outer while loop is used with the event structure. I used the inner while loop to wait for the user to acknowledge (pressing the "Set" button) so that the program can proceed to the next step. The "Wait loop" counter is not really needed, it's just to show that the loop is running. I still need to find a way to wait for user's response.

Also, could you suggest why the other program worked? Thanks.

[aeastet]

That is what an event structure is for. It will not do anything until the user does something. You need to look into state machine and ques. What you are doing will get you into trouble and make it hard to take care of.

Your outer loop is not doing anything with the event structure inside of it unless you change the timeout value to something other than -1

[aeastet]

You can look into events as well. They may be a good way to get information back and forth between loops.

[pji]

Thanks again for your help, Tim.

My program is quite large and has been running for a while, so I prefer not to change the entire structure to state machine, etc.

My goal cannot be met with a simple event structure either, because after one event is triggered (such as pressing the "Run" here), the subsequent sub-tasks need to be executed one by one, with acknowledgement by the user along the way at various stages. The simple inner wait loop worked perfectly in the past, allowing the user to set some parameters, then press a button (such as the "Set" here) to move to the next step.

[aputman · Accepted solution]

Edit the event for Run and unlock the front panel.

[pji]

Thanks a lot, aputman. My bad. I forot to uncheck the "Lock panel". Now it's working as expected.

[billko]

---

@aputman wrote:

Edit the event for Run and unlock the front panel.

---

99% of the time unlocking the front panel to make the front panel responsive means you're doing something wrong.  In this case, you just shouldn't have a loop inside the event structure.  Fix this the right way, as others have suggested, by not having a loop inside an event structure.  This is a very bad habit to develop.

[aputman]

---

@billko wrote:

---

@aputman wrote:

Edit the event for Run and unlock the front panel.

---

99% of the time unlocking the front panel to make the front panel responsive means you're doing something wrong.  In this case, you just shouldn't have a loop inside the event structure.  Fix this the right way, as others have suggested, by not having a loop inside an event structure.  This is a very bad habit to develop.

---

I agree with everything you said here but the question was why the programs were not the same.