IMAQdx Close Camera memory problem

[wet_shoes_83]

TLDR: I have an IMAQdx Open Camera vi without an IMAQdx Close Camera. Is that bad?

Hi,

I have a program with three independent, parallel loops which execute forever. One loop has an event structure with an IMAQ Dispose vi. It executes when the stop button is pushed. IMAQ Dispose is wired to destroy all the images created by IMAQ Create. That’s good, but I’m worried about IMAQdx Open Camera.

I’ve read that IMAQdx Open Camera should always be paired with IMAQdx Close Camera. I assume that Close releases the memory allocated for the camera reference when Open is called. Is this memory released when the main VI stops?

Normally, you place IMAQdx Open Camera before a loop, IMAQdx Grab 2 inside the loop to continually display the camera’s output, and IMAQdx Close Camera after the loop. But now I’m juggling multiple loops and the dataflow never exits the camera loop in my program. Windows Task Manager’s utilities suggest that the computer performance is unaffected.

[b.ploetzeneder]

1) IMAQ Dispose has nothing to do with IMAQdx Close camera. So nope, doesn't help.

2) I can't tell you much about the internal memory handling of the IMAQdx references. Since you open them by name of the camera, which can be a string, I assume they are not unique/random, so it shouldn't be too much of a problem if one remains open. That is an educated guess, not certainty. 

3) The main problem with not using IMAQdx Close Camera are usually cameras, not the driver itself. Plenty of cameras have internal state machines and expect some "I'm done" command. Especially GigE cameras, with their "lock" parameter can get super annoying with that. Took me forever with one project to figure out why I had to "powercycle" a camera to reconnect..

4) You should really look into the producer-consumer architecture, especially message-based. It will make your code much cleaner and you won't have to worry about stuff like that.

5) Failing that: At least implement a functional global variable that stores your camera session reference. You can access that from different points in your code and call a "close" command..

[Bob_Schor]

So how do you get out of the "Read Camera" loop?  I presume you have something wired to the Stop indicator.  What I do is to have Close Camera either in the Exit State (if I'm using a State Machine) or on the "just-exited" outside of the While Loop so that I never even have to ask the question.

But now that you've asked, I'm 99.44% certain that when your Program exits, the Camera Resources being used by the Driver will be released.  This will especially be true if you exit LabVIEW (or if you are running your code as an Executable).  But going back to the previous paragraph, there is really (almost?) no excuse for "not cleaning up after yourself".

Bob Schor

[wet_shoes_83]

B. Ploetzender,

Thanks for the advice. My coding skills are at the level where I've never heard of producer-consumer architecture, so I'll definitely look into that, as well as the global variable fix.

[wet_shoes_83]

Bob,

I never do exit the camera loop. It's not a great design, but it works.

[Bob_Schor]

If you never exit the Camera loop, how do you stop your program?  You aren't using Abort, are you?  That's not the proper way to exit!  It would be "interesting" to see the code ...

Bob Schor

[wet_shoes_83]

Bob,

The CamLoop.jpg attached to my original post shows how the program terminates.

[Bob_Schor]

My apologies.  I originally answered your question (without looking at the picture of your code), and never went back to check out the picture.  You are using the "Abort" method of stopping your program.  As the Help for the Stop function explains, this is not the optimal way of stopping programs, as it leaves them, and any connect hardware, in an "unknown" state.  A much better place to put the Stop button is inside the While loop, bring the IMAQdx wire out, and do a proper Close Camera when exiting.

Bob Schor

[wet_shoes_83]

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LmXSAU

Useful article on stopping parallel loops, though no information on memory allocation as it relates to IMAQdx Open and Close

[Bob_Schor · Accepted solution]

As it relates to Memory Allocation, it should be the case that when a LabVIEW program stops/aborts/exits, the memory that its various pieces (like the DAQmx Driver) should be released and freed, but I suppose there is always a possibility that there's a bug somewhere that "hogs" memory (though I doubt it).

As has been pointed out, going through a proper Shutdown procedure that includes closing the Devices is your best bet to ensure that the hardware is left in a Good Place.  One responder mentioned some GigE cameras can hang up if not properly closed.

A final argument (kudos for finding the article on Loop Shutdown) is that paying attention to how all the parts of your program interact and starting and stopping them properly makes it more likely that you've got a good grip on the multiple loops and routines you are using, and thus more likely that it will do what you what (in addition to, of course, doing what you told it to do).

Bob Schor