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

[Hummer1]

I have a vi.  It is "waiting for front panel activity".  I cause some front panel activity by pressing a control...and the vi functions.  I then press the same button again and the vi hangs, the front panel does not respond to any mouse activity.  When I run the highlight execution function it shows that the case controled by the value change of the control executes to the end in the true case, but then there is no further action anywhere on (in) the vi.

How do you find out what the vi is waiting on to proceed, or which element "has the ball" so to speak.

Thanks

Stopped Humming for a while.

[altenbach]

---

Hummer1 wrote:
How do you find out what the vi is waiting on to proceed, or which element "has the ball" so to speak.

---

Well, that's a bad analogy, because LabVIEW is multithreaded and there could be many balls in play at the same time. 😄

Can you attach your VI or alt least provide much more detail? Are you exclusively using the "wait for front panel activity" primitive, or do you also have event structures?

[Hummer1]

I can't attach the vi.  It consists of a while loop which contains a wait for front panel activity and a stop control to the while stop if true.  It also contains two event structures.  One event structure handles the control mouse down which I described before.  The other event structure contains the response to another front panel control when it changes value.

[TCPlomp]

Two event structures and a 'wait for front panel' activity in one while loop?
That sounds like the major reason.
Try to merge the two event structures.

Ton

[altenbach]

Hummer1 wrote:

I can't attach the vi.  It consists of a while loop which contains a wait for front panel activity and a stop control to the while stop if true.  It also contains two event structures.  One event structure handles the control mouse down which I described before.  The other event structure contains the response to another front panel control when it changes value.

If all event structures are in the same loop, the loop iteration cannot complete until ALL event structures have fired. This is the core of dataflow. if you have an "wait for front panel activity", you should not have any event structure in the same loop. You also should have only one event structure per loop. You can add several event cases to the same structure for ultimate flexibility.

Message Edited by altenbach on 06-18-2008 11:52 AM

[Hummer1]

Got it....so...

If I put all the front panel controls in the loop with the wait for front panel activity, and all the event structures in another loop...(using multiple event cases to sort out which event to deal with, that should do it?

Thanks ...

I am making a lot of progress for a beginner at this, but am still confused about some of the "basics".

Back to humming.

[altenbach]

If you have event structures, you usually have no longer any need for "wait for front panel activity". This was more of a cheap bandaid solution before the introduction of the event structure. 😉

Many front panel operation don't need to trigger any events or do anything, so spinning the "wait for activity loop" everytime something is clicked is a total waste of resources.

You should create events only for  things that really do something while other controls (e.g. configuration) don't need to be serviced by any event. The control will keep the data until it is needed by the code.

Here is an example:

You need to set aquisition parameters (rate, # of points, etc.) then press a button to start acquisition. None of the paramter settings need any events or need to spin any loops. Once start is pressed, their last settings will get read from the terminal anyway if the code is layed out correctly. And so on....

[Hummer1]

Thanks...that helps a lot.

I'm confused about triggering events using front panel controls and triggering them using the property node value(signaling).  The property node value(signaling) doesn't seem to trigger a value change event like the action taken by activating the control on the front panel...should it?  Perhaps I had some other problem going on that masked this action, but I wound up having to make sure that the front panel controls were in a while loop that was either polled with a clock or by a wait for front panel activity.  Even then, when the property node value(signaling) was changed, you had to execute a Generate Front Panel Activity for the event to be processed.

Did I miss something?

Thanks for taking time to straighten me out...as you can see, I need all the help I can get.

Humming softly.

[JeffOverton]

A Value(SGN) node will change the value of a control or indicator as if the user had clicked on it, but only in regards to events.  So this will trigger events, but it will not trigger a front panel activity node.

So if you have an event structure with two or three user events, the structure will wait until one of those events happens before executing and allowing the loop to spin one more time.  It will then wait again for one of those user events, etc.  Another option is to have some kind of status update in the timeout event, which will happen whenever the specified number of milliseconds go by without a user event.

[Hummer1]

Ok, I finally have duplicated the kind of problem I am having in a simple vi.  (attached.)

The objective is to trigger an event when the control is pressed.  (you can't use latched control action with events, so the control stays True until you reset it as part of the event structure)...BUT...If you reset it using Value(Signaling) it creates another event which causes the false case to run...If you reset it using Value (change to read)...the buttons state is now False....and the next time you press the button...the Value change event DOES NOT occur...(well, if it occurs, it doesn't trigger the value change event.)

This is probably something simple...and fundamental...and I'm sorry to bug everybody about it...but ....

Well you know what I mean.

Thanks.