my vi is hung...how can I discover where it hangs without running it over and over

[Hummer1]

After my vi performs some of the tasks it is asked to do (all by events), when pressing the next button (latch type) that should create a new event, the button stays down (is never read by the event) , the event does not trigger.  The previous event seems to complete all its functions but doesn't seem to allow other events to be started.

any thoughts.

[Mark_Yedinak]

Could you pot your code? It is hard to determine what is happening without seeing the code.

[Hummer1]

Sorry, but can't post the code....

Think of it as a vi front pannel with 3 latch buttons tied to 3 events in a while loop.  One of the buttons is a stop button, triggering a stop event that stops the while loop.  When running, you press button 1...event one functions...performing a stacked structure of tasks...which all seem to complete....BUT...when you press button 2...to cause event 2 to trigger, the button stays in the T state, does not cause event 2 to trigger and no other front pannel action is possible...

???

[johnsold]

Have you used execution highlighting to watch what happens? Or put breakpoints into the code to pause it when it reaches a certain place. 

It is generally not a good idea to have code in an event case which could take more than a few milliseconds to execute. Producer/consumer architecture may be better suited to what you are trying to do.

Lynn 

[Mark_Yedinak]

Have you tried turning on execution highlighting? From the sounds of it sounds like you are getting stuck inside your event 1 task and not really exiting it. Also, as a general suggestion stacked sequences are generally frowned upon. You are much better off using a state machine. It is much more flexible and extensible. Another option would be to use a producer consumer archittecture and when the event triggers notify (using a queue) the consumer task, which is usually a state machine, to process the event. At a minimum I would turn the code from each of your frames into a subVI and then simply wire all the subVIs together.

[JÞB]

OK event two is detected- you can tell by the front panel being locked that an event is being handled.

Is there pehaps an infinate loop in the event?  

[smercurio_fc]

Also make sure the button terminals are inside the event cases so LabVIEW can reset them once read.

[Hummer1]

I am doing lots of stuff in each of the events...perhaps that is the problem...What is the problem with wrapping lots of work into an event...?

The second event is never being triggered...perhaps the first event is "hung" although all the stacked work is complete.

I don't understand how to make an event queue and then refer it to sequences that have to be performed.  can you give me a reference to a paper or discussion of that technique.   The work has to be sequenced as it is dependent on responses from other vis which must complete their work on certain variables before new steps can be taken....so there is a lot of flag passing and waiting in timed loops.

thanks.

[Hummer1]

Yep...buttons are in the event to be read and reset.

thanks.  (I've missed that before....)

H

[JÞB]

HOLD On you said thee LATCHING booleans  AHHA! and a value change event

Make 'em switchers.  The first thing to do in the event would be to read the old val and use a property node>Value (Not Value(Signaling)) to reset the boolean.  Latching booleans don't play nice with value properties because of the way latching is handled in the guts of the complied code.