subvi stalling on reuse

[Leeser]

Hi all,

I have a problem with a subvi stalling in reuse inside a larger state-machine like system. Basically, the subvi gives the user two choices OK and cancel. On selecting OK the subvi closes and outputs the next state for the state machine to follow. On selecting cancel, the subvi closes and the state machine goes into idel mode. When the subvi is called again, the two buttons, OK and cancel are visible but can't be pressed/clicked and the system hangs.

I have attached a much simplified version where I put the subvi in a stae machine like loop-case structure to illustrate the problem.

If you work on the subvi outside of the stat machine loop, it works perfectly each time (it gives the next state and closes...).  I have the feeling it is something related to reinitialisation but explicity making the buttons enabled didn't seem to help on 2nd pass.

Can anyone spot the error? is it something very simple I have missed. I appreciate any help on this matter.

Regards,

Leeser

[PiDi]

This might be something very simple, but first you must provide me with example which is a least functional, not with the one with missing subVIs 😉 Could you also clarify, how do you call this VI you attached? Or is it the top-level VI and this missing subVI is making a problem?

[RavensFan]

You have OK and stop buttons.  I don't see the cancel button you refer to.

Having an event structure inside of a case structure is often a bad idea.  Event structures are always waiting on events, even if they are not in the path of execution.  If you never get back to the case that contains the event structure, then that event will never get services.

You have your event cases set to lock the front panel until the event is complete.  A setting like this makes the situation I just mentioned even more critical.  Because now the front panel will lock up, and you have no means of clicking any buttons that might help the code progress to the case where it can service the event structure and the events.

[Leeser]

forgot to upload the subvi that is causing the problem...

[Leeser]

I have just added the subvi that is missing. iwould be grateful if you look at the example for me again...

Regards,

Leeser

[Leeser]

I have just added the subvi that is missing. iwould be grateful if you look at the example for me again...

Regards,

Leeser

[Leeser]

I have just added the subvi that is missing. iwould be grateful if you look at the example for me again...

Regards,

Leeser

[RavensFan]

One thing to watch out for with subVI's you call that have the "X" button enabled on the window.  It will close the subVI, but the subVI will actually still be running in the background, which can cause problems when you try to call the subVI again.

Be sure to either disable the "X" button in the subVI's properties, or use an event structure with teh Panel Close? event set up to discard the event and stop the VI cleanly.

[PiDi]

Ok, this is exactly what I expected. Never use two event structures inside one loop - this leads to unexpected behaviour, as we witness here. Remove the event structure from "initial" state and everything will work. Another workaround is reconfiguring event cases so they won't lock front panel - uncheck this option in event configuration (see attachment), but I'd really advise you to remove excess event structures and always use single one.

[RavensFan]

Yes.  That is the problem.  I hadn't noticed that there were two event structures in that subVI.  Both are set to capture the OK button value change, and both are set to lock the front panel.  As a result, the front panel won't be unlocked until both event structures have executed and serviced the event.  Your code probably never gets to the other event structure because of the way the state machine is written.

Even if you did set both event structures to not lock, you'll probably still have unexpected behavior.  Because when you do do something to get to the other event structure, it will service the OK button event that occurred some time ago, which is probably not what you want it to do.

Caveats and Recommendations when Using Events in LabVIEW - LabVIEW 2011 Help