Completely stumped by the behaviour of user event

[AlexA]

So in the course of my tinkering, I came up with this gem:

The time out case of the event structure contains nothing.

So, here's what happens. If there is a timeout wired, the stop button (passed via local variable from the upper loop) causes the program to stop, but the "data calibrated", which is basically junk but should also stop the program, doesn't. (Even if you add something like a set true to a local variable corresponding to the upper loop stop. Basically, with a timeout value wired in, the "Data Calibrated" event is never handled (wire a simple indicator to the button to observe).

If no timeout is wired, data calibrated works but the stop button obviously doesn't.

Why does this happen?

I've read through everything I could find in the labview help searching for something to do with this behaviour, but couldn't parse any useful information out of it.

Edited September 28, 2011 by AlexA

[AlexA]

I achieved what I was trying to do by having no timeout and writing the stop condition of the stop loop to a property node (value(signalling)) linked to the control bool.

Still don't know why having a time out causes the control to become unresponsive.

[asbo]

Upload the VI.

[jgcode]

I achieved what I was trying to do by having no timeout and writing the stop condition of the stop loop to a property node (value(signalling)) linked to the control bool.

Still don't know why having a time out causes the control to become unresponsive.

Just guessing:

Is it because you are not initializing that local variable and you have a race condition?

.

[Ton Plomp]

Could you upload the VI, since I don't understand what you want. Your message title mentions User Events, while your code doesn't show any, you post mentions 'Data Calibrated', but your code doesn't show something like that.

Ton

[drjdpowell]

First thing to do is put a Wait in the upper loop, which is currently running at max CPU and starving other processes. That might have strange effects.

[jcarmody]

I'm confused by the behavior of the two boolean buttons. If I start this and hit 'Stopped? 2' the VI exits as I'd expect. If I start it and hit 'Done Calibrating' once the corresponding indicator updates and the VI will stop after hitting 'Stopped? 2'. If I start it and hit 'Done Calibrating' more than once the FP won't respond to clicks on 'Stopped? 2' and needs to be aborted. Execution highlighting shows that the bottom loop has stopped and the top loop is still spinning.

I added the Wait function because sometimes the bottom loop beat the top loop to the 'Stopped?' indicator/local.

EDIT - changing the Event Structure to not lock the Front Panel for this event fixes the issue. I expected that the Event Structure wouldn't have any more influence once it executed and the loop stopped...

Edited September 28, 2011 by jcarmody

[jcarmody]

Apart from the cause for the unexpected (to me) behavior, I think the solution involves using only one loop to handle FP interaction.

[Ravi Beniwal]

... If I start it and hit 'Done Calibrating' more than once the FP won't respond to clicks on 'Stopped? 2' and needs to be aborted.

Turn off "Lock front panel..." for the Done Calibrating:value change event and this will be fixed.

When you hit Done Calibrating once, it shuts down the event handling loop. When you click it again, it locks the FP until "this event case completes", but the event never gets a chance to handle this event again and the FP never gets unlocked. That's why you can't click on Stopped? 2.

[jcarmody]

Turn off "Lock front panel..." for the Done Calibrating:value change event and this will be fixed.

Thanks, I understand that. What I don't understand is why the Event Structure locks the FP after 'Done Calibrating' has stopped the bottom loop.

[drjdpowell]

What I don't understand is why the Event Structure locks the FP after 'Done Calibrating' has stopped the bottom loop.

'Cause you hit the button again. Stopping the loop doesn't stop the event queue inherent to the event structure. It locks the front panel, as instructed, until the event is handled. That it will never be handled because the loop is stopped is immaterial.

[Ravi Beniwal]

It was the while loop around the event structure that finished execution. The event structure is put inside the while loop so that we can give it a chance to handle more events that might have occurred since its last execution. By not returning control to it, we took its ability to handle the events away.

I see your point too! It probably should have locked down the front panel once it started handling the event and then should have unlocked it, once it was done. But I'm not sure if this is the behavior we really want. Let's say the loop is busy handling one event and you click a button, which is supposed to lock down the FP. If the FP is not locked down right away, you could generate many other events before the button click event case gets a chance to execute. To avoid this, you could enable locking down FP for the current event. But then, where do you stop? This strategy would have to cascade through all the events, because you won't know when a user might throw in a couple of clicks.

Ideally, this shouldn't even be an issue because your event handler should receive all FP events and then send them for processing elsewhere. The event loop should finish only when the VI is "on its way out" and at that time, the FP should be not be expected to let you interact with it.

[AlexA]

Thanks Jcarmody for clarifying and putting up that code. Time zones meant I was asleep!

Anyway, the reason I wanted two means of stopping, was that the program can receive shut down messages from another section of the code and also from the user when they're looking at the front panel. Either way should shut down the code with a single button press.

[Ravi Beniwal]

Anyway, the reason I wanted two means of stopping, was that the program can receive shut down messages from another section of the code and also from the user when they're looking at the front panel. Either way should shut down the code with a single button press.

You could use the value (signalling) property of your Done Calibrating button to stop the event loop in response to the shutdown message from the other section. That way the same button can respond to the user click as well as outside messages.