event structure with sub-VI

[Pac_LV8]

hi,

I designed a event-driven state machine UI that uses pop-up sub-VI for user date configuration and COM port config. Calling the sub-VIs works fine, but by closing them and sending back the modified data to the main state machine, the event handling routine stalls. With highlighting, I could verify that after returning from the sub-VI, the timeout event is being carried out as the only one (used because there is some background code to be processed repeatedly).

There are more buttons on the front panel then handled events in a certain state (the other buttons are used in other states), but the unused buttons are neither disabled nor hidden. Could that cause the problem? Or does the OK button of the closing sub-VI (or the changing data out of it) affect the main state machine event handler?

Thanks for your reply

Pac

[Kenny_K]

Are you using the event structure in a single while loop to amke your state machine, or are you using the event structure in a producer/consumer template??  I would highly recommend using the producer/consumer template if you are not already.  That will allow you to fire an event in the producer loop, that will then send in the information to the consumer loop and have the consumer loop open the subvi, while the producer loop "waits" for the next event.

When you press the OK button on the pop up subvi, that "stops" the subvi )i am assuming that it has a while loop) and then sends that data out to be used elsewhere, correct??

What si the background code that you are refereing too??  Is it running in the same loop or event as the subvi??  Or is it running in a seperate loop??

It should not matter that you have other buttons on your front panel and they are not used, you shouldnt need to disable them if you are running your subvi.

Is it possible for you  to submit your code??  It usually makes it easier to troubleshoot.

Kenny

[Pac_LV8]

hi Kenny,
thanks for your reply. I am not yet familiar with producer-consumer structures. What I did is a conventional case structure in a single loop. There are some cases where the UI waits for front panel action through buttons, but in the same case  structure, additional activity like reading or writing the serial port is also done. You can check the basic design of the VI in the attached state_machine.zip. I use a timed loop and remarked that the "finished late" flag is on when I return from a pop-up sub-VI (which is obviously correct, because the sub-VI blocks the event structure to finish).
Thanks in advance
Pac

[Jarrod_S.]

Hi Pac,

There are a couple ways to solve this. The best way is most likely using the Producer/Consumer as suggested. The idea there is to send messages to a parallel loop (the consumer loop) that launches the subVI or performs some other calculation. This does not hold up your main loop (the producer loop) because it only takes a very short time to send the message itself. You can find information on that design pattern here, and a basic template is also available directly from LabVIEW. Just select File >> New to bring up the template dialog and search under Frameworks >> Design Patterns.

Alternatively, you can launch your subVI without waiting for it to finish. Check out my post here on a similar issue. Hope this helps!

[Pac_LV8]

hi Jarrod,
thanks a lot for your reply. The second link looks like the right one for me... the VIs behave exactly like I want mine to. Now its just a little bit of handcraft
Thanks a lot again!
Pac

[Jarrod_S.]

Hi again,

I just wanted to point out there are some potential problems in your code as it is. In general I would recommend finding a way in your code to only have one event structure, rather than one in the startup and one in the running case as well. For instance, if the user presses Connect twice in your application, your front panel will lock up and become unresponsive. The reason is that you fired the Mouse Up event for that button, but no event case is ready to handle the event.

Check out this very comprehensive document on how to use event structures and things to keep in mind when doing so. It should really help out a lot! Also try searching the forums for other people's examples of Event Structure-driven state machines to see how they implemented it. A lot of people are fond of this design pattern. I hope this helps!

[Jason King]

Hi, Pac.  Looking at your original VI, I would make a couple of general comments:

1) I don't suggest using an event structure in a timed loop.  The timed loop is to ensure determinism in the code that is running. This doesn't really fit well with handling user interaction.  As suggested in other posts, I would have a separate loop that is watching for user interaction with an event structure.

2) Having different event structures in each frame of a case structure is asking for trouble.  The link Jarrod posted should be very helpful, but it is just a subset of the thorough documentation on using event structures (note: I may be a bit biased as I am one of the authors of the documentation :).  I would browse this whole chapter (http://zone.ni.com/reference/en-XX/help/371361A-01/TOC20.htm) and pay specific attention to the "Caveats and Recommendations" section which should help save you a lot of frustration.

J