Prevent unwanted aborting of VI in a Sub Panel

[wiebe@CARYA]

You can't use InsertedVI.

That sounds silly, and it is.

InsertedVI doesn't returns a reference to the instered VI, but the actual VI. So if you use InsertedVI, and the VI that used it stops, or closes the refereence, the VI is removed from the subpanel, and the subpanel will be messed up until you restart LabVIEW.

This could be a cause of your trouble.

This might be fixed in LV23 or LV23, but I doubt it as I don't recall NI ever acknowledged this problem.

---

@OsamuTakeuchi wrote:

Note that the VI reference obtained from "Inserted VI" property is not identical to the one that is given to "Insert VI" function. So, even after closing the VI reference obtained by "Inserted VI", the original VI reference remains valid.

---

For as long as I know, InsertedVI is tight very closely to the original VI. Even if the reference is different, something in LabVIEW is very, very wrong and using InsertedVi will ruin everything.

Here's a simple showcase:

The SubVI is a simple new VI with a loop counter looping.

The VI in the subpanel will stop updating, and when you open the VI, it's not in the subpanel anymore, but there's still a front panel kn the subpanel. Note that this VI is not reentrant, so something is just wrong.

[OsamuTakeuchi]

Hi, wiebe@CARYA,

---

wiebe@CARYA さんは書きました:

---

@OsamuTakeuchi wrote:

Thanks for your interest to my post.

But unfortunately I do not see how your post helps solving my issue.

Do you suggest not dynamically started VIs do not suffer from the problem?

---

If you can find out a way to avoid dynamically starting VIs, then yes, it will solve a lot of your problems.

Working around problems can be a solution to problems 😎.

For instance, if you have multiple values you could use a tree and only allow editing one at the time by selecting single items in the tree.

"the problem" means the problem on this topic.

---

@OsamuTakeuchi wrote:

By the way,

My goal is to have generic way to access values of controls.

As suggested above, I use multiple Sub Panels that load instances of a same VI.

---

I'd never use a template. In stead, I'd use a reentrant VI. The intent of a templates is to get a starting point for developing a VI.

Actually, I was first using reentrant VIs.

But when VIs are unexpectedly unlinked from Sub Panels, reentrant VIs opened with 0x100 option are not cleanly terminated and caused errors when the VI is restarted.

From this experience I feel using .vit is easier and safer for testing this issue.

@OsamuTakeuchi wrote:

I write a test code as simple as possible just enough to reproduce the issue.

---

I'll have a look, but your code doesn't run as the owning library isn't in the zip...

---

Excuse me.

I repeat failing to attach files...

I hope I make it this time.

[OsamuTakeuchi · Accepted solution]

I summarize this topic from the conversation up to now.

Environment

tested with LabView 21.0.1 (64bit)

Title of the topic

The title of this topic should have been

   "Prevent unwanted unlinking of VI from a Sub Panel"

instead of

   "Prevent unwanted aborting of VI in a Sub Panel"

because the VI is not necessarily aborted.

Observed problem

Assume that the "Inserted VI" property of a Sub Panel on a VI is read from another VI, then the Sub Panel stops working at the moment when the latter VI terminates.

Cause of the problem

Reading "Inserted VI" property has a side effect: the read VI reference is marked as "to be closed at termination" even when it should not be closed.

When the VI reference obtained from "Inserted VI" property is closed, the embedded VI is unlinked from the Sub Panel, which causes the appearance of the Sub Panel freezes and the controls on the Sub Panel stop working. Meanwhile, the unlinked VI may continue working background.

Additional information

According to GerdW, we can not avoid the side effect of reading "Inserted VI".

When a VI reference is given to "Insert VI" function of a Sub Panel, a new VI reference is opened for the VI and the newly opened reference is stored in "Inserted VI" property.

So, closing the original VI reference does not affect the Sub Panel.

Closing the reference read from "Inserted VI" property unlinks the VI from the Sub Panel.

If any reference of the VI is valid, just unlinking from the Sub Panel does not kill the VI. The unlinked VI continues working background.

Workaround

Reading "Value" property of VIRefNum control has no such side effect.

So, if we store the reference of embedded VI to a VIRefNum control, another VI can read that value safely.

Preferable behavior

LabView should not mark the VI reference as "to be closed at termination" when it is read from "Inserted VI" property.

Instead, LabView should mark the VI reference as "to be closed at termination" when it is opened in "Insert VI" function.

[OsamuTakeuchi]

Hi, wiebe@CARYA,

I overlooked your third post.

I agree almost all your opinion but I do not know "something in LabVIEW is very, very wrong and using InsertedVi will ruin everything" is true or not.

I can say closing the reference read from InsertedVI must be avoided but it is unnecessarily closed when VI is terminated.

So, InsertedVI can be safely used only from a VI that has a lifetime equal to or longer than the embedded VI in the Sub Panel.

Reading InsertedVI property from the VI that owns the Sub Panel will not cause any problem.

[OsamuTakeuchi]

I summarize reproduction steps of my observation with the content of "test-subpanel4.zip" attached above:

1) Sub Panel stops working when another VI that accessed its InsertedVI property terminates.

2) This is because the VI reference read from InsertedVI property is closed at VI termination.

3) Closing the VI reference causes the inserted VI unlinked from the Sub Panel.

4) Even after unlinking, the once-inserted VI continues working and is even re-insertable to the Sub Panel. (According to wiebe@CARYA, the front panel of the unlinked VI is in an ill state.)

