LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

close reference

does reference(s) in red circle should be closed? or LabVIEW handles memory itself ? 

Vasilich2004_0-1680408110997.png

 

0 Kudos
Message 1 of 10
(1,301 Views)

Broadly speaking, for VI Server references you didn't create explicitly, you don't need to close them (and closing them doesn't actually do anything, so it doesn't matter if you call it or not). The easiest way to check is to close the reference and then use it for something. If you get an error, then it means the close did work and you probably need to do it if you want to release the reference.

 

It's generally best to have whoever opened the reference be responsible for closing it, but I assume your code is just something for testing, so it's not useful for commenting on that aspect in any detail.


___________________
Try to take over the world!
Message 2 of 10
(1,272 Views)

I also think it doesn't matter. 

This is test program. One of my program uses a lot of such code and has memory leaking. Additionally, VIs are reentrant. 

Thank you for suggestion of simple testing!

0 Kudos
Message 3 of 10
(1,213 Views)

Another trick which can help is probing a reference wire (or type casting it to U32) and looking at the value over repeated runs. If it doesn't change, it likely means the reference is static and there is no need to close it.

 

For example, in the following code the two properties behave differently when you probe them and run the VI multiple times, because the Owning VI property does generate a new reference on each call (and the help for it does say "Returns a reference to the VI that owns this object. Close this reference when you are finished using it.").

 

Example_VI_BD.png


___________________
Try to take over the world!
Message 4 of 10
(1,183 Views)

This may not work because reference can get the same memory each time.

Actually, I decided to create this topic because new LabVIEW wiki has example Control References . As you can see "internal" reference is closed.

Vasilich2004_0-1680571616144.png

 

0 Kudos
Message 5 of 10
(1,146 Views)

I'm pretty sure the wiki is wrong on this, at least for those specific examples. Michael wrote it quite some time ago and I doubt anyone reviewed it critically since then. It might have been true in the past and changed since then (although LV 7.0 does seem to behave like modern LV).

 

If I run a tight loop which reads a control's Label.Reference property, LV is happy to do it. The value of the reference is the same, RAM usage doesn't rise and the VI stops immediately when I stop it.

 

If I do the same with the Owning VI property, the value does change, RAM usage goes up and LV will get stuck when stopping the VI trying to close all the references and require crashing (or possibly a long wait). This doesn't happen if you close the VI reference with each iteration.

 

Offhand, I don't remember other properties other the "Owning VI" which do this, but they probably do exist. It might be useful to have a VI Analyzer test for finding them (and it might already exist).


___________________
Try to take over the world!
0 Kudos
Message 6 of 10
(1,137 Views)

@tst wrote:

 

Offhand, I don't remember other properties other the "Owning VI" which do this, but they probably do exist. It might be useful to have a VI Analyzer test for finding them (and it might already exist).


Any refnum you get with an explicit Open or similar function needs to get closed. Also any refnum that does not reference a frontpanel control or subelement of such a control. Front panel controls are instantiated the moment the front panel is loaded. In early VI Server days LabVIEW still opened a new reference to such an element anytime you requested such a reference but that had some serious performance implications and was no good for anything. As long as the front panel is loaded, those controls are there, and as soon as the front panel goes away, there is no space in which the control could still exist. So they optimized the VI Server to return always the same refnum for such objects and Close Reference to recognize such refnums and simply do nothing on them.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 10
(1,121 Views)

Should input reference be closed also?

Vi is reentrant (pre-allocated).

0 Kudos
Message 8 of 10
(1,100 Views)

Darren Nattinger once did a presentation called "An End to Brainless LabVIEW Programing" and included a section on closing references.

 

I suggest watching part of this video to help:

 

https://youtu.be/LcLyl3Xtp3Y?t=1764

 

Link is timestamped to the part about closing references.  That part of it is only about 3.5 minutes long, though the rest of the video is worth a watch too (just not related to the topic of this thread).

Message 9 of 10
(1,080 Views)

@Kyle97330 wrote:

Darren Nattinger once did a presentation called "An End to Brainless LabVIEW Programing" and included a section on closing references.


I was just about to suggest the same thing. Darren states that anything that is a GObject (inherits from the GObject class in the VI Server Class Hierarchy) does not need a “Close Reference”. In fact, if it is used, it does not actually do anything on references to GObjects. A GObject’s reference life it tied to the VI it is in. 

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



0 Kudos
Message 10 of 10
(1,062 Views)