View Full Version : LabVIEW memory usage, bug in IC_Grab_IMAQ.vi

February 1, 2011, 23:54:22
I am using IC Imaging Control 3.0 / IC LabVIEW Extension 2 within LabVIEW 2010 to perform particle analysis at 30 images/second. My little program ate the memory up really quick (10 Mb/s) and accordingly the program crashed after ~5 minutes. The culprit was the IC_GRAB_IMAQ.vi, which just kept adding images to the memory without deleting them. I found that the IMAQ_Create within the VI didn't have an Image Name. Adding a string name solved my memory problem, since the image was now overwritten in each loop iteration.

I don't know whether any other people ran into this problem, but I thought I would share this info.

PS: Alternatively, one could just dispose the image after usage, as recommended in the IC LabVIEW Extension documentation. However, this did not work for me as I still needed to see the current image in a LabVIEW window.

Stefan Geissler
February 2, 2011, 09:28:39

even other people run in this problem. But is was wanted, that the Grab.vi creates a new image and the rest of the application is responsible for deleting it.

February 2, 2011, 10:18:26
Thanks for your response. I understand that it is wanted that the programmer has to delete the image him/herself. However, this was not my problem. The problem was that each time the IC_Grab_IMAQ.vi was called, LabVIEW allocated new memory for the image instead of overwriting the image from the last instance IC_Grab_IMAQ.vi was called. Maybe this is wanted behavior. If so, what is the advantage of that? For me as an amateur LabVIEW user it is counter-intuitive, since the images generated by IC_Grab_IMAQ.vi during previous calls don't have specified names/are not put into a matrix - I would not know how to access them anyways.

Stefan Geissler
February 3, 2011, 13:26:33

If the image is not created new, you must pass an image with the size and pixel format to the grab vi on your own. At least, I am also no LabVIEW expert.

January 20, 2012, 10:08:05

I had similar memory leak problem, it took a while to find out the cause - open references.
In order to avoid memory overfill in LabVIEW, you must close all created references.
The problem is that it is not self-explanatory, where the references are created.

Explanatory block diagram Forum.jpg: 1445

See the explanatory diagram, I marked with red arrows the places where the references are created.
All they have to be closed. Supposedly in a correct order - opposite to their creation.
Even if you create a property node and do not wire it at all, it occupies memory.

Now I can run simultaneously four USB cameras DMK 22BUC03 ,
Y8, 640x480, 30 fps, each separately asynchronously hardware triggered.
Labview 2010 SP1, no memory leak detected.

PS: The problem with finding the file "IC LabVIEW Extension 2.dll" I solved just with creating the path
"C:\Programme\National Instruments\LabVIEW 7.0\user.lib" and copying the file there.
Now it is found in every computer with no problemo.

April 5, 2012, 18:22:27

I have the same problem.

Then I tried to name the image in IC_Grab_IMAQ.vi but it did not work. I am posting my sample .vi. Could you all please help me to find a solution cues my RAM memory is full after 2 min and an error a cures.

How can I prevent this ?

Simple answer for you just a click away !


Stefan Geissler
April 10, 2012, 09:13:23

The IC_Grab*vi creates a new image each time it is called. That means, the using program has to delete it, when it is no longer used.

April 20, 2012, 18:45:12
Hello Stefan,


But I want to display the image so the program is more user friendly please understand that. I have read in this topic that guys could fix that problem with memory leak and still display the picture.

@Ari wrote in his first post that he named the new picture in IC_Grab_IMAQ.vi but that does not work for me.
@Ari help ?!

Stefan, OK I tried to use the function IMAQ Dispose and it had work using IS USB camera but not with IS Fire Wire camera.
Is the problem W7 x64 or IC Imaging Control 3.2 ?

How can i delete the buffer usinf Fire Wire camra ? Should I use a lover IC Imaging Control version ?

Stefan Geissler
April 23, 2012, 08:11:04
Stefan, OK I tried to use the function IMAQ Dispose and it had work using IS USB camera but not with IS Fire Wire camera.
Is the problem W7 x64 or IC Imaging Control 3.2 ?

There is no difference between the cameras in IC Imaging Control. It must work exactly the same for grabbers, FireWire, USB and GigE cameras. IC Imaging Control is hardware independent. Therefore I wonder, what you change, when using FireWire instead of USB cameras.

You can change the IC_Grab_IMAQ.vi in this way, that you create the image using the correct size out of the vi and pass it into the vi. In the vi you simple remove the part, that creates the new image and use the image, that you created outside instead. In this case, the image will be created only once and you do not need to dispose it in your program's loop. I suppose, this will solve your problems. You only need to take care of the image dimensions, so you will not receive an access violation.

Our VIs can be changed by the user to his own needs.