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

[PJM_labview]

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 the resource created by the target resulting - among other thing - for every references created within the target scope to die (see attached example).

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

Cross posted on NI forum

rvm.zip

Edited April 7, 2019 by PJM_labview

[Rolf Kalbermatter]

15 hours ago, PJM_labview said:

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 the resource created by the target resulting - among other thing - for every references created within the target scope to die (see attached example).

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

rvm.zip 12.05 kB · 1 download

You realize that the Enque Element in the Run VI part is not guaranteed to be executed before you close the VI reference itself? In the CBR case you guarantee to call it before you attempt to close that VI reference.

[PJM_labview]

Yes. I thought about changing it, but since it does not make any difference, I left it. in Any case, I changed the example to show that.

Note: Just to prevent more confusion, the error shows up immediately before clicking the stop button.

Thanks

rvm.zip

Edited March 31, 2019 by PJM_labview

[drjdpowell]

I'm curious; what's the use case you have?

[PJM_labview]

On 4/6/2019 at 2:29 AM, drjdpowell said:

I'm curious; what's the use case you have?

Use case: The selection of the target VI will not be under my control so I have no knowledge about it ahead of time (so I cant do a CBR). I can detect other potential issue with the run VI method (ex: reserved for execution ) through the "Open VI" primitive but I can not detect lifetime related issues (shown in the example). I can script a wrapper (at edit time) around the target to do a static call (somewhat similar to what actor framework do with message class), but I would rather avoid doing this if I can help it as this introduce various complications.

[drjdpowell]

That isn't a use case; it's just the next level up in your solution to whatever the use case is.   What is the real-world use case?  Who's your "User" and what are they trying to do?

[Aristos Queue]

On 3/30/2019 at 5:59 PM, PJM_labview said:

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

As far as I also know, it is impossible. 

Having said that, I'm with Powell: if you provide more details about your use case, maybe we can work something out. You explained your work, but you didn't say why you need the call to remain in the call chain.