Pass Panel Close? Event to blocking Sub VI

[JScherer]

I've made a few sub VI's in a main VI to act as data input modules. Is there a way to have the "Panel Close?" button press of my main.vi trigger the blocking modules to exit? 

My best guess is below, unfortunately it does not work.

[RavensFan]

You need to start the subVI asynchronously so that the main VI can go back to work in its loop and handle the panel close event.  Or at least set the event structure in a separate loop so that it is not blocked by the loop that started the subVI.

Then you need a message scheme (queue?  notifier?) that can pass a message from the panel close event to the subVI.

[JScherer]

---

@RavensFan wrote:

You need to start the subVI asynchronously so that the main VI can go back to work in its loop and handle the panel close event.  Or at least set the event structure in a separate loop so that it is not blocked by the loop that started the subVI.

Then you need a message scheme (queue?  notifier?) that can pass a message from the panel close event to the subVI.

---

Fair enough, I was afraid of that.

I am a bit surprised I need a message scheme though. To clarify, even if I make the SubVI run asynchronously, this dynamic event wouldn't work?

[RavensFan]

In your subVI, you told it to discard that event when you wired up the True.

But even changing that to false doesn't seem to help.  Something very strange is going on in that the subVI seems to run twice when I click start blocker. 

[JScherer]

---

@RavensFan wrote:

In your subVI, you told it to discard that event when you wired up the True.

But even changing that to false doesn't seem to help.  Something very strange is going on in that the subVI seems to run twice when I click start blocker. 

---

Interesting, I think I have it set to run after INIT, before the Idle state starts, but that shouldn't cause two instances.

I did find a workaround that gets me about what i was looking for:

 

[johntrich1971]

The problem is that the Panel Close? event can only be assigned to one event structure. Since the event structure breaks data flow the main vi is already registered for that event, so it sees the event and not the subvi. You can see this by taking the Panel Close? event out of the main - your subvi will close properly. You could start the subvi asynchronously and pass it a user event, generating the user event inside the Panel Close? event in the main.

[Bob_Schor · Accepted solution]

When you have multiple sub-VIs running asynchronously, you need to designate someone as "The Master".  This is almost always the Top Level VI, as this is the one with the stable Controls and Indicators that should always be visible when the program runs (unlike sub-VIs, whose front panels are normally not displayed).

Here's a Good Rule (for LabVIEW and for Real Life):  The Master is In Charge, and says When to Quit.  This means that only the Top Level VI should have the "Stop" button, or the Panel Close? Event.  It is the job of the Master to inform his Asynchronous Slaves (there really is a "Master-Slave Design Pattern") that they, too, should exit.  This can be done by sending a "Quit" signal using some form of asynchronous communication, e.g. a Queue, Notifier, or Channel Wire.

But what if a Slave throws an Error and decides to Exit prematurely?  Ideally, it will send a message to the Master as part of its Exit routine, possibly commuunicating the nature of the Error.  Depending on the situation, the Master may find that all its Slaves have exited, and decide to exit, itself, under those circumstances.

At the recently-concluded NIWeek, I presented a talk about using Channel Wires that described such a Master/Slave design, all managed with Messenger Channels (mostly).  It was designed for 1-24 Slaves, with each Slave having a "sub-Master" and 3 "sub-Slaves", so there could be up to 96 simultaneously-running asynchronous Clones.  There were two ways the program exited -- if "Stop" was pushed on the Master, it sent an Exit message to its (24) Slaves, and each Slave sent Exit to its 3 sub-Slaves, shutting down everyone.  The more usual way, however, is that each Slave was told to run for, say, 2 hours, and kept its own Time Sheet.  When the Time was up, it told its Slaves to exit, then sent a message to its Master saying "I Quit!".  When the Master saw that all its (24) Slaves had quit, it also exited.

There was only one Event Loop, in the Master.  This has been working several times a week for a few years.

Bob Schor

[JScherer]

Bob,

Thanks for you in depth reply. I wish I could have been at NI week to hear your presentation. Maybe next year. Is there any location where I can see your presentation/code?