Close VI References

[dannyt]

Hi,

 

Quick question regarding my closing of my VI references, I suspect I am doing this wrong. Should I have the close reference inside my for loop and close it each time ? The code works fine I have been using it for a while now, but I was doing a review and noticed this.

 

any comments please

 

cheers

 

Danny

 

 

[Aristos Queue]

Published in January 2013, this is the official directive on closing references: when you need to and when you don't.

http://www.ni.com/white-paper/14393/en

 

In your picture, the code shown is fine. Moving the Open and Close inside the loop would just create a performance burden. Moving only the Close inside would cause run time errors since the reference would be closed on the second iteration.

[dannyt]

Thank you for the reply and I will be reading the link you posted tonight

 

cheers

 

Danny

[todd]

I don't see a feedback link on that white paper. The Related Links are all malformed. Checked in IE10 and Firefox.

[JackDunaway]

Hi,

 

Quick question regarding my closing of my VI references, I suspect I am doing this wrong. Should I have the close reference inside my for loop and close it each time ? The code works fine I have been using it for a while now, but I was doing a review and noticed this.

 

any comments please

 

cheers

 

Danny

 

 

launch_clone.jpg

 

Not related to the VI Clone Refs per se, but while we're on the topic...

 

Since the User Events are created by this launcher SubVI, this SubVI must remain reserved for execution (or running) for the User Event Refs to remain valid. One common misconception is to think that keeping this VI in memory is sufficient, or that once passed to the clones the User Event Refs tie their lifetimes to that of the clones. The lifetimes of these User Events are tied to the static call chain of the diagram that creates the references.

 

This gets tricky when clones start launching clones.

[dannyt]

Hi, Thanks for the extra info. My system does work so I must be doing this correctly, by luck I suspect.So I have a top level typical event driven state machine system and it calls this subvi just before it enters the state machine while loop. If I understand what you are saying, I cannot make the calling of this subvi its self a dynamic call

[JackDunaway]

Hi, Thanks for the extra info. My system does work so I must be doing this correctly, by luck I suspect. So I have a top level typical event driven state machine system and it calls this subvi just before it enters the state machine while loop. If I understand what you are saying, I cannot make the calling of this subvi its self a dynamic call

 

 

Bingo. Sounds like you'll be fine, since this Launcher VI remains reserved for execution as long as the top-level VI remains running.

 

But just to watch out for in the future, here are two places this can get tricky:

1. When shutting down your application: If the top-level loop stops before the clones stop, the Event Ref will go invalid since its lifetime is tied to the top-level loop. Fortunately, the Events API grants immunity against this, because the Event Registration Refnum can have a different lifetime than that of the Event Ref. In your example, the event ref lifetime is tied to the static call chain of the Launcher up to the top-level state machine, while the Event Registration Refnum is tied to the lifetime of the Clone (presumably, if the Clone is calling the Register For Events method). For this reason, it's OK for the top-level loop to send a final "Shutdown" message and then immediately close the Event Ref -- even though the Messenger is now gone, the Mailbox remains valid with the final Shutdown message in its queue.
   
2. When you're running the Launcher directly from the IDE in order to troubleshoot/develop the clones: If you were to run this VI directly, it would launch the clones, but the User Event references would immediately die as this Launcher is no longer running or reserved for execution. Common misconception -- even though it remains in memory (since the panel remains open), and even though we passed the references to VIs that are currently running, references created by this VI go invalid once the VI finishes execution. One way to circumvent this, is to create a trivlally simple "Debug Launcher" VI that makes a static call to the launcher and remains running until a simple event (shown below):
   

 

[dannyt]

Published in January 2013, this is the official directive on closing references: when you need to and when you don't.

http://www.ni.com/white-paper/14393/en

 

In your picture, the code shown is fine. Moving the Open and Close inside the loop would just create a performance burden. Moving only the Close inside would cause run time errors since the reference would be closed on the second iteration.

 

If I wanted to go one stage further and put the Front Panels of these launched VI into a subpanel, I assume I do NOT want to close here at all but gather up the array of references coming out of the loop to pass into the "Insert VI " subpanel method as required. I would then need to close the full array of references when I no longer needed them for the subpanel.