window events infinite loop

[dgholstein]

I've got a "do while" loop connected to a boolean (switch when pressed), while it's pressed down, it loops; click on it again to off, it stops looping -- everything works well.

The main body of the VI is in an (window) event driven loop, the "do while" loop from above is both started, and controlled by the clicking of the boolean.  All the events work well, close window - close application; ctrl-O - open data; ctrl-Q - close application; again, everything works well.

The problem is, when looping, if the user fires an event loop before hitting the boolean and stopping the "do while" loop, the window will no longer react to any events at all, it becomes an infinite loop.  The only way to terminate is by using "Task Manager" to terminate LabView.

What's up with that?

   ...Dan

[RavensFan]

Perhaps you should post your code.

Did you create an event in the event structure for the for a value change on the Boolean stop button?  Perhaps put a timeout on the event structure so that the loop will occasionally iterate to handle other tasks?  I don't think you have an infinite loop, probably just the event structure waiting on the event to fire again.  A lone boolean stop button will get read early in the iteration of the loop.  so the event structure is waiting for the event.  If you hit the Stop boolean, it won't get read again until an event fires completing that iteration of the loop.  Then in the next iteration, the stop button will get read, but the loop won't complete because it will again be waiting on an event, once the event occurs, then the loop will end because the Stop will be true and all other code inside the loop will have completed.

[dgholstein]

The code is very long with several custom DLLs, but I've included this screen shot.  The boolean, "Tune", is the subject here.

   ...Dan

[Ben]

Tune has tp be true to enter the loop and the loop continues while Tune is true so you have coded it to run forever or until an erro occurs.

Ben

Message Edited by Ben on 05-28-2008 01:46 PM

[dgholstein]

I don't see how you can say that, Ben.  Normally, it works perfectly, I click "Tune" and it loops, click again and it stops, that doesn't define it as being "programmed as an infinite loop".

It is only if the sequence is buggered up that it becomes an infinite loop.  If I trigger an event, such as choosing a menu item, before terminating the "do while", it then becomes infinite.  Maybe I should trap/kill events that aren't related to pressing the "Tune" boolean.

[altenbach]

Is the tune event set to "lock front panel until event completes"? If this is enabled (the default) you will not be able to operate the button while the event is active

In any case, this is not pretty code to poll a boolean inside an event assigned to the same boolean. 😮

[Ben]

watch your code in execution highlighting mode and re-create the hang condition.

If the event you showed us is not what is hanging then please show us what it is doing prior to the hang.

Do you have a Time Out Event structure that will let the while loop spin when no event is being fired?

Ben

[dgholstein]

No, the panel is not being locked -- just for giggles I tried locking it and that would definitely be programming an infinite loop.

I'm not even using the "Set Busy.vi", which I use often.

[TCPlomp]

---

@dgholstein wrote:
I've got a "do while" loop connected to a boolean (switch when pressed), while it's pressed down, it loops; click on it again to off, it stops looping -- everything works well.

The problem is, when looping, if the user fires an event loop before hitting the boolean and stopping the "do while" loop, the window will no longer react to any events at all, it becomes an infinite loop.  The only way to terminate is by using "Task Manager" to terminate LabView.

---

Could you elaborate a little bit more on this.
What works, and what doesn't. (I don't fully understand 'event loop')

I assume event loop is one of the other events, does the other event finish? Is any of the events locking the FP?

On the shown code, after an error 1 additional run of the while loop will happen.

Wait this workflow isn't working:

-Tune=true event, locks the event structure
-Open event (can't execute, could lock the FP)

Ton

[dgholstein]

Ben, there is the standard, blank, timeout event where nothing happens.  It's never fired since, as you can see from the screenshot, is not enabled with a finite timeout value.

Anyway, for giggles (even though I new nothing would change), I wired a 1000 ms timeout and put a 1 button dialog within the timeout event, and the bad behavior didn't change (except for having to hit the 1-button dialog every second when the "Tune" loop wasn't running)