LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Prevent unwanted aborting of VI in a Sub Panel

Solved!
Go to solution

Hi there.

I'm using a "Sub Panel" on a VI and another top-level VI accesses the VI inserted into the "Sub Panel" by using "InsertedVI" property.

After successful access, a problem occurs.

When the latter VI is stopped, the VI in the "Sub Panel" stops working.

It seems that the VI reference obtained by "InsertedVI" property is automatically closed when the latter VI is stopped, and that causes the VI in the "Sub Panel" to be aborted.

 

This reasoning is based on the following post:

https://forums.ni.com/t5/LabVIEW/Labview-Auto-Close-VI-Reference/m-p/1989797#M656349

 

Once the VI hierarchy that called the Open Reference goes idle, any reference is automatically closed. LabVIEW does not have a reference count system like Java or Lua, where the runtime environment controls the life time of objects depending on if they are assigned to a variable. Instead it controls the life time of it's "objects" (almost anything that is represented with refnums) by the lifetime of the top level VI in whose hierarchy the Open call was done.

 

Actually in my case, the VI reference is not opened directly. It is just obtained by using "InsertedVI" property like the following test code. However, the VI still closes the reference when it stops.

 

OsamuTakeuchi_1-1707980861034.png

 

Here, the inserted VI is created by opening VI template following an instruction to insert multiple instances of a same VI to Sub Panels.

https://forums.ni.com/t5/Example-Code/Load-Two-Subpanels-with-Same-VI-Using-VI-Template-VIT/ta-p/351...

 

OsamuTakeuchi_3-1707981763258.png

 

I confirmed the inserted VI is immediately aborted when the VI reference obtained by "InsertedVI" property is explicitly closed by "Close Reference" function.

 

So here is my question:

 

Is there any way to let a VI know that some specific refnums are not of YOUR objects and you SHOULD NOT control the lifetime of them?

 

Thank you for your kind helps.

 

Reproduction steps:

  1. Unzip the attachment.
  2. Run "main.vi". It loads two instances of "sub.vit" into the two Sub Panel's respectively.
  3. Run "access.vi" and press "Access" button. It reads the name of the VI inserted into the first Sub Panel on "main.vi".
  4. Abort "access.vi" while watching the "Valid" indicator on "main.vi". The indicator turns off when the "access.vi" is aborted. It indicates the VI reference inserted to the Sub Panel becomes invalid when "access.vi" is aborted. After that, the Numeric control in the Sub Panel is not working any more.
  5. If you turn on the "Close Immediately" switch on "access.vi" before pressing "Access" button, "access.vi" closes the VI reference obtained by InsertedVI property immediately after accessing its Name property. In that case, immediately after pressing "Access" button, the "Valid" indicator turns off. This means that closing the VI reference obtained by InsertedVI property causes the VI in Sub Panel to be aborted.

 

0 Kudos
Message 1 of 19
(427 Views)

Hi Osamu,

 


@OsamuTakeuchi wrote:

When the latter VI is stopped, the VI in the "Sub Panel" stops working.

It seems that the VI reference obtained by "InsertedVI" property is automatically closed when the latter VI is stopped, and that causes the VI in the "Sub Panel" to be aborted.


The problem is that your subVI stops on its own: prevent the subVI from stopping "on its own"…

(You cannot tell LabVIEW to handle VI references differently than it does now.)

 


@OsamuTakeuchi wrote:

Reproduction steps:

  1. Unzip the attachment.

Which one?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 19
(398 Views)

I by myself found a weird work around.

 

When I store the VI reference value obtained by "InsertedVI" into a Refnum indicator named "InseredVI" and another VI reads its value, the read VI reference is not automatically closed when the another VI is closed. By this method, I can access the VI inserted into a Sub Panel from another VI without the unwanted aborting.

 

OsamuTakeuchi_0-1707988307579.png

 

OsamuTakeuchi_1-1707988386203.png

 

This result suggests that not all the VI references used in a VI are automatically closed when the VI stops. Whether a reference is automatically closed or not depends on how the VI reference is obtained.

 

Now I doubt that the automatic closing of a VI reference obtained by reading "InsertedVI" property of "Sub Panel" is a weird behavior.

 

