Jump to content

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


Recommended Posts

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

2019-03-30_15-42-35.png.713908f5df3dce1491801ce36ced705f.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

Cross posted on NI forum

rvm.zip

Edited by PJM_labview
Link to comment
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).

2019-03-30_15-42-35.png.713908f5df3dce1491801ce36ced705f.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

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.

Link to comment
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.

Link to comment
  • 2 weeks later...
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. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.