LabVIEW
Prevent unwanted aborting of VI in a Sub Panel
Solved!
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.
Here, the inserted VI is created by opening VI template following an instruction to insert multiple instances of a same VI to Sub Panels.
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:
- Unzip the attachment.
- Run "main.vi". It loads two instances of "sub.vit" into the two Sub Panel's respectively.
- Run "access.vi" and press "Access" button. It reads the name of the VI inserted into the first Sub Panel on "main.vi".
- 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.
- 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.
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:
- Unzip the attachment.
Which one?
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.
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:
- Unzip the attachment.
- Run "main.vi".
- Run "access.vi".
- Press "Access Indicator value" button and abort "access.vi". The "Valid" indicator on "main.vi" will remain on.
- 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.
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:
- Unzip the attachment.
- Run "main.vi".
- Run "access.vi".
- 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.
- 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.
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.
Search LabVIEW like a graph!
@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...
