Dynamically launch VI can't pass DVR to caller

[Stobber]

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why? See the attached code (LV15) for an example.

I don't want to use the ACBR node right now because I want to set some control values of the VI ref on a different diagram than the one that will run it. (I just want to pass the VI ref between calling diagrams, not all the values that'll be passed into it.)

DVRtest.zip

[drjdpowell]

  On 5/16/2016 at 6:41 PM, Stobber said:

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why?

Expand  

References are “owned” by the "VI hierarchy" that created them, and are automatically destroyed if that hierarchy goes idle.  Asynchronously-called VIs run in their own independent hierarchy (even if you use the Run method instead of ACBR).  In your example, the DVR was destroyed when the launched VI finished.  

[Stobber]

Thanks, but "ugh" . Guess I'll have to pass a DVR in.

[LogMAN]

  On 5/16/2016 at 6:41 PM, Stobber said:

If I create a DVR in a dynamically launched VI, the DVR ref goes stale when it's passed back to the caller. Anybody know why?

Expand  

The DVR will remain valid for as long as your dynamically launched VI is running (or rather for as long as the VI which created the DVR stays in memory). Since you wait for it to finish execution LabVIEW recognizes the VI as being idle and therefore removes any remaining references automatically. Reading the indicator value as variant doesn't help either, as LabVIEW cannot recognize the value as reference type.

You can try an FGV to store the DVR in a buffer (the FGV must create the DVR though), but this will work for one instance only.

Another option is to create the DVR in the caller and pass it to the dynamically launched VI. That's assuming the caller knows the DVR type => maybe use a subVI to create the DVR in the caller and pass it to the dynamically launched VI.

[drjdpowell]

  On 5/16/2016 at 7:21 PM, Stobber said:

Thanks, but "ugh" . Guess I'll have to pass a DVR in.

Expand  

Why are you not just (plain-old synchronously) calling the subVI?

[Stobber]

  On 5/16/2016 at 7:52 PM, drjdpowell said:

Why are you not just (plain-old synchronously) calling the subVI?

Expand  

Oh, you know. "Reasons."

[Norm Kirchner]

Dave, 

I've got a version of ESF that will keep references live beyond the boundary of the creating hierarchy. 

Willing to dive back into that pond? 

[Stobber]

No thanks. I simply changed the pattern, and it works fine without having to introduce new dependencies to the app.

[endeavor]

Norm,

let's assume I have two VIs that are running in parallel and sharing an ESF based session. VI 1 started earlier so it created the session whereas VI 2 found the active reference. Excellent.

The question now is what should happen when I stop VI 1 and it closes the reference with 'force destroy' flag set to FALSE. Should my session reference in VI 2 still be valid? Since the 'owner' is not running anymore I guess it shouldn't and this is also what I'm experiencing. Can you confirm it? If yes, I would like to know more about the version of ESF you mentioned.