Diagnosing a Memory Problem

[Gregory]

Hi Ravensfan,

I see, I think it would take a bit of effort to get the camera running in a separate executable. As far as accelerating the memory error... I made a Picture Input to pass the previous image into the "Get Image" VI, because I am used to working with imaq images. I think this caused each picture to be written on top of the previous image and caused a memory error in about a minute. But, I don't think this is what is actually happening when a blank Picture is being used as the input.

[Gregory]

---

@Ben wrote:

The 2D picture control has a right-click option "erase first" which when set will clear the indicator.

Generally...

You should be using the Profile Memory over a long period of time to try and spot which component is using up the memory. If all else fails, start whacking large portions of the code to ID what part is leaking. 

Ben

---

Hi Ben,

I did find a subVI that had "Erase First" unchecked. So I changed that and we'll see if it helps!

Hi Jeff,

Thank you, I fixed that forked reference just now. But I should add that Desktop Execution Trace Toolkit has an option to capture "reference leaks" which comes up with absolutely nothing when I run the application. 

[zou]

Acquisition refnum doesn't get closed.

Is there a method to dispose Memory ?

[Gregory]

Hi George, 

Thank you I'll go back and close that reference. Are you asking if the camera has a "Dispose Memory" method?

Hi all,

When the image is converted to a picture, the input array is decimated and joined (I guess to create the RGB format) and then resized. I have heard that continuous resizings can hog the memory, is there a better way to do this?

[mcduff]

I do not think this is your problem, but it may reduce memory a bit. The decimate array is probably the fastest solution, but each output array has its own memory space. I think LabVIEW should be reusing those buffers for each iteration, but who knows. I have something from years ago that is similar, a Princeton CCD camera, you should modify for your purposes. I did the following to save a bit of memory.

cheers,

mcduff

[Jacobson-ni]

---

@Gregory wrote:

I have the camera streaming in a separate module, should I just close it and relaunch it every couple hours?

---

Do you see the application memory constantly increasing over time? If that's the case, you probably don't have to wait the full 30 hours to know if your changes worked.

Depending on how you have separated each of these modules you could also try stress testing each one individually. There is a good chance that the camera will run at more than 10Hz so possibly just monitor memory as you request images as fast as you reasonably can. You could also go the opposite way and remove the camera from the system. Save a few sample images and instead of querying the camera, just use one of these images.

[zou]

Wire an invoke node  to Memory, see if you can find a method of Dispose.

Some C# objects require users to call Dispose explicitly before close.

[JÞB]

---

@Gregory wrote:

---

@Ben wrote:

The 2D picture control has a right-click option "erase first" which when set will clear the indicator.

Generally...

You should be using the Profile Memory over a long period of time to try and spot which component is using up the memory. If all else fails, start whacking large portions of the code to ID what part is leaking. 

Ben

---

Hi Ben,

I did find a subVI that had "Erase First" unchecked. So I changed that and we'll see if it helps!

Hi Jeff,

Thank you, I fixed that forked reference just now. But I should add that Desktop Execution Trace Toolkit has an option to capture "reference leaks" which comes up with absolutely nothing when I run the application. 

---

It may be that the compiler was smart enough to deallocate the unused ref copy.  Magic and mayhew in that optimizer. 

[Gregory]

Hi George,

The .Net interface does have methods for "Allocate", "Free", and "Clear" memory. The Allocate method is called when the camera initializes.

Allocate: Allocates an image memory for an image

Free: Releases an image memory and removes it from the driver management

Clear: Removes all image memories from the sequence list

As far as I can tell, the Active s32MemID stays at 1 for the duration of the program, so I don't think I want to use the Free method until closing the camera.