Subpanels: what are the rules for order of operations?

[Aristos Queue]

I would like to run a VI, open its panel Hidden, execute it to update all its indicators and then display that VI's panel in a subpanel.

 

Can I do that? Or does a VI have to already be running before it goes into a subpanel? Do I have to close the panel before I put it into the subpanel? I think there's at least some special cases because I've burned myself a few times in the past trying to set up similar situations. I just don't do UI work often enough for it to stick in my head, so I figure someone here who does UI regularly knows what I have to do to get as close as possible to what I want to achieve.

 

PS: After I put the panel into the subpanel, can I close the reference or do I have to keep it open so that the VI stays in the subpanel? If I don't close it and then put a different panel into the subpanel, will the subpanel close the reference for me?

Edited November 7, 2015 by Aristos Queue

[Neil Pate]

You certainly can run the code as you wish.

A VI does not need to be running to be inserted, but if you do this and then run it there is a nasty transition when the VI changes to running.

The refs are not related at all. The subpanel will not do anything with the inserted VI ref. Inserting a different VI does not destroy the original VI ref. You can get a ref to the inserted VI from the subpanel. Hold onto the VI ref if you want to do other stuff to the VI like aborting it etc

[drjdpowell]

Or does a VI have to already be running before it goes into a subpanel? 

If you executed it, then it must be reserved for running, so the “nasty transition†Neil mentions doesn’t apply.  

 

Do I have to close the panel before I put it into the subpanel? 

 

Yes.   I put Close Front Panel before Insert VI (I ignore any error from the Close, thrown when it was already closed).

 

PS: After I put the panel into the subpanel, can I close the reference or do I have to keep it open so that the VI stays in the subpanel? If I don't close it and then put a different panel into the subpanel, will the subpanel close the reference for me?

 

You can close the reference.  The subpanel doesn’t (I don’t think) ever close the reference itself.

[Aristos Queue]

Yes.   I put Close Front Panel before Insert VI (I ignore any error from the Close, thrown when it was already closed).

If I run it with the panel hidden and then close the panel to insert it into the subpanel, that's going to reset all the values to default values, isn't it?

(that's what it seems to be doing for me... maybe I've still got something wrong.)

[Neil Pate]

You just need to hide the fp, not close it.

[drjdpowell]

If I run it with the panel hidden and then close the panel to insert it into the subpanel, that's going to reset all the values to default values, isn't it?

(that's what it seems to be doing for me... maybe I've still got something wrong.)

Does it?  Closing isn’t the same as unloading.  Is your VI reserved-for-execution?  If it is, I don’t think closing the FP unloads it or resets anything.

[Aristos Queue]

Ah... I didn't have any property/invoke nodes on this particular VI, nor did I have anything special set in VI Properties... of the various reasons to hold the FP in memory, none existed from LV's point of view. I just need some sort of static property node to signal "hey, I'm doing UI stuff with this thing." Probably a rare use case -- most UIs are going to have *some* property work. 

[shoneill]

Just a note of warning depending on what the VI should do when it leaves the subpanel....

 

Due to the fact that the FP must be closed before entering into the subpanel, if you happen to close the reference you used when inserting, then upon exiting the subpanel, the VI will abort (Closed FP, no managed references in memory).  As long as the VI is in the subpanel, the subpanel seems to manage it's own reference to the VI.  I suppose this would suggest that yes, the subpanel closes a reference to the sub-VI when the sub-VI exits the subpanel.

 

