VI reference close

In my main VI, I opened a VI reference to another VI (let's call it VI1) and used the invoke node to run VI1 in the background. Once VI1 is done running, I thought I still have to close its reference in my main VI. However, the reference to VI1 became invalid. Is that a standard behavior? It doesn't make sense to me why the reference would become invalid.
Kudos and Accepted as Solution are welcome!
Solved!
Go to Solution.

Sounds like you set Auto Dispose Ref to True.
LV Help:
Allows you to run a VI independently of the caller without opening its front panel immediately or opening another reference inside the target VI. If TRUE, the referenced VI transfers ownership of the reference from the calling VI to the VI that is running. This means LabVIEW disposes of the reference, along with the parallel data space, when the target VI goes idle, not when the VI that opened the reference goes idle. The reference can still be used by the calling VI until the target VI closes the reference. The calling VI does not need to close the reference unless the Run VI method returns an error. If the calling VI does close the reference, the target VI can abort and leave memory. If FALSE, LabVIEW automatically disposes of the VI reference when the VI that opened it goes idle. The default is FALSE.

Similar Messages

Close reference, write to reference, close reference--Redundant?

Hello,
I am analyzing another's code, and came upon this snippet:
[Text reference in] --> Close Reference [Reference out]
--> [Text string in] Write to Text File [Reference out] --> Close reference
Thoughts?
Thanks for your time.

From your description, it sounds like at least one of the reference close operations are redundant - it's hard to tell exactly. However, operationally it shouldn't cause too much mischief as redundant or unneeded reference closings compile to a noop instruction.
Mike..
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Close reference needed for step object reference open? If so, how?

Hello,
We are using an activex method call to open an object reference to a step and programatically rename it. This is done many many times during our test run, thousands. We ran into an "out of memory" problem we had never seen before during a 72 hour test run, and in hunting down any possible memory leaks, I am wondering if a corresponding close is needed for the step reference open we are doing, and how. I have hunted around the different methods/properties, and can't seem to find if there is a step reference close. I have attached the specify module screen of the activex call which opens the step reference.
Thanks for any replies
David Jenkinson
Message Edited by david_jenkinson on 06-11-2007 05:07 PM
Attachments:
step reference specify module.png ‏25 KB

Hi David,
Setting a reference to nothing in TestStand will close it. However, if you are assigning a new value to the local it also frees the memory associated with the original value, making it so you don't need to assign it to nothing. I don't believe the source of the leak is in this step.
Test Engineer - CTA

DataSocket memory leak problem (2VO0SF00) -- more info?

When upgrading to LabVIEW 8.5 recently, I noticed the following known issue in the readme file:
"ID: 2VO0SF00
DataSocket/OPC Leaks Memory using ActiveX VIs to perform open-write-close repeatedly
If you call the DataSocket Open, DataSocket Write, and DataSocket Close functions in succession repeatedly, LabVIEW leaks memory. Workaround — To correct this problem, call the DataSocket Open function once, use the DataSocket Write function to write multiple times, and then use the DataSocket Close function."
Looking back, I think this problem may have been present in previous LabVIEW releases as well, and might be giving rise to a problem that's been dogging me for quite some time (see my thread, "Error 66 with DataSockets", http://forums.ni.com/ni/board/message?board.id=170&thread.id=187206), in addition to general slow/glitchy behaviour when my VI's have been running continuously for a long time. But in order to determine whether or not this issue affects me, and how I should go about fixing it in the context of my own programs, I need a bit more information about the nature of the issue itself and the inner workings of the DataSocket VI's. Any help or insight the community can provide into this would be greatly appreciated!
Here are my questions:
It is my understanding from the "known issue" description above that the memory leak happens when you have a DS Open wired to a DS Write wired to a DS Close, all inside a loop (example 1), and that the suggested workaround would be to move the DS Open and DS Close functions out of the loop on opposite sides, wired to the DS Write which remains inside the loop (example 2). Is this correct?
Does this leak also happen when performing DS open-read-close's repeatedly (example 3)?
What happens when a DS Write (or DS Read) is called without a corresponding DS Open and DS Close (examples 4a and 4b)? Does it implicitly do a DS open before doing the write operation and a DS close afterwards? What I'm getting at is this: would having an isolated DS Write (or DS Read) inside a loop, not connected to any DS Open or DS Close functions at all, cause this same memory leak?
If one computer is running the DS server and a second computer is running the VI with the repeated open-write-close's, on which computer does the memory leak occur?
In my question #1 workaround (example 2), the DS Open and DS Close outside the loop are routed through a shift register and in to and out of the DS Write inside the loop. If the DS connection id goes into the DS Write "connection in" and then splits and goes around the DS Write and out to the DS Close, without coming out of the DS Write "connection out" (example 5), will the memory leak still be avoided? I.e. if the DS Write function doesn't have anything connected to its "connection out", will it try to do an implicit DS Close?
If the VI causing the memory leak is stopped, but LabVIEW stays running, will the leaked memory be reclaimed? What if the VI is closed? What if all of LabVIEW is closed?
FYI, in the examples above "x1a" is a statically-defined DataSocket on the DS server running on the computer Max, to which the computer running the example VI's has read/write access. My actual application has numerous VI's and hundreds of DataSocket items, many of which are written to / read from every 50-100 ms in the style of examples 4a and 4b.
Does anyone have any idea about this stuff?
Thanks in advance,
Patrick
Attachments:
examples_jpg1.zip ‏63 KB
examples_vi1.zip ‏40 KB

Hi Meghan,
Yes, some of the larger VIs in my application do write to / read from several hundred DataSockets, so it's not feasible to use shift registers for each one individually, and hence why I'm passing the references into an array, etc.
Your Alternate Solution 2 is more along the lines of something that would work for me. However, my actual code has a lot of nested loops, sequences and DataSocket items which are not all written to in the same frame, so this solution would still be difficult to implement: it would be cumbersome to unpack the entire 500-element reference id array and build a new one (maintaining the positions and values of the unaffected elements) every time I write to some small subset of the DataSockets.
I think I have a solution which solves the problem and is also scalable to the size of my application -- I've attached it as Example 7. Do you think this will avoid the memory leak? It's the same as your Alternate Solution 2, except that instead of building a new array out of the DS Write reference outs, each reference out replaces the appropriate element of the original array.
If I understand you correctly, in order to avoid implicit reference opens and closes, a DS Write needs to have both it's reference in and reference out wired to something. Thus, even though my Example 7 replaces an element of the array with an identical value, and therefore doesn't actually change the array (which would be a silly thing to do normally), the DS Writes have their reference outs wired to something, and eventually in a convoluted way to a DS Close, so it should avoid the memory leak.
Just out of curiosity (I don't think anything like this would apply to my application or any fixes I implement), when would the implicit reference close happen in the attached Example 8? The DS Write has its reference in and reference out both connected to temporally "adjacent" DS Writes via the shift register, so perhaps it wouldn't try to close the reference on each loop iteration? Or would it look into the future and see that there is no DS Close and decide to implicitly do that itself? Or maybe only the DS Write on the last loop iteration does this?
Thanks for bearing with me through this,
Patrick
Attachments:
example73.JPG ‏40 KB
example83.JPG ‏14 KB

How can I connect to a remote firewire camera?

We have a system that has the following peripherals connected to it:
1 - firewire camera
2 - serial port devices
2 - emulated serial port devices (on VCP USB drivers)
1 - Ethernet device
We have developed an application using CVI 8.1, NI Vision 8.6, and NI-IMAQdx 3.2 (it's an older cam). I would like to make this system accessible remotely (not remote desktop) and was looking for a way to program a server/client setup. Although it will be a lot of work, we can easily take care of a protocol for the Ethernet and serial devices. Where I'm getting stuck is the camera.
I've searched the forums and it seems that people can use the RT software module on specific host hardware to do just that. We don't want to invest in purchasing a separate software module or another piece of hardware, so I was wondering if it was possible to configure MAX or the NI vision server somehow to connect to a remote win7 PC to grab frames and configure the camera OR is there an easy way that I can transfer the stream over TCP/IP?
The only solution I can come up with is the grab a frame, save to .PNG, transmit it, and then load it on the client side. This seems very wasteful (and slow considering the harddrive will constantly buffer the data) and I would need to do a lot of encapsulation for changing camera settings, etc. Further, I'm not sure how well this would work for when we try to calibrate the camera with the IMAQ drivers. Is there a way to get the size and all relevant data structures in memory of the vision server so I can transfer them?
Finally, if there is a simple way of configuring and doing all of this for the camera that I'm missing (through MAX), then is there a similarly easy way of mapping the remote serial ports and of bridging the Ethernet data? I know there are a few pieces of existing software for the serial ports, but was looking to make a single software solution.
Thanks for taking the time!
-Stan

Hi Stan,
Welcome to the NI Discussion forums! Thanks for posting your application here. There certainly are more efficient ways of streaming IMAQ images over a network. One such method would be to convert the IMAQ image type to a 2D array and then pass the data through TCP/IP, as you eluded to. Do you have access to LabVIEW? If so, you can look at this community example and base your CVI code on it. Although it is meant for a Real-time CVS acting as the remote system, you should be able to run the code on a regular PC. If you don't have access to the LabVIEW development system, the overall code structure for the server system is as follows:
- Open IMAQdx reference, initiate a TCP connection, Create IMAQ image buffer
- Initialize an IMAQdx grab
- Loop:
- Call IMAQdx grab
- Use the IMAQ Flatten Image to String to convert the IMAQ image to a string
- Call TCP Write to send the string length first, then again to send the actual string data
- Dispose of the IMAQ image buffer, close the IMAQdx reference, close the TCP connection
On the client end, you just need to open the TCP connection and call TCP read to read the string size and then the string data. Then, you can use the unflatten from string function to convert the string back to an IMAQ image data type. After this, it is up to you how you want to process the data (display it on the screen, write to an AVI file, etc).
If you are not sure how to implement TCP/IP programs in CVI, please take a look at this tutorial. If you have more in-depth questions about implementing the TCP/IP side of the program in CVI, you may wish to post that specific question on the CVI board.
With regards to mapping the serial ports remotely, if you are already using NI-VISA for COM port communication, take a look at this document on Remote Instrument Control with NI-VISA. Essentially, you should be able to access the VISA resource (e.g. a COM port) remotely by enabling the remote NI-VISA server on the client machine. For more specific help with this aspect of your code, please post to the GPIB/VISA board.
Feel free to post again here if you have more IMAQ and vision-related questions. Hope this helps!

Why does the "Dispose Report.vi" doesn't release memory used by report

I have prepared report that includes a few tables After finishing printing, the amount of memory used by my application is bigger. Next printing of the raport lead to crash the LabView because of lack of memory.
It also cause mu application to work slowly.
The amount of used memory is checked by the Task Manager. My operating system is Windows NT 4.

This issue has been reported to R&D, and they are currently going through the VIs and the dll to track down all the memory leaks.
You can go through the VIs and edit them so that every open reference has a reference close. This will not fix all of the leaks but might be enough to get your program working.
Jeremy Braden
National Instruments

Unable to truncate() a file previously mapped to a MappedByteBuffer

(Here's hoping that my carriage returns will be preserved this time...)
I am using memory-mapped IO to record a program log. The mapped portion is done 512kb at a time, and when the program is finished, the logging section does the following:
determines how long the file actually is,
force()'s the byte buffer,
nulls out the byte buffer reference,
closes the byte buffer's channel,
nulls out the channel's reference,
calls System.runFinalization(),
calls System.gc(),
opens a new RandomAccessFile on the log file,
truncates the log file (the new RandomAccessFile) down to the correct size.
About half the time, this works as planned, the other half (using Java 1.5.0_06 on a Windows XP machine), the truncate throws an IOException:
"The requested operation cannot be performed on a file with a user-mapped section open."
I think it has to do with the garbage collection call not working, because I have resorted to the kludge of:
boolean truncated = false;
int numTries = 0;
while (!truncated)
try
    new RandomAccessFile(logFile, "rw").getChannel().truncate(fileSize);
    truncated = true;
catch (IOException e)
    debug("truncation failed because the file is still mapped, attempting to garbage collect...AGAIN.");
    //do garbage collection to ensure that the file is no longer mapped
    System.runFinalization();
    System.gc();
    numTries ++;
if (numTries == 10)
    debug("Tried to unmap file 10 times; failing now.");
    truncated = true;
} The above seems to work just fine...though it may run through the loop a few times.
Is there something that I'm missing here?
Thanks!
-Zach

Crossposted and answered http://forum.java.sun.com/thread.jspa?threadID=745275&tstart=0

Opening Appleworks 5 in Vista

I am a teacher and just switched schools. All my files at my old school were made on Appleworks 5 (I prefer that version to Appleworks 6) but my new school uses Microsoft Works. Is there any way I can open all my Appleworks 5 doccuments and convert them to Microsoft Works Word Processor? I would hate to lose all that work! Thanks, Mary

Hi.
This is how i would do it...
1. Methodically gather all of the files into a folder on your Mac desktop. The fewer folders you sort them into, the better.
2. Open Applscript Editor on your Mac and copy the following into the blank window...
property theTranslator : "Word Windows 97, 2000, XP 2002 "
try
tell application "Finder"
set thisFile to choose file
duplicate thisFile
if kind of thisFile is not equal to "Folder" then
set FileName to (name of thisFile) as text
set Filenamelength to length of FileName
set Suffix to ".doc"
if file type of thisFile is "CWWP" then
-- set currentPath to currentFile as text -- AW6 wants a path, not an alias -- alias ref is ok
if FileName ends with ".cwk" then
set nameCount to count of characters in FileName
set FileName to ¬
(characters 1 through (nameCount - 4) of FileName as string)
end if
if Filenamelength > 27 then
set TopLimit to (Filenamelength + (27 - Filenamelength))
copy characters 1 through TopLimit of FileName as string to NewFilename
set NewFilename to NewFilename & Suffix
else
set NewFilename to FileName & Suffix
end if
try
set the name of thisFile to NewFilename
on error
set name of thisFile to the text returned of (display dialog "You have duplicate file names. Please rename this file. If the file name entered here is already in use the operation will end and you will need to check for any files not converted." default answer NewFilename)
end try
end if
try
set theCounter to 0 -- initialized variable theCounter
tell application "AppleWorks 6"
activate
open thisFile -- alias reference is ok
save thisFile using translator theTranslator with NewFilename -- fixed the reference
close front document without saving
set theCounter to theCounter + 1
end tell
on error theError
display dialog theError
end try
else
(display dialog "This is not an Appleworks document and will not be converted")
end if
end tell
end try
display dialog "Congratulations! " & (theCounter as string) & " files have been converted from AppleWorks 6 file format to Microsoft Word file format." buttons {"OK"} default button 1
3. Run the script for each folder of AppleWorks files. It will convert your files while retaining the originals.
4. Duplicate the folder on your desktop once you have all files converted.
5. Go through one of the folders, sorting by file type, then deleting the cwk files from one and the doc files from the other.
6. Store your cwk files safely and then move the doc files to your Vista PC.
7. Follow the instsruction found here
http://www.ehow.com/how4869590open-file-using-microsoft-works.html
to open the doc files in MS Works.
Good Luck!

Darren's Weekly Nugget 06/19/2006

Have you noticed the new "Call Setup..." menu option when right-clicking subVIs in LabVIEW 8.0? It's a really handy way to clean up your diagrams, and improve the load times of your VIs:
The code in the two frames is functionally equivalent. In the second frame, I simply dropped the subVI on my diagram, right-clicked and chose Call Setup. Then I selected "Reload on each call". That makes the code function the same as doing an Open/Call By Reference/Close, like in the top diagram. If I had selected "Load and retain on first call", the VI would be loaded into memory the first time it is called, but its reference would be kept in memory if the code is ever called again (like if this frame was in a loop). If I had selected "Load with callers (like subVI)", it would behave exactly like a normal subVI (and the little "Call By Reference" halo around the VI would be removed).
So in this example, we are using Call Setup primarily to clean up our diagram, since both frames do exactly the same thing. But there are some cases where it can improve performance as well. One example where I have used Call Setup is in the VI Analyzer 1.1. The subVI we use to load a configuration file in the VI Analyzer is rather large (with hundreds of subVIs). In VI Analyzer 1.0, this subVI was called statically, meaning whenever you launch the VI Analyzer from the menus, this VI (along with everything else in the VI Analyzer) had to be loaded into memory. In VI Analyzer 1.1, we used Call Setup on the file loading VI and selected "Load and retain on first call". This improved the VI Analyzer launch time quite a bit, since now we only load the file loading VI into memory if the user needs to load a VI Analyzer configuration file. In other words, with version 1.1, the waiting time it takes to load the file loading VI is only experienced by users who need to load a configuration file...with 1.0, everybody had to wait.
-D
P.S. - Check out past nuggets here.
Message Edited by Darren on 06-19-2006 12:38 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
Call_Setup.jpg ‏149 KB

Hello Darren, i have a major problem with the call setup.
You mentioned that there are no more problems when the connector pane changes, well i couldn't figure that one out.
I have a large Application where i use a lot of the call setups when i made some chenges in the connector pattern i never get an error message.
When i build the exe file there is no error message coming up during the build process, it only comes up when the programm reaches the call and the error message only says :
Error 1031 occurred at Call By Reference Node in Untitled 1
Possible reason(s):
LabVIEW: VI Reference type does not match VI connector pane.
With this kind of error message i can't even find out which Vi the error caused,
so i have to check each call setup in the VI.
This is even worse then in the old style, because if you had an error there you also saw which VI it caused.
So what possibility is there to make a general test of all VIs loaded with a call setup?
It seems to me that with the call setup the connector pane is picked once when you create a call setup from the normal vi,
and it only updates the connector pane when you do again your right click and set the call setup again.
why does it not normaly update the actual connector pane???
I also didn't understand that in the LV 7.x Version. because there was the same problem with the conector pane.
Why isnt there a possibility to auto update the connnector pane????
Greetings Daniel

How to terminate VB process that calls VI Dll Library when application closed

I have simple VB application to call VI DLL library. The problem is the VB executable file will reside in processes list even close the VB application. Looks like VI DLL does not free from memory when VB application unloaded. Did I miss something to terminate or unload VI DLL in VB program or VI program?

Well, I'm afraid we're down to good old-fashioned debugging tricks - something is happening that the OS doesn't want to kill. You can try to comment out sections of the VI (new feature in LV 8.2!) to see when it starts to work, or review the code looking for things like event handlers, callbacks, mutexes, open file handles, etc. It's hard to say what going wrong at this level. Also if you are calling out to 3rd party code (Call Library Node, ActiveX, .NET), make sure that it isn't creating such items and holding onto them.
General rules of thumb...
1. If you don't have a shutdown VI, or some sort of reference close VI, each VI you call from outside (DLL function) must exist with nothing left in LabVIEW - for example, no registered event handlers, no open file handles, etc. Just like camping, "leave it like you found it".
2. If you do have such a shutdown, ensure that everything is indeed being shutdown correctly.
Sorry I can't be more specific.
Brian Tyler
http://detritus.blogs.com/lycangeek

VI front panel won't close when it's done executing, when this vi was called by reference.

I've created a simple vi set to demonstrate the issue I'm having. I'm dynamically launching sub vi's from a main application. Simply put the main application is my test exec and the subvi's I'm calling dynamically are different tests. In the example I'm posting here the test vi is called Electrical Test 1.vi. I've configured this Electrical Test 1.vi to show front panel when called and close afterwards if originally closed. Problem is it won't close the front.
Other things to keep in mind
I want to be able to launch the test vi and not wait till it's done.
I'm using LabVIEW 2012 SP1.
Solved!
Go to Solution.
Attachments:
vi_launcher - v5.zip ‏73 KB

Basically the close after call only matters if the VI is called as a subVI (just like if you open a VI yourself and run it, it doesn't close when it is done). The two ways around this are to either have your top lvl app close the VI when it is done, this is explained here:
http://digital.ni.com/public.nsf/allkb/987B2026B41BD39786256CF800032E8C
or to have your VI close itself when it is done. Use a This VI reference and the Front Panel:Close invoke node.
Hope this helps.

Do I need to close ActiveX references?

Hi,
I am developing a library of VIs that use ActiveX to control APWin (for Audio Precision System Two) with LabVIEW where both are running on the same PC and I am wondering if I need to close ActiveX refnums when I'm finished along a particular heirarchy level. The context help says that LV closes references when they're no longer needed but is it bad practice to leave them open? Can not closing refnums potentially cause problems? See attached picture for an example.
Thanks,
Sara
Attachments:
close_ref.JPG ‏46 KB

Sara2004 wrote:
> Thanks for your response. This is good to know. I'm assuming the same
> is true for MSWord and MSExcel report refnums...is this a correct
> assumption?
You should generally close any refnum. LabVIEW 7 does have improvements
to its own refnums (App and VI refnums, Control refnums) which does not
require to close them anymore but doing so will definitly not hurt.
For Active X refnums, in the best case they just use up memory until you
close the entire application or the LabVIEW development system. In the
worst case the system can crash when you close the executable or LabVIEW
due to the Active X component stumbling over left open object references
when Windows forces those objects to be closed on behalve of the leaving
execu
table.
Rolf Kalbermatter
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Close vi reference doesnt close the VI?!

Hi,
I'm running an application that has several dynamically loaded listening threads. When running in interpreted mode while developing, I noticed the threads are not closing when I stop the main VI. To try to combat this, I made an event case:
This didn't appear to help either. That is when I read in the help menu on 'close reference' the following:
"When you create a refnum to a VI, LabVIEW loads the VI into memory. The VI stays in memory until you close the refnum and until the VI meets the following conditions:
There are no other open references to the referenced VI.
The front panel of the VI is not open.
The VI is not a subVI of another VI in memory.
The VI is not a member of an open project library."
So the last part is my problem since the VI is still a member of the open library in interpreted mode. Is there any way to force closure of these threads without having to restart the project?
Solved!
Go to Solution.

Actually no, it wouldn't. The abort is a hard close that shuts everything down immediately and won't allow you to do any cleanup. For any application I disttibute I hide the Run, and Abort buttons completely. Looking for the Application CLose, Panel Close and your own Exit/Stop is the proper way to close an application so you can do all of your necessary cleanup.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

How I can forced close the Citadel Trace References

On my application I write data to Citadel traces using "Database Writing
VIs" (Open Trace.vi .. Write Trace.vi ... Close Trace.vi).
Sometimes if my application "crash" the Close Trace.vi is not executed and that's why the "trace references"
are NOT closed.
When start my application again I get error: "There is already an open writer for the selected trace."
This is natural because the references are not closed when application crash.
My question: How can I solve problem like this?
Is there any function on the Citadel Engine what I can use to "force"
close all writer references, reboot engine etc, get references already opened?
An attachments there is example VI and EXE.
Attachments:
CitadelTest-LV2011.zip ‏531 KB

Hello Mikko!
I can see that we have Services as NI Citadel 4 Service and NI Citadel 5 from Services in Administration tools. Can you try to restart them and see if the effect is something that you need. From then maybe we could try something out.
BR,
Make Nguyen
NI Finland Technical support.
Attachments:
citadel.png ‏151 KB

When does LabVIEW actually close object references?

I wanted to find out how LabVIEW manages references to objects when a reference is distributed among more than one property node located within different structures. So I created a little test where I passed a reference into a for loop, modified the referenced object with a property node and closed the reference inside the loop, then ran the loop several times.
To my surprise, the VI ran without generating any errors. This doesn't make sense because once I closed the reference in the first iteration of the loop, when the second iteration occurred, the reference should have been invalid. Why did I not receive any errors?
This begs the question: what happens to references when they are passed to more than one
location within a VI? Does the reference need to be closed each time it is used, or only after it's been used for the last time?
Also, if the cluster "controls[]" property is used, do the references to all of the controls within the cluster have to be closed as well as the reference to the cluster itself?
This issue is very important to me because I am developing a very large VI that is meant to be run for days at a time, and at the moment, there is a memory leak in the program. I want to make sure that all of my references are closed before exiting any sub VIs and I'm not positive that simply closing the original reference passed into a sub VI is actually freeing up all of the memory. On the other hand, I'm afraid of closing references after each time they are used if they are going to be used again in the same VI before it finishes executing.
Does anybody have any insight on this matter?

> I wanted to find out how LabVIEW manages references...
Unfortunately, this depends a bit on which version of LV you are using.
It was changed for LV6.1 to ensure that front panel object references
wouldn't cause memory leaks, or more correctly, memory hoarding.
In LV6, the guideline is to close the reference the same number of times
you opened it or asked for its value. Opens are easy to spot. The
asking needs some more explanation. When you read the Controls[]
property for a cluster or the panel, you are asking the cluster or panel
to provide you with a bunch of references. In LV6, these were unique
references each time they were asked. If you do not want these
references to build up, your diagram needs to call Close on each of the
asked or opened references. Technically these aren't a leak since LV
still knows that they are allocated, and when the top-level VI finishes,
LV will clean them up. But in applications where the top-level VI run
continuously, then this hoarding of memory is the same as a true leak.
The size of the leak per reference is something like 20 to 40 bytes, so
not huge, but still a leak/hoard.
In LV6.1, the asking for references changed. They always return the
same reference, and it is a reference that cannot be closed by the user.
Trying to close it is not an error, but it will be ignored. This
means that the first time someone wants a reference to a control, a
reference is generated, and it will be the reference that is returned
everytime someone asks for the control reference. If your diagram calls
close already, no harm. If your diagram doesn't call close, no harm.
When this panel leaves memory and the reference no longer makes sense,
it will be torn down.
I need to make it clear that the new LV6.1 behavior is for control
references that are asked for. References returned from Open are the
same as before and should be Closed. So this doesn't affect VISA, File
I/O, and other types of references, it is specific to front panel
references.
In case it still isn't clear why the behavior changed, we started seeing
many diagrams written such that they leaked or hoarded memory. In
reality, spotting where a diagram asks for a reference is hard, and
everyone was missing them some of the time. So we changed the
implementation to be more forgiving. The downside is that LV now hoards
one reference and you can't tell it that you are totally finished with
it, but it is no longer a leak.
I hope this sheds some light. If you have additional questions, just ask.
Greg McKaskle

VI reference close

Similar Messages

Maybe you are looking for