Unwanted behaviour when removing a RUNNING top-level VI from subpanel

[Intaris]

I ran into a weird behaviour yesterday which I was amazed I hadn't noticed before.

If I insert a VI into a sub-panel and remove it later, normally everything is fine.  IF however, the VI I have inserted is a running top-level VI then the act of removing it from the sub-panel will abort the VI.  I would expect this kind of clean-up only if the VI was not currently running.  Why on earth is aborting a VI a valid decision when simply changing the VIs method of being displayed.  Note that closing the FP of the VI in question does not stop the VI running so it's not that.

Can someone please explain why the aborting of a perfectly valid running VI needs to be performed just because I'm removing it from a sub-panel?

And yes, I'm aware of a workaround which I have already implemented.  But the fact that I NEED a workaround would hint at a bug or at least very questionable intended behaviour.

Shane.

[Norbert_B]

Shane,

do you have a simple example for this? (Kinda lazy to create one myself 😉 )

Due to the help for "Remove VI", the VI should keep running, so it looks like a bug. So: Which version of LV is this happening?

Unloads the VI in the subpanel control. If no references to the VI remain, LabVIEW removes the VI from memory. If references to the VI remain and the VI stays in memory, this method does not change the state of the VI.

thanks,

Norbert

[Intaris]

Hi Norbert,

here's a small example to show this.  This is all with LV 2012 SP1 (32-bit) on Win7 64-bit.

Start "Sub item 1.vi" as a top-level VI and then run "Load Unload.vi".  You can load the FP of "Sub item 1.vi" (closing the FP to allow insertion) and everything is fine.  When unloading, however the VI exits from memory even though it SHOULD still be running.

If you start "Sub item 1.vi" as a process from another VI (and thus a reference remains in memory, the VI will continue running after removing from the Sub-Panel.

It sure feels like a bug.

Shane.

[Thoric]

In my Model View Controller architectures I regularly replace a subpanel view with one of any number of running VIs, depending on the view the operator has chosen. When switching between views, all are kept running and none are ever exited. These are all top-level VIs (I think) because they're launched asynchronously, so they have no parent call chain. Therefore, I don't see what you're describing in my own code. I'll check out your example and see if anything looks obviously different to my own code.

[Thoric]

---

@Intaris wrote:

Hi Norbert,

here's a small example to show this.  This is all with LV 2012 SP1 (32-bit) on Win7 64-bit.

Start "Sub item 1.vi" as a top-level VI and then run "Load Unload.vi".  You can load the FP of "Sub item 1.vi" (closing the FP to allow insertion) and everything is fine.  When unloading, however the VI exits from memory even though it SHOULD still be running.

If you start "Sub item 1.vi" as a process from another VI (and thus a reference remains in memory, the VI will continue running after removing from the Sub-Panel.

It sure feels like a bug.

Shane.

---

In your example, when you Insert the subitem VI you're also closing its reference, so there's no longer a reference to the VI handled anywhere. Therefore, when you Remove the VI from the subpanel, it's no longer an owner and gets closed. If you remove the "Close Reference" from the Insert, it remains in memory after being removed from the subpanel. Is this a sufficient workaround?

In my own reference handling I always keep a reference to every asynchronous VI open somewhere, to ensure they can't be dropped from memory when no longer visible.

[Intaris]

As said previously, yes I can workaround it and I have implemented it so.  Indeed the help describes exactly what happens.  The matter is whether a top-level VI (which is running) should NEED a reference open to prevent it from being disposed of.  There's also no guarantee whatsoever that the VI inserting the aforementioned VI into a subpanel is even the same VI which launched it in the first place.

The question is: Should removing a VI from a subpanel abort a running VI without explicitly being told to do so, no matter how many or how few references are around.

My suggestion would be to check not only if there are still references open but also whether the VI is running or not (i.e. top-level).  In that case I fail to see the use case of actually aborting the VI.

[Thoric]

---

@Intaris wrote:

The question is: Should removing a VI from a subpanel abort a running VI without explicitly being told to do so, no matter how many or how few references are around.

My suggestion would be to check not only if there are still references open but also whether the VI is running or not (i.e. top-level).  In that case I fail to see the use case of actually aborting the VI.

---

I can see how this is tricky. If a VI has open references it shouldn't be removed from memory, any open reference necessarily keeps a VI open.

It also doesn't matter which VI opened it if it was performed asynchronously because after that there's no link between them.

Regarding the question: "Should removing a VI from a subpanel abort a running VI?" I would say no. I would prefer the VI's reference to be returned from the "Remove VI" function so that it can be subsequently handled as we see fit. Thus, if we want it to exit we can abort it and close the reference. If we don't want it to exit, we can store the reference.

[Intaris]

This is also exactly the solution I would most like to see implemented.

I believe there's an idea on exactly that point.  I'm off to vote.

Shane.

[Norbert_B]

---

@Intaris wrote:

[...]   When unloading, however the VI exits from memory even though it SHOULD still be running.[...]

Shane.

---

Shane,

point is, that there are specific criteria for a keeping the VI reference.

•Three things can keep a VI in memory

−Open caller

−Open VI reference

−Front panel is open

(Excerpt from the Advanced Architectures class)

Let's check:

- Open caller: This refers to static calls which keep the reference. As you close the reference explicitely after insertion of the VI into the subpanel, the caller doesn't have a valid reference anymore.

- Open VI reference: Same as caller.

- Front panel is open: As you close the FP before moving the VI in the subpanel control, there is no front panel open.

So, you have no valid reference to the sub item 1.vi in memory when removing the vi from the subpanel, as the subpanel control was the last one to keep the reference.

OK, it is an arguable situation. I think that two options could be "suitable", but require NI to change things in LV:

a) If a top-level vi is inserted as subpanel, but the panel is closed (which is essentially for getting it in the subpanel), it loses the state "Top-level" and becomes "Running". This would probably the preferred option.

b) If the top-level vi is removed from the subpanel, it will immediatly re-open its front panel to continue to keep a valid vi reference.

The "clean" solution is, as thoric suggests, keeping a valid reference in the calling VI on purpose and closing it only if the vi should be removed from memory.

hope this helps,

Norbert

[Intaris]

---

@Norbert_B wrote:

•Three things can keep a VI in memory

−Open caller

−Open VI reference

−Front panel is open

---

I see now what the problem is.

If I have a top-level VI running and I have no open callers of a Reference open to the VI and I close the FP the VI is removed from memory even though it is still running at that time.  I know this has been like that for a LONG time but I still find the reasoning somehow wrong.  I feel that the fact that the VI is currently running should have some effect on whether the VI is simply aborted or not (no cleaning up of device references, no proper shutdown, just nuked).

Thus removing the VI from the Subpanel is actually the same as doing the same operations on the top-level VI anywhere in LabVIEW.  I have just tested this and to be honest, I'm surprised LV acts like this despite my nearly 20 years working with it.

So the take away message is closing the FP of a top-level VI is the same as aborting the VI.

My proposal?  A top-level VI should inherently (without intervention by the user - handled in the background by LV) possess a reference to itself.  Anything other than a top-level VI should behave as now.

I can get along with the current implementation but am interested to know WHY the current implementation is deemed correct.

Shane.