This can be a bit surprising when you come accross it the first time (and I still think it's not ideal behaviour to be honest).  You have to babysit that original reference until the VI has left the subpanel, had its FP set to not closed and then and only then can you close that VI reference.  Or you can open a new reference just before removing, set the FP to "hidden" and then close the reference whereupon the VI will continue running.

Edited November 9, 2015 by shoneill

[CraigC]

Hi,

 

I am doing precisely this at the moment.

 

My Order of Operations are. Open VI reference->  Write control Values-> Insert VI in subPanel -> Run VI (Auto Dispose Ref = TRUE).

 

Craig

[drjdpowell]

This can be a bit surprising when you come accross it the first time (and I still think it's not ideal behaviour to be honest).  You have to babysit that original reference until the VI has left the subpanel, had its FP set to not closed and then and only then can you close that VI reference.  

For async VIs** I use ACBR with option 0x80, which, like Run VI with Auto Dispose Ref = TRUE, means the VI never aborts like this.  

 

**We don’t seem to be talking about synchronous subVI calls here, but for those I just use a static reference (which cannot be closed).  

[shoneill]

@drjdpowell,

 

That I was not aware of.  That's quite an interesting tip.  I was also unaware that the Run VI with autodispose set to TRUE would actually prevent this behaviour.

 

Edit: The Open Vi Reference followed by "Auto Dispose" TRUE only seems to work if I wire in a strict VI Reference constant with the correct connector pane.  If I do a generic "VI Open" without the VI Type being specified, the VI will still auto-abort when leaving the sub panel even if "Autodispose" is set to TRUE.

 

So the method to avoid the VI auto-aborting seems to be linked to the usage of a strict VI reference when opening the reference and less the method used afterwards.  Good to know.

 

Testing done in LV 2012 SP1.

Edited November 9, 2015 by shoneill

[OlivierL]

Due to the fact that the FP must be closed before entering into the subpanel, if you happen to close the reference you used when inserting, then upon exiting the subpanel, the VI will abort (Closed FP, no managed references in memory).  As long as the VI is in the subpanel, the subpanel seems to manage it's own reference to the VI.  I suppose this would suggest that yes, the subpanel closes a reference to the sub-VI when the sub-VI exits the subpanel.

 

I wouldn't say that the subpanel "closes a reference" but rather than LabVIEW does its basic job of stopping the execution of a VI which already had no opened references and no longer has a FP opened, which, as you suggested, was the main reason for keeping it running in the first place.

@drjdpowell,

 

So the method to avoid the VI auto-aborting seems to be linked to the usage of a strict VI reference when opening the reference and less the method used afterwards.  Good to know.

 

Also, on the "Strict VI Reference", I believe that it actually loads the VI in memory during execution and therefore, creates the reference that keeps it running in the background. This does the exact same thing as putting the VI as a subVI elsewhere in code executing.

[drjdpowell]

@drjdpowell,

 

Edit: The Open Vi Reference followed by "Auto Dispose" TRUE only seems to work if I wire in a strict VI Reference constant with the correct connector pane.  If I do a generic "VI Open" without the VI Type being specified, the VI will still auto-abort when leaving the sub panel even if "Autodispose" is set to TRUE.

 

That’s surprising to me, but then I haven’t used the Run VI method in years.   I only use ACBR, which always required a strict reference.

[shoneill]

Also, on the "Strict VI Reference", I believe that it actually loads the VI in memory during execution and therefore, creates the reference that keeps it running in the background. This does the exact same thing as putting the VI as a subVI elsewhere in code executing.

This is true.

 

By replacing a strict VI reference (Browsing for the path and setting to Strict Typed) with a Generic reference of the same type (Also strict typed, but not linked to any specific position on disk) the VI is again aborted when removed from the subpanel.  So even using the ABCR is not a guarantee.  It's having the strict reference on the BD that keeps the VI in memory afterwards, so essentially no surprises there.

 

[OlivierL]

I just cannot reproduce the behavior that you are describing. I've never really used the ABCR as I prefer use the Run Method instead but I played with it this morning.

 

I tried with both with a non re-entrant VI and with a re-entrant VI using option 0x80 and both VI keep running in the background (infinite While loop) even after closing the reference and removing each from the sub panel. It appears to me that the ACBR has the equivalent of "Auto-dispose VI Ref" set to "True" as the VI runs even if  the reference is closed in the caller and the FP is also closed.

 

In your test, does your VI called with ABCR keeps running or does it stop executing? Is it set to re-entrant?

[shoneill]

I can't reproduce it today either.  I don't know what it is I saw last week.

 

I give up.  I just ran the same code which gave me clear results last week, and now using the ABCR, both code versions do NOT abort the vi as you say.

 

I still see that not having a static ref to the sub-VI anywhere in memory and using the "Run VI" method always aborts the VI, even if the "Auto dispose" is set to true.  So it appears to be a plain "Run VI" vs "ABCR" thing.  Note: Even putting the strict reference in a disable structure keeps the reference in memory, you really need to remove it fromt he code altogether.

 

But having said all of that, I could have sworn the results I saw last week were clearly different.  Must be getting old.

[drjdpowell]

I am reminded of this Eyes on VIs video, and how it matters whether or not one closes the VI reference when using Run VI.  Don’t know if this helps.

[OlivierL]

I still see that not having a static ref to the sub-VI anywhere in memory and using the "Run VI" method always aborts the VI, even if the "Auto dispose" is set to true.  So it appears to be a plain "Run VI" vs "ABCR" thing.  Note: Even putting the strict reference in a disable structure keeps the reference in memory, you really need to remove it fromt he code altogether.

As suggested by James, are you closing the reference after the "Run VI" call?  you must not.

 

Similarly, is it possible that you don't close your reference anymore in your test using the ACBR? That might explain why they stay in memory.

[shoneill]

Here are three VIs for testing which show a difference in behaviour between ABCR and Run VI.

 

In the Run VI version, after removing the sub-VI fromt he subpanel, it is aborted.

In the ABCR version, the sub-VI keeps running after being removed.

 

In BOTH cases I close the references after inserting into subpanel.

 

You may need to change the path of the control on the FP in order to find the sub-VI.

 

Can anyone else confirm that the ABCR sub-VI still runs after removing whereas the Run VI sub-VI does not?

subpanel test ABCR.vi

subpanel test RunVI.vi

Blinker.vi

[ensegre]

Like you say, LV2014SP1 linux. The lifeline of Run VI dies either that Auto Dispose is on or off.

[shoneill]

Can you also confirm that the ABCR versions do NOT die when removed?

[Neil Pate]

Yes, it works like that on my LV2015. The heartbeat light thingy keeps on blinking until the top-level VI is stopped.

[ensegre]

Can you also confirm that the ABCR versions(?) do NOT die when removed?

So it is. The lifeline keeps blinking. It stops only when I press the stop button, or if I reopen the FP of the blinker and abort it (maybe obvious but foolprofing).

Edited November 17, 2015 by ensegre

[OlivierL]

Can you also confirm that the ABCR versions do NOT die when removed?

Yes it keeps running.

 

So why does the ACBR keep running in your case and not the "Run VI"? My guess comes from different implementation of the two methods. Whereas "Run VI" launches the Sub VI as a Top Level VI, "ACBR" actually creates a proxy (Use "Call Chain" in your SubVI to see this). That special Proxy VI then calls the SubVI as a subVI instead of a top level VI. Therefore, another references is created (in the Proxy) to the subVI so even if you close the original reference, the Proxy keeps running and keep Sub VI in memory.  In the case of RunVI, if you close the reference, then the SubVI (Running as "Top-Level") becomes identical to any other Top Level VI and stops since no reference is opened and FP is closed, stops its execution.

 

I ran another test and I was surprised by the result; If you do not close the reference, in both cases, Blinker.vi keeps running (I removed the error from the Queue stopping the While loop) in the background. I thought that it would be aborted by the ACBR ("Run VI" actually runs as a top level VI so I expected it to behave as such, with no knowledge of the VI who launched it.) I assumed that the Proxy's reference would be tied to the calling VI but it is not. Moreover, the behavior (Blinker.vi keeps running) is the same whether you close the original reference or not! "Proxy" appears to have no knowledge of the caller ("subpanel test ABCR.vi") status. Now that I think about it, I guess this makes sense as it is the behavior I've seen within the Actor Framework where the Actors keep running in the background under certain debugging cases.

[shoneill]

Olivier, reading your post made me realise something (it happened magically by reading the words you wrote!).

 

Launching an ABCR requires some mechanism to retain a reference somewhere so that at a later stage we can get the results back using the "collect" functionality (the proxy you refer to).  This would indeed seem the most likely candidate why the "Run VI" and "ABCR" are fundamentally different in this regard.

Edited November 18, 2015 by shoneill