LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview Auto Close VI Reference?

Solved!
Go to solution

I'm having trouble with what I think is Labview auto closing a VI reference. Here's my setup:

 

I have a number of VI's that require a termination when the program ends.

Upon the first call of the VI, it essentially registers a termination VI that will call that VI with the terminate flag set. This is done by opening a reference to the termination VI and adding it to an array in an FGV.

Upon exit, the VI containing the FGV is called. It runs each VI in the array to terminate any VI's that need it.

 

The problem is, it keeps complaining that the VI reference is not valid. I've check at the point of putting the VI in the array to be sure the VI reference is valid an it is fine. It's only when it tries to call it upon exit that is has a problem. Would labview close any references to VI's automatically?

 

I've used this scheme successfully before, but on an older version of Labview (8.0). Has something changed since then?

0 Kudos
Message 1 of 5
(3,876 Views)

That's an interesting issue an I have to say althought I use similar technics regularly I'm not to clear on the recent evolutions of LabVIEW on that subject.

How do you obtain those vi refs that you place in your FGV? Are these the refs you keep just after launching the VIs dynamically? If yes, check your launch options.

If that is not the issue, then maybe instead  of keeping Vi refs in your FGV you could keep VI names (strings) and when you want to acces then use the "open VI ref" primitive with the VI names, if at this point the VI you try to get a ref of is not in memory anymore, you'll get a clear error that tells you that.

 

Hope this helps


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 2 of 5
(3,855 Views)
Solution
Accepted by thutch79

Once the VI hierarchy that called the Open Reference goes idle, any reference is automatically closed. LabVIEW does not have a reference count system like Java or Lua, where the runtime environment controls the life time of objects depending on if they are assigned to a variable. Instead it controls the life time of it's "objects" (almost anything that is represented with refnums) by the lifetime of the top level VI in whose hierarchy the Open call was done.

 

So if you have a startup VI that spawns your main VI and also creates the refnums and then terminates, those refnums are gone the instant your startup VI stops executing.You will have to make sure the refnums are opened inside a VI that stays executing for the entire lifetime of your application, which in most cases would be the main VI that starts eventually other sub panels as needed.

Rolf Kalbermatter
My Blog
Message 3 of 5
(3,832 Views)

I am so glad I posted this before going home for the weekend. You're absolutely right. This is my first application where I'm using subpanels extensively. Because the reference managing VI is designed to self-initialize, the first call to that VI is happening inside one of the subpanels. That subpanel gets closed before the termination call of that subvi happens. Once I made a dummy call to that VI early in my main VI, all is good. This also explains why I was getting reference leaks on my desktop execution trace of the program.

 

I had planned to just switch to storing the VI paths instead of the references, but as I was troubleshooting, I ran into the same problem managing config file refnums. That is a bigger problem since I don't want to open and close config files every time I need a value. This solution fixed that as well.

 

I seriously went home very angry on Friday because I couldn't sort this out. Thanks for your help! It made my Monday.

0 Kudos
Message 4 of 5
(3,818 Views)

FWIW, this LabVIEW behaviour is also documented in the following blog post: Got Bitten: Data Value Reference Caveat | Science & Wires (wordpress.com)

0 Kudos
Message 5 of 5
(107 Views)