Which references need to be "Closed"?

[Dynamik]

Hi BJK,

      While your experience is a valuable observation, it seems to be in conflict with Darren's statement that "the Close Reference function is a no-op on those references".  Maybe resource-allocation depends on the type of reference, if it's used, and how it's used... 

[Elsa Fung]

As for the memory problem, if you're using SubVIs, I remember reading something that LabVIEW doesn't deallocate memory (until all LabVIEW VIs are done running), so when you have millions of subVIs, it creates a memory problem.  I never tried the closing reference solution, but it helps when you put a Request Deallocation block on your VIs.  The Request Deallocation block (Numeric -> Data Manipulation -> Request Deallocation) deallocates memoary allocated by the VI at the end of the VI's execution.

From Search LabVIEW Help:

"Request Deallocation

Deallocates unused memory after the VI that contains this function runs. When a top-level VI calls a subVI, LabVIEW allocates a data space of memory in which that subVI runs. When the subVI finishes running, LabVIEW does not deallocate the data space until the top-level VI finishes running or until the entire application stops, which can result in out-of-memory conditions and degradation of performance. Place the Request Deallocation function in the subVI you want to deallocate memory for. When you set the flag Boolean input to TRUE, LabVIEW reduces memory usage by deallocating the data space for the subVI."

[Ben]

This seems to be getting to complicated.

Open references as infrequently as possible.

If you type-cast a reference to an I32 and look at the value each time the "open" is executed, that will tell you if you have to close it. References that are unique each time a reference is acquired should be closed. The reference that do NOT change (static) do NOT need closed.

And by the way;

It is a bad Idea to to close a VISA session in if you are using VISA 2.10 or earlier.

For that matter, closing a VISA references is now a NO-OP.

Ben

[Darren]

Hi BJK,

Were you using a recent LabVIEW version when you ran into the performance problems with the Controls[] property in a loop?  Because, as I mentioned before, older versions of LabVIEW would have created unique object references every loop iteration which, as I mentioned, would definitely cause a memory leak.  But if you are using a relatively recent version of LabVIEW (7.0 or later), you should not see any sort of memory leak issue with reading this property.

However, I do agree with a later post from Ben.  I can't think of any reason why you would want to read the Controls[] property of a cluster in a For Loop, particularly since that array will always return the exact same controls every time.  You should read the Controls[] property outside the loop, then use the array inside the loop to do whatever it is you need to do with those controls.

Hope this helps,

-D

[shoneill]

If I may give my opiniion on this:

As Darren has said, older versions may behave differently.  I'm working with LV 6.1 and I've noticed quite a lot of problems when I don't close control references explicitly.  I have a few routines which make extensive use of control references, and it took me quite a while to nail all of the references.  Using not fully debugged versions causes "unexplainable" crashes after while with some nice error dialogs.  At least I'm fairly sure it was to do with not closing the references.

If this has changed in later versions of LabVIEW, then I've got another reason to upgrade.

Shane.

[BJK]

Hi Darren,

I can't remember exactly, but I think I was using LabVIEW 6.1 (now I am using 7.0).
Maybe that was the problem!!

And I explained it wrong:
I am not using the Control[] property IN the loop.
The property was outside the For loop and inside the loop I am changing properties like visible, blinking & caption.
Nowadays the property is even outside the Main While loop!

BJK

[Dynamik]

Hi Ben,

      Your "rule" about closing those references that return different values, VS static references not needing to be closed, seems to be consistent with Help for "Panel" and "Owning VI" - I was surprised to see "Owning VI" return a different reference each time (Panel didn't).

It would be nice if we could read the source-code and know whether a particular "Close" operation was useless.  If LabVIEW HELP consistently/correctly supplies instructions re: Closing [VI-server references], while not convenient at least it would be definitive.  If running a test on a specific reference is the best method for determining whether a "Close" is appropriate, it seems that [VI-server] references are inherently ambiguous in this regard.

[Ben]

Hi Dynamik,

You wrote "Your "rule"..." I would like to correct my previous shortcoming and acknowledge the source of that info was originally Greg McKaskle who was answering a similar question when control references were first introduced.

You went on to write

"it seems that [VI-server] references are inherently ambiguous in this regard.  "

Ditto that!

Ben

[Dynamik]

---

@Ben wrote:

... "it seems that [VI-server] references are inherently ambiguous in this regard.  "

Ditto that!

Ben

---

Hmmm, the meaning of that quote seems rather... unclear.

Were you "Ditto"ing" with me or Dittoing at me?

[Ben]

I aqm not sure what "Ditto"ing" with me or Dittoing at me" so  I can not confirm either of those options.

"Ditto that" = repeat that [statement]

or I agree 100%.

Sorry for ambiguity,

Ben