Where when and why should we close references

[Nitrof]

No one, from all that I have seen on the NI site, agree on this issue. Should we close references? or does LabVIEW will handle them? Does the performance will suffer?

From my own experience:
Yes we need to close them.

Yes LabVIEW will handle them, but only when the program exit or is aborted.

Yes the performance will suffer.

The example provided by NI are not correct. Reference are not closed. This will be ok for a small program. But when the number of operation by references increase. The rusult is that the program may take some time to stop, abort and in some times all ressources may be required.

The main reason, from what I heard, is du to the creation of temporary references made inside looping
structures i.e. for loop, while loop.

There is a small example attached to this question. If someone know the rules to do everything properly.

[Ben]

I agree,

I have never seen and end all statement on how to handle refnums.

Let me share what I have picked up.

First of all, I don't think they have chased all of the bugs out of close the references and freeing up the allocated resources.

I will generally assume that some trash is going to be left over after working with references. With this in mind, I approach them carefully. If I am going to be using a reference to an object repeatedly, I will open the refenece once and keep it open until the program exits.
If I will be getting at an object in-frequently, I will open the reference use it, then close it. This would be the case in reading values from a screen that is only accessed once in a blue moon.

Either way, I always close any reference that I hav
e opened. As long as I do, I never run into any problems.

Ben

[JRA]

First let me say that I am very impressed by the depth of your search! The VI you built shows much skill and creativity.

This is an excellent question you have raised. The "offical" stance is that you should always close references when you are finished using them. There are a variety of reasons for this, the primary reason being that you can fill up unused memory by not closing a reference.

For instance, if you open a reference to an object, then the memory for that object is not freed until you close the reference. In the case of a loop especially, you could continue to open numerous references and therefore consume more and more memory.

Within various applications, there are more specific reasons for closing references which you have opened. For ins
tance, in a GPIB application, if you have opened a reference to a communication line, then if you try to open another without closing the original, you can get run-time errors and your application will crash. You will find similar circumstances in data acquisition applications. Also, in some ActiveX applications, creating a reference to an ActiveX server without closing a previous reference can cause your program to crash.

To summarize, it is excellent coding practice to always close references when you are finished with them. Besides various, specific reasons, this will free up memory for later use and give better performance to your overall applications. Good luck coding!

[bmihura]

What about a reference to a "really simple" thing, like a Property Node controlling the "Disabled" property of a front panel Numeric Control?

I see tons of LabVIEW examples written where the really simple property nodes never have their references closed. Is that OK?

If so, when where do you draw the line separating what is "really simple" and what is not?

[Nick R]

Hi bmihura,

Like you've said, in simple cases leaving the references open will not cause any problems. A reference to a property node is internal to LabVIEW (as long as it is not ActiveX or something like that), so its not like you're leaving VISA references open or something else that is an external connection.

I have not personally seen any situations where someone had enough property node references open in an application that it started causing problems. However, I would imagine that in an extreme case this could cause problems. Unfortunately I do not have any hard guidelines for for what is a simple case and what is an extreme case.

On a side note, you replyed to a pretty old discussion. In most cases you will have a better chance of getting more responses if you created a new discussion and just references this one.

[PaulG.]

By my understanding references to controls are handled by LV internally and don't need to be closed, but EVERY other type of reference needs to be closed explicitly. E-V-E-R-Y non-control reference.

[Nick R]

This is correct. References internal to LabVIEW should be handled by LabVIEW. Any external references need to be closed, such as file I/O, ActiveX, instruments, etc.

[jccorreu1]

Nice test vi's there.  I really like that.  Does anyone know if we can use labview to show us the memory load of the different runs?

I'm going through a large project trying to improve performance and track down a bug so now I'm looking at refs deeper than ever.  I created this little thing because I use refs in many different places, and I've got a number of concurrently running subvis that all interact, and wanted to know when to close refs and when to leave them open.

It seems to me here that for controls closing them makes no difference at all.  You can see that I created 2 arrays, holding the refnum and label of each control on the front panel.  But I did this after closing the references.  Ok no big deal since I took the input for the property node before I closed the refs, so their numbers are stored in the for loops node.  But then I send this to a subvi that gets opened afterwards, and it does a strict property node read of those numbers and they still give the correct labels.  It seems to me that as long as the front panel is open labview maintains the same refnum for each control, and won't close the refnum because the panel is still using those controls.  I'm more convinced of this because when I put probes where the black arrows point, that no matter how many times I run through the while loop, the refnums never change, and all 3 probes show the same numbers.  And when I do kill the top process then run it again the refnums of the controls are different then.  So it would seem that if you are taking refnums to controls from a panel that will be opened and closed repeatedly then it would make sense to destroy those refnums, er close the refs.

SO then to check out how it affects vi refs I put the close ref at the end of the panel read, where the red arrow is.  Each successive loop shows a new refnum in the probe.  If I do not close it there, and put a probe before the panel read where the blue arrow is, the refnums also change in that probe.  Which leads to think that there is a memory difference for vi's, even when within itself.

So then to be a smart alec I decided to pass the close fron panle ref to the subvi, and sure enough it blows up with an invalid reference error like we'd expect.  Of course if I abort the top vi the subvi dies before I can finish that test.  I think what I need to do is make the top vi call a subvi and get refs from the subvi that the top will try to use after closing the sub....

So I decided to use a static vi ref to do that, and well putting a probe on it, even with closing it ech time, the refnum stays the same through the loops, i.e. the word "static" i suppose. It does change when I abort the top vi and make a new run.  Maybe I could use something with a queue from the subvi to try out more refnum experiments...

Now if I leave the ms wait timer on 1 ms.... after a few seconds it closes quickly, no probs.  After only a minute... when I hit abort it takes its sweet little time to close.  This is with me killing the static vi refnum eaech cycle which of course does nothing.  But not killing the self-refnum.  When I do kill the self-refnums it doesn't matter how long I leave it up and running it still aborts as quickly as if I did it just after run.

So it seems that any time a vi is called by a non-static refernce, which could be every other kind, i'm not testing them all right this minute, its going to be generating more overhead and would be better closed.  For front panel controls, if the vi they're on is closed and opened again they too will have a new set of refnums, and the consequential overhead involved.

Does this seem to fit with what the starter of our thread showed us?

And again how can we measure the memory usage?

[Gabi1]

i just got very confused from reading this thread:

i assumed references could be tought as pointers to variables. if so, there should be no necessity to close any control reference, and only references to vis or subpanels should be handled properly.

If this is not the case, we enter into a contradiction: a local variable effectively duplicate memory, therefore should not be used. reference also uses memory, and should be dealt with properly. so, for simple cases where a variable has multiple write and read in an event structure for example, should we close reference every time we open them? isnt it just much better to use a local variable, which as duplicated memory, but only once (at copy place), and is kept during run of the program. this in contrast with reference, whom every time i call it (every time same event is called), it use another memory spot?

my programs are filled with property nodes in even structures called via references open on the spot...and the program does crash once every 2 weeks of continuous running, not knowing why...is it related?

[tbd]

Hi Gabi,

      In case it's of interest, Here's a somewhat exhaustive thread on the subject of closing references.

Cheers