Reproduction steps:

  1. Unzip the attachment.
  2. Run "main.vi".
  3. Run "access.vi".
  4. Press "Access Indicator value" button and abort "access.vi". The "Valid" indicator on "main.vi" will remain on.
  5. Run "access.vi" again. Switch "Close Immediately" on and press "Access Indicator value" button. The "Valid" indicator on "main.vi" will turn off.

Step 5. means that closing the VI reference causes the VI in "Sub Panel" to be aborted.

Then, step 4. means that a VI reference obtained by reading an indicator value will not be closed automatically when the VI stops.

 

0 Kudos
Message 3 of 19
(387 Views)

I'm glad to see your reply.

Well, it seems I failed attaching the zip file...

I attached a revised version on my newer post.

0 Kudos
Message 4 of 19
(382 Views)

What are you actually trying to achieve?

 

These VIs with while loops hardwired to constants are a bit of a red flag. Abort should never be used as a way to control execution of your program. It is there to instant kill execution if necessary while debugging.

0 Kudos
Message 5 of 19
(321 Views)

Hi, JimB.

 

> What are you actually trying to achieve?

 

I'm trying to have a generic way of reading/writing values of controls. It will be convenient to implement saving/loading measurement conditions to/from files. Actually, it is almost finished except for the case where the target control is on a VI embedded in a Sub Panel.

 

When the control is on a VI embedded in a Sub Panel, just reading its value from the parameter saving VI causes the embedded VI stop working because the VI reference for the embedded VI is unnecessarily closed when the parameter saving VI successfully finish working.

 

> These VIs with while loops hardwired to constants are a bit of a red flag. Abort should never be used as a way to control execution of your program. It is there to instant kill execution if necessary while debugging.

 

Isn't this a bit of off topic?

Otherwise, the test code proves that the VI reference is unnecessarily closed EVEN WHEN the other VI is instantly killed.

 

0 Kudos
Message 6 of 19
(302 Views)

Hi there,

 

I found my analysis above was partially wrong.

Closing the VI reference obtained from "Inserted VI" does not cause the embedded VI to be aborted.

It just unlink the embedded VI from the Sub Panel.

The once-embedded VI continue working background even after the VI reference is closed.

I could reinsert the original VI reference to the Sub Panel to recover the linkage.

 

Reproduction steps:

  1. Unzip the attachment.
  2. Run "main.vi".
  3. Run "access.vi".
  4. Switch "Close Immediately" on and press "Access InsertedVI property" button. This will unlink the embedded VI from the Sub Panel so that "Valid" indicator on "main.vi" turns off and the control value in the Sub Panel stop increasing. Meanwhile, the VI is still working background so that the value of the control "Numeric" read by "Control Value.Get" function continue to increase.
  5. Press "Insert Again" button on "main.vi" to see the VI reappear working in the Sub Panel.

 

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.

OsamuTakeuchi_0-1708049398512.png

 

 
 

 

 

0 Kudos
Message 7 of 19
(289 Views)

SubPanels work a lot easier without dynamic VIs. There certainly not always a reason to use a dynamic VI when you want a SubPanel. It seems to be the default solution: SubPanel->Dynamic VI.

 

If the VIs must be dynamic, always prefer a static VI reference if possible (e.g. if it's not a dynamically loaded plugin).

 

Even if the VI should be a clone, use a static VI reference to get the name or path and use that.

 

If the VI isn't reentrant, simply put the VI in the main to get it running and keep it running as long as the main runs. Either pass the VI a SubPanel reference, or get the VI's reference from a static VI reference and put it in a SubPanel. You can even give the Vi 2 modes: 1) do nothing but return reference(s) and 2) Do stuff. If you only implement 1) you effectively have a facade: a VI that only servers as a FP. It won't need to know if it runs in a SubPanel. 2) could be used to scale itself, while it's returned references can be used to get\set values and\or catch events.

 

You'll get (a lot) easier code if you don't use dynamically started VIs, and SubPanels do not require it.

0 Kudos
Message 8 of 19
(250 Views)

Hi, wiebe@CARYA,

 

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?

 

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 write a test code as simple as possible just enough to reproduce the issue.

 

0 Kudos
Message 9 of 19
(228 Views)

@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.

 


@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.

 


@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...

0 Kudos
Message 10 of 19
(219 Views)