when a vi hangs...how do I find out what it is waiting for?

[johnsold]

You can use latched mechanical action with events. I do so all the time. But, the terminal needs to be inside the event (or at least somewhere so that it will be read).

Generally you do not need the Wait for front panel activity if you have an event structure. The event structure can be set to capture the activity.

Here is a modification of your VI which uses 2 buttons with latching actions. I added the numeric indicator to show when the loop runs.

Lynn

[altenbach]

You have an interaction with "wait for front panel activity" and the event structure.

The wait for front panel activity has no purpose here, delete it!

Basically, each click on OK queues up two events, but only one can get serviced because it stalls at the wait for front panel activity (the value(sgl) does NOT trigger a FP activity). On the average, you allow one loop spin while firing two events with each click, leading to a buildup of events.

You can easily use latch action boolean with events, you just cannot use them with value signaling properties or local variables.

Also there is little reason to reset it with a signaling property, a plain value property or local variable will work just as well and will not trigger an extra event.

In summary.

• Delete the "wait for front panel activity"!
• Use latch action boolean!

[Hummer1]

Got it...

Thanks a ton.

Use Latches.  Put them in the events...read them with something(?)

get rid of the wait for front panel activities.

Hummin.

[Hummer1]

Johnsold,

Thanks for the sample modification.

Strangely enough ... it seems to work with the ok button inside OR outside the event.

Really Hummin now.

[johnsold]

If the OK button is outside the event structure but still inside the while loop, it will be read when the loop iterates. Once it is read, it will reset to the default value. If you move the button outside the loop, the event will work but the button will not be read and will not unlatch.

Lynn

[Hummer1]

Got it.

I tried it both ways.

The event fires both ways...AND...the button seems to unlatch ...  Perhaps if the button was in a different while loop (which as established earlier would need some sort of polling or wait for front panel action ... which is undesirable...(Got it...Alt. ..thanks.) from the event it wouldn't but it seems to be read when the event causes the while to run once.

I'm not suggesting that putting the button inside the event it is causing is not the right thing to do, I'm just noticing that there is some reason for us novices (I'm speaking for myself here...) to, on occasion, (read ..."almost continuously") be confused.  Thanks for the help.

By putting the button inside the event loop it seems to do away with the need for the case sturcture to sort out the T/F status when latching is used as well...taking off another layer of the onion.  As I learn how these things "like" to be done, things seem to be getting simpler.  It's a very visual thing, and I like that aspect.

Hummin.

[johnsold]

Often the best way to figure these things out is to try something, but if you are completely confused then trying may be just a random shot.

One key to understanding what is happening with the button is the concept of dataflow. In LabVIEW things can only happen when the data is ready. A loop will only go the the next iteration after everything inside it has completed. A latched button only resets when it is read.

So in the case of a VI with a button outside a loop and an event structure handling the Value Changed event for that button inside the loop, the button will be read when the VI first starts to execute. The loop also starts and immediately begins to wait for an event. Either the loop or the button might be read first. If there is no data dependency between them you have no way of knowing. Because of the wait both the loop start and the reading of the button will have happened within nanoseconds of starting the VI. When the button is pressed, the event case will execute and the loop will proceed to the next iteration where it will wait for another event. However, the button outside the loop has not been read again, and never will be until the VI is stopped and restarted, so the button does not unlatch.

If the button is inside the loop, it will be read on every iteration of the loop. If it is inside the event case for its Value Changed event, it will be read when that case executes.

If it is inside the loop but inside, say, the Stop button Value Changed event case, then what happens? The Button Value Changed event still works fine, but the button will not be read (and thus, unlatched) until the Stop button Value Changed event occurs.

Try these variations on my VI. Run with highlight execution on and watch what happens.

Lynn