LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Owning the lifetime of VI launched with "Run VI Method"

Lifetime of VI launched by the "run VI method" are managed by LabVIEW (meaning the caller do not own the the lifetime).

 

Practically, as soon as the target VI terminate, LabVIEW will dispose of all the resources created by the target resulting - among other thing - for every references created within the target scope to die (see attached example).

 

2019-04-05_18-55-32.png

 

I have a use case where this is undesirable and I would love to have the flexibility of the run VI method (generically address control on the target VI) while keeping ownership of the VI call chain in the launcher (like the CBR does).

 

Note: as far as I know, what I am asking is not possible but I would love to be told otherwise.

 

Thanks

 

PJM

 

Note: Cross posted on LAVA Forum



  


vipm.io | jki.net

0 Kudos
Message 1 of 14
(3,112 Views)

Hi PJM_JKI,

 

You're right that this is the expected behavior when using the Run VI Invoke Node. Using that Call by Reference node would be the best way to achieve what you're doing.

 

What would be your use case that using the Run VI would be better than the Call By Reference?

Jiwhan S.
Technical Support Engineer
National Instruments
0 Kudos
Message 2 of 14
(3,034 Views)

@PJM_JKI wrote:

Lifetime of VI launched by the "run VI method" are managed by LabVIEW (meaning the caller do not own the the lifetime).

 

Practically, as soon as the target VI terminate, LabVIEW will dispose of all the resources created by the target resulting - among other thing - for every references created within the target scope to die (see attached example).

 

2019-04-05_18-55-32.png

 

I have a use case where this is undesirable and I would love to have the flexibility of the run VI method (generically address control on the target VI) while keeping ownership of the VI call chain in the launcher (like the CBR does).

 

Note: as far as I know, what I am asking is not possible but I would love to be told otherwise.

 

Thanks

 

PJM

 

Note: Cross posted on LAVA Forum


I first saw that issue in LV 6.1 RT where I served up an Action Engine via VI-Server. IN my case, the queue would go invalid when I had a comm error and the served VI and all of its resources ( the queue) where cleared.

 

The CBR method works since you do not close the VI until after the enqueue operation completes.

 

You could create the queue and pass it to the Target

OR

Create a Daemon that creates the queue and stays alive to keep the queue alive.

OR

Maybe have the target open a ref to itself.

 

That is all that I can offer,

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 14
(3,017 Views)

JiwhanS and Ben,

 

Thanks you both for the reply.

Ben, like you I have been aware of this for a long time, and while from time to time this has prove to be inconvenient, finding work around (if I can modify the target VI) has never been a problem (Note: The queue was just a quick example demonstrating the problem)

In the current scenario that I am facing, the target VI is - in most case - not under my control (and it might be password protected), so modifying it is not possible. In addition, the target VI will be specified by a user, so I really have no idea ahead of time of its connector pane, but if I have to, I will script [similar to AF message maker] CBR (or direct static call) around each different target. It would have been nice to not have to do that though...

 

Thanks again for answering.

 

PJM



  


vipm.io | jki.net

0 Kudos
Message 4 of 14
(3,009 Views)

@PJM_JKI wrote:

JiwhanS and Ben,

 

Thanks you both for the reply.

Ben, like you I have been aware of this for a long time, and while from time to time this has prove to be inconvenient, finding work around (if I can modify the target VI) has never been a problem (Note: The queue was just a quick example demonstrating the problem)

In the current scenario that I am facing, the target VI is - in most case - not under my control (and it might be password protected), so modifying it is not possible. In addition, the target VI will be specified by a user, so I really have no idea ahead of time of its connector pane, but if I have to, I will script [similar to AF message maker] CBR (or direct static call) around each different target. It would have been nice to not have to do that though...

 

Thanks again for answering.

 

PJM


If I come up with a work-around I will let you know.

 

The way it is implemented now does prevent issues with never to be used resources from piling up in memory.

 

Have fun whatever you decided to do!

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 14
(3,005 Views)

You could put the tartget.vi in a dummy.vi that runs forever... Create indicators of target.vi's outputs... Perhaps even make dummy.vi signal that target.vi is done with a queue or event of some sort.

 

Start the dummy.vi, get the results from it's front panel. Then, let it run, even though target.vi is done.

 

