Race condition(?) between Main VI and SubVI in Subpanel and othe

[nikvl]

Hi all,

so I have a Main Vi which has a Subpanel on it. When a button is pressed, a Sub Vi is inserted into it. (I used the Run VI property node before Insert VI rather than Call by Reference). Some of the Main VI indicators are linked to the Sub vi's indicators. The inserting and removing of Sub VI works so far (except for when I want to reinsert/switch between different Sub Vis but that's a different problem altogether)

When Highlight Execution is switched on, I'm able to interact with the different button controls of the Sub Vi (Start, stop, etc.). When the Highlight Execution is switched off however, the controls of the Sub VI don't respond anymore and when I remove the SubVI from the subpanel, the Sub vi doesn't stop running despite programatically trying to use Ctrl Val.Set to set the Stop button in the Subvi to True. Even when I stop the main vi, the sub vi is still running in the background and when I open it, it no longer respond to the controls even though I'm directly interacting with it rather than through the Subpanel so in the end I would have to forcibly abort it.

I realise this is a few-fold problem....

1) There seems to be a race condition between my Main vi and Subvi through the Subpanel (Inserting and changing wait times in the while loops doesn't seem to help)

2) Once the Sub vi has been called by the Main vi through the SP, some reference seemed to be blocked and I can no longer interact with the Sub vi even when I open the Sub VI. (The sub vi is always closed before running Main and calling it in the SP, otherwise it will not run)

3) How is it possible to reinsert the SubVI after removing it? Do I make the Subvi a reentrant (I've never used reentrant vi's before...)?

I've attached simplified versions of the programme 

I kinda want to avoid using Tab Control...

[paul_cardinale]

Your subVI has an event structure that captures value change events on the Start and Stop buttons.  A Value Change event on a button is triggered by:

• Changing the value by clicking on it

or

• Writing to the Value Signalling property

Any other method of changing the value (e.g.using Ctrl Val.Set) will not trigger a Value Change event.

[nikvl]

I see. I assumed that writing a True boolean would change its value.

Is there another way to trigger the stop button of the Sub Vi from the Main vi then? 

I'm super reluctant to use Abort VI because it will most probably not close my DAQ Tasks properly...

[Ben]

---

@nikvl wrote:

I see. I assumed that writing a True boolean would change its value.

Is there another way to trigger the stop button of the Sub Vi from the Main vi then? 

I'm super reluctant to use Abort VI because it will most probably not close my DAQ Tasks properly...

---

What you did not see is Paul indicating a "value Signaling" node to trigger the event.

Ben

[wiebe@CARYA]

---

@nikvl wrote:

I'm super reluctant to use Abort VI because it will most probably not close my DAQ Tasks properly...

---

You should be. Abort VI is a terrible thing to use in applications.

---

@nikvl wrote:

Is there another way to trigger the stop button of the Sub Vi from the Main vi then? 

---

That has been answered: value signaling.

But it is the wrong question, IMHO. The question should be: "Is there another way to stop the Sub VI from the Main vi? "

Triggering the stop button will work just fine. But when the application grows, you'd probably want to use a user event, or several user events to trigger stop and other events with one mechanism.

An alternative would be a channel wire. IIR, a few of them allow triggering events from the channel wire. Haven't done it, but it might be a bit faster to setup.

[Bob_Schor · Accepted solution]

Wow!  I can't even open your VIs (in LabVIEW 2018 or 2019) without rendering LabVIEW "unresponsive" and needing to close!

Some comments:

• The simplest (and perfectly safe) way to stop a Sub-Panel routine is to put a Stop button in its Front Panel and have "the usual code" in the sub-VI where pushing Stop stops the routine.  Depending on how the Main interacts with the Sub-Panel (for example, is the Main sending "commands" via a Queue to the Sub-Panel, including an "Exit" command?), there may be alternate ways to stop it.  However, you should (probably) not have the Main try to "push" the Sub-Panel's buttons.
• Another way to start the Sub-Panel code running is using Start Asynchronous Call.  This lets you pass in arguments to your Sub-Panel's VI to start it running.
• A handy function when dealing with sub-VIs is OpenG's "Fit VI Window to Largest Decoration".  You can draw a Frame decoration around the part of you Sub-Panel VI that you want to see in the Sub-Panel (leaving, for example, Error In and Error Out outside the Decoration).  You can measure the Decoration and make your sub-Panel window the same size.  If you now put "Fit VI Window" as the first VI executed in your Sub-Panel code, when you call the Sub-Panel, the VI's "Decorated" Front Panel will exactly fit in the Window without your having to adjust anything.  OpenG can be found on the LabVIEW Tools Network (I recommend installing the OpenG Toolkit, which brings in the most useful of the OpenG tools) -- you'll use VIPM to interact with the Tools Network.

Bob Schor

[paul_cardinale]

---

@Bob_Schor wrote:

Wow!  I can't even open your VIs (in LabVIEW 2018 or 2019) without rendering LabVIEW "unresponsive" and needing to close!

Some comments:

• The simplest (and perfectly safe) way to stop a Sub-Panel routine is to put a Stop button in its Front Panel and have "the usual code" in the sub-VI where pushing Stop stops the routine.  Depending on how the Main interacts with the Sub-Panel (for example, is the Main sending "commands" via a Queue to the Sub-Panel, including an "Exit" command?), there may be alternate ways to stop it.  However, you should (probably) not have the Main try to "push" the Sub-Panel's buttons.
• Another way to start the Sub-Panel code running is using Start Asynchronous Call.  This lets you pass in arguments to your Sub-Panel's VI to start it running.
• A handy function when dealing with sub-VIs is OpenG's "Fit VI Window to Largest Decoration".  You can draw a Frame decoration around the part of you Sub-Panel VI that you want to see in the Sub-Panel (leaving, for example, Error In and Error Out outside the Decoration).  You can measure the Decoration and make your sub-Panel window the same size.  If you now put "Fit VI Window" as the first VI executed in your Sub-Panel code, when you call the Sub-Panel, the VI's "Decorated" Front Panel will exactly fit in the Window without your having to adjust anything.  OpenG can be found on the LabVIEW Tools Network (I recommend installing the OpenG Toolkit, which brings in the most useful of the OpenG tools) -- you'll use VIPM to interact with the Tools Network.

Bob Schor

---

That reminds me: A long time ago, I made this.

[nikvl]

That has been answered: value signaling.

But it is the wrong question, IMHO. The question should be: "Is there another way to stop the Sub VI from the Main vi? "

Triggering the stop button will work just fine. But when the application grows, you'd probably want to use a user event, or several user events to trigger stop and other events with one mechanism.

An alternative would be a channel wire. IIR, a few of them allow triggering events from the channel wire. Haven't done it, but it might be a bit faster to setup.

I know many have suggested the Value Signaling node...but I just can't figure out how to get the Value Signaling property node of the Sub vi to link it to the Stop button of the Main vi without placing the entire SubVi into the Main Vi (which defeats the purpose of a Subpanel bc I could just have the FP of the SubVI pop up...).  Could you maybe show an example? Thank you in advance!

I'm inexperienced with user events. How would I go about creating one? Would I need separate user events for the Main and the Sub VI?

---

@Bob_Schor wrote:

Wow!  I can't even open your VIs (in LabVIEW 2018 or 2019) without rendering LabVIEW "unresponsive" and needing to close!

Some comments:

• The simplest (and perfectly safe) way to stop a Sub-Panel routine is to put a Stop button in its Front Panel and have "the usual code" in the sub-VI where pushing Stop stops the routine.  Depending on how the Main interacts with the Sub-Panel (for example, is the Main sending "commands" via a Queue to the Sub-Panel, including an "Exit" command?), there may be alternate ways to stop it.  However, you should (probably) not have the Main try to "push" the Sub-Panel's buttons.
• Another way to start the Sub-Panel code running is using Start Asynchronous Call.  This lets you pass in arguments to your Sub-Panel's VI to start it running.
• A handy function when dealing with sub-VIs is OpenG's "Fit VI Window to Largest Decoration".  You can draw a Frame decoration around the part of you Sub-Panel VI that you want to see in the Sub-Panel (leaving, for example, Error In and Error Out outside the Decoration).  You can measure the Decoration and make your sub-Panel window the same size.  If you now put "Fit VI Window" as the first VI executed in your Sub-Panel code, when you call the Sub-Panel, the VI's "Decorated" Front Panel will exactly fit in the Window without your having to adjust anything.  OpenG can be found on the LabVIEW Tools Network (I recommend installing the OpenG Toolkit, which brings in the most useful of the OpenG tools) -- you'll use VIPM to interact with the Tools Network.

Bob Schor

---

I'm working with Labview 8.0 32-bit...

1) The Stop button in the Sub vi works fine when I am running JUST the Sub vi. The point of the Main vi's stop button controlling the Sub vi's stop button is so I can stop it cleanly before I remove it from the Subpanel without necessarily stopping the Main (I could insert another Subvi into the Subpanel etc.)
2) The reason why I chose Run VI was because I read somewhere that you can't interact with the Sub Vi while it is running in the Subpanel if I were to use Asynchronous Call

3) If you did manage to open the VI you will see I did exactly just that for the Sub VI....

Thanks for all the tips you guys, but it doesn't answer the main question of why I can't interact with the Sub vi's controls in the Subpanel unless I'm in Highlight Execution mode......

[wiebe@CARYA]

---

@nikvl wrote:

I'm working with Labview 8.0 32-bit...

---

I'd prefer to use LV5 (or actually any version, including NXG) over LabVIEW 8.0.  It's inadequacy is legendary.

You'd do yourself a favor by at least upgrading to 8.2.

[nikvl]

I'm working with Labview 8.0 32-bit...

I'd prefer to use LV5 (or actually any version, including NXG) over LabVIEW 8.0.  It's inadequacy is legendary.

You'd do yourself a favor by at least upgrading to 8.2.

Well, unfortunately that is out of my hands...