1. Run "main.vi". It loads two instances of "sub.vit" into the two Sub Panel's, respectively.
2. Run "access.vi" and press "Access InsertedVI property" button. It reads the name of the VI inserted into the first Sub Panel on "main.vi" using the InsertedVI property.
3. Abort "access.vi" while watching the "Valid" indicator on "main.vi".
   At the moment when the "access.vi" is aborted, the indicator turns off, which indicates the VI reference stored in InsertedVI property becomes invalid. After that, counting up in Sub Panel stops and the Numeric control in the Sub Panel is not working any more.
4. Confirm the number in "Control Value:Get" indicator continues counting up. This value is read from the inserted VI using "Control Value:Get" function of the inserted VI.
   This means the inserted VI is working background even after unlinking.
5. Press "Insert Again" button. This inserts the original VI reference to the Sub Panel again.
6. Confirm the "Valid" indicator turns on and the Sub Panel gets back to working.

5) Accessing value property of VIRefNum control does not mark the VI reference as "to be closed at termination".

1. Restart "access.vi".
2. Press "Access Indicator value". It gets the name of Inserted VI by using the VI reference stored in the VIRefNum indicator named as "Inserted VI" on "main.vi".
3. Confirm aborting "access.vi" does not cause the Sub Panel stop working.
   Reading VI reference from the Value property of VIRefNum control does not mark the reference as "to be closed at termination."

[wiebe@CARYA]

---

@OsamuTakeuchi wrote:

Hi, wiebe@CARYA,

I overlooked your third post.

I agree almost all your opinion but I do not know "something in LabVIEW is very, very wrong and using InsertedVi will ruin everything" is true or not.

---

I do. Look at the simple example I posted. InsertedVI can't be used without suffering the consequences. Note that the failures that are shown are only the obvious failures. Who knows what's happening behind the scenes. If I see 2 panels of a non-reentrant VI, it's bad...

---

@OsamuTakeuchi wrote:

Hi, wiebe@CARYA,

I can say closing the reference read from InsertedVI must be avoided but it is unnecessarily closed when VI is terminated.

---

Or when you close the reference yourself. Avoid InsertedVI altogether.

---

@OsamuTakeuchi wrote:

So, InsertedVI can be safely used only from a VI that has a lifetime equal to or longer than the embedded VI in the Sub Panel.

Reading InsertedVI property from the VI that owns the Sub Panel will not cause any problem.

---

Suit yourself. 

I still consider InsertedVI as evil. It doesn't work as it should even in trivial cases and until it does, I won't use it.

I've build (proprietary) dynamic grids and dynamic front panels. But I didn't use InsertedVI 😉.

[OsamuTakeuchi]

Hi, wiebe@CARYA,

---

wiebe@CARYA wrote:

---

@OsamuTakeuchi wrote:

Hi, wiebe@CARYA,

I can say closing the reference read from InsertedVI must be avoided but it is unnecessarily closed when VI is terminated.

---

Or when you close the reference yourself. Avoid InsertedVI altogether.

Why do you close it?

I believe the VI reference obtained from "InsertedVI" property does not have to be closed and actually must not be closed in a user code.

When you avoid closing it, do you really see any problem?

[wiebe@CARYA]

---

@OsamuTakeuchi wrote:

When you avoid closing it, do you really see any problem?

---

No I don't see any problem, but I do expect problems as the method works in unpredictable (and unknown) ways.

The reference returned by InsertedVI simply doesn't behave like a reference should behave. There's no other way to get a reference that behaves like it either. Closing a reference should not close the object, and these references seem to have that effect. So I don't use it at all and recommend other not to use it. 

If you use InsertedVI in a sub VI, you created a sub VI with 'special instructions'. Basically a time bomb, set to go off when you least expect it. When you start using that sub VI in dynamic VIs (very likely as combining SubPanels and Dynamic VIs is likely), you get the close automatically when the top level dynamic VI stops...

[OsamuTakeuchi]

Hi, wiebe@CARYA,

Actually I would not like to use InsertedVI very much because it is problematic in some known cases but at the same time I want to be analytic.

---

wiebe@CARYA wrote:

---

@OsamuTakeuchi wrote:

When you avoid closing it, do you really see any problem?

---

No I don't see any problem, but I do expect problems as the method works in unpredictable (and unknown) ways.

It's a good news that no issue has been known.

The reference returned by InsertedVI simply doesn't behave like a reference should behave. There's no other way to get a reference that behaves like it either. Closing a reference should not close the object, and these references seem to have that effect. So I don't use it at all and recommend other not to use it. 

As mentioned, closing the reference returned by InsertedVI does not close the VI.

It just brutally unlink the VI from the Sub Panel.

In my opinion, this unlink happens because a Sub Panel keeps its connection with the inserted VI via the reference.

So, when the reference is closed and becomes invalid, the connection is suddenly lost.

This brute unlinking leaves inconsistent state in LabView.

So closing the reference returned by InsertedVI must be avoided.

Some part of this story is just my imagination but I feel it convincing.

If it is the truth, the observed behavior is explained and no longer unknown.

If you use InsertedVI in a sub VI, you created a sub VI with 'special instructions'. Basically a time bomb, set to go off when you least expect it. When you start using that sub VI in dynamic VIs (very likely as combining SubPanels and Dynamic VIs is likely), you get the close automatically when the top level dynamic VI stops...

---

I do not think you are pointing out any defect of my sentences.

@OsamuTakeuchi wrote:

So, InsertedVI can be safely used only from a VI that has a lifetime equal to or longer than the embedded VI in the Sub Panel.

Reading InsertedVI property from the VI that owns the Sub Panel will not cause any problem.

I agree that we can live in safety if we do not use the InsertedVI property and actually I myself will go that way.

I just mentioned a very limited use cases where we may use the InsertedVI property safely.