Dummy.vi might need to be reentrant, if you want to invoke target.vi more then once.

 

DISCLAIMER: not tested!

0 Kudos
Message 6 of 14
(2,992 Views)

Wiebe,

 

Interesting suggestion, but if I understand your suggestion well, I do not use the "run vi method" any more correct?

If this is the case then to pass inputs to target (there will most likely be some input in the real situation), I need to script that for each target VI. If this is what you proposed, I think this is very close to my current work around (if I can call it that).

 

PJM



  


vipm.io | jki.net

0 Kudos
Message 7 of 14
(2,974 Views)

I'd use the run method to start the dummy. The dummy runs the target, target is done, dummy sends a signal (optional) but keeps running. Optionally, dummy could be closed gracefully, or simply be aborted.

 

Inputs of target would need to propagate to inputs (or at least front panel controls) of dummy.

 

You would need to script\create a dummy for each target. But with OO\polymorphism, target could be a dynamic dispatch VI that simply executes the method of the given child. So, then only one input (the object, a child of a common parent) would allow execution of all targets. The output could also be just one (and the same) object...

 

All of this smells a lot like polymorphism...  Polymorphism, combined with a for loop set to parallel execution, might get you 90% there. Not sure how you landed in this exact situation, but there might be completely unrelated solutions. I use dynamically running of VIs a hole lot less since I started OO...

0 Kudos
Message 8 of 14
(2,964 Views)

Hi Wiebe,

 

Thanks again for replying. I think I understood the first part of your reply but not the later. Before going over this, let me restate that the "target.vi" is a black box which I have no control over (and in reality there could be a very larger number of different target with different con pane).

 


wiebe@CARYA wrote:

I'd use the run method to start the dummy. The dummy runs the target, target is done, dummy sends a signal (optional) but keeps running. Optionally, dummy could be closed gracefully, or simply be aborted.

 

Inputs of target would need to propagate to inputs (or at least front panel controls) of dummy.

 

You would need to script\create a dummy for each target.


Ok, I believe I understood that part. In summary, create wrapper around target, launch & run wrapper using "run vi method" (wrapper will then run target once passing argument as needed and collecting output as needed) and keep wrapper running (to preserve any possible references that target may have created). Stop wrapper when appropriate to "clean up".

 


wiebe@CARYA wrote:

But with OO\polymorphism, target could be a dynamic dispatch VI that simply executes the method of the given child. So, then only one input (the object, a child of a common parent) would allow execution of all targets. The output could also be just one (and the same) object...

 

All of this smells a lot like polymorphism...  Polymorphism, combined with a for loop set to parallel execution, might get you 90% there. Not sure how you landed in this exact situation, but there might be completely unrelated solutions. I use dynamically running of VIs a hole lot less since I started OO...


I have to confess that I am not following that later part. Are you suggesting I modify target to put it in a class? or something else altogether?

 

Thanks



  


vipm.io | jki.net

0 Kudos
Message 9 of 14
(2,935 Views)

@PJM_JKI wrote:

 


wiebe@CARYA wrote:

But with OO\polymorphism, target could be a dynamic dispatch VI that simply executes the method of the given child. So, then only one input (the object, a child of a common parent) would allow execution of all targets. The output could also be just one (and the same) object...

 

All of this smells a lot like polymorphism...  Polymorphism, combined with a for loop set to parallel execution, might get you 90% there. Not sure how you landed in this exact situation, but there might be completely unrelated solutions. I use dynamically running of VIs a hole lot less since I started OO...


I have to confess that I am not following that later part. Are you suggesting I modify target to put it in a class? or something else altogether?

 

Thanks


My knowledge about your exact situations isn't enough to really advice here.

 

With OO, you could make class wrappers (children of a common parent) to call the target vis. Then you could start more then one in parallel, by putting the objects in a for loop, and then running them in a parallel for loop. All object will execute their target in parallel then.

 

There would be no control over the lifetime of the targets, so it might not apply.

 

In general, I think dynamically starting VIs is (mis)used way to often. Especially call and forget\collect is way to complex for my taste, and refactoring usually gives a clean solution.

 

I don't know if this applies in your situation. When you have closed source to deal with, it can change the game completely.

 

Guess what it comes down to that your situation isn't ideal, but that you can't change it...

 

0 Kudos
Message 10 of 14
(2,922 Views)