Showing results for 
Search instead for 
Did you mean: 

IMAQdx Acquisition - grabbing not fast enough

Go to solution

I think you have two race conditions going on.


I tested running your code with my webcam (only 20fps), and every time I hit Record with "Auto AVI" selected, it only saves one frame and stops. I put a "Flush Queue" before you enqueue "auto avi write", and that solved the recording stopping immediately.


Start race condition



Second race condition comes up because you're disposing of the image in the preview loop. This means there's a chance the image will get released from memory before it can be written to the file. Move the IMAQ Dispose to the Saving loop instead. This ensures that the image will only be released once it has been saved to disk. 


auto avi.PNG


Same with the auto jpeg state.

auto jpeg.PNG



Message 11 of 17

Thanks a lot for debugging the VI and for the ideas.


That makes the functionality work, but somehow I get problems with memory.

If I shift the IMAQ Dispose to the saving loop as you recommended, the memory will overflow very quick.



If I remove the consumer loop and the queue of imaging, then I get the an error that IMAQ Get Image gets an invalid pointer... But only for high frame rates.

I don't know... tricky...


If someone has another idea, that would be great.

New VIs attached.

Best regards




Download All
0 Kudos
Message 12 of 17

@2Mb/picture you'll use 1Gb in 2,5 secs if you keep all images in memory, so how fast can you write to disk and free up memory?


G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
0 Kudos
Message 13 of 17

The last descriped problem does allready happen in "idle mode", when nothing gets saved.

0 Kudos
Message 14 of 17

Well I went back to the structure ng1902 recommended,

and somethimes it works stable in "idle" state

and sometimes it doesn't which means that RAM usages is increasing (e.g. suddenly).


I don't understand that, because the queue isn't growing and that means every buffer should get disposed with the iterations.


Download All
0 Kudos
Message 15 of 17

Sorry, I was away and not checking this thread.


I went back and looked at your implementation of the Queue idea I mentioned.  I apologize if I wasn't clear, but you don't put images on the Queue, you put the buffer number of the image on the Queue.  This is blinding fast, and leaves the "big structures" (the Image) in the Camera Driver.  Now, when you are ready to write the Image to an AVI, you use the Buffer Number (and the Camera Reference) to get the Image (use a fixed Image that you create one and use over-and-over again) and write it to the AVI.  This should simplify things and speed them up to the point that the "bottleneck" will be how fast you can write your AVI frames.


Bob Schor


0 Kudos
Message 16 of 17
Accepted by stefan123

Hello again,

finally I got a solution and the programm is running as it should.

Some things that have been neccessary:

- turning "fast-mode" in NI MAX on to get 200 fps

- only use one loop for previewing and saving (otherwise race conditions if "IMAQ dispose" in both loops or RAM overflow if only in one of the loops)

- slow previewing down to less then 35 fps because CPU or GPU isn't managing quicker

- restrict the queue size to prevent RAM overflow (500 frames fill 2 gb)

- also make correlations of max capture duration to this limit, because CPU/GPU can only write avi with min 10 ms/frame and jpg with min 15 ms/frame


What I would definitily do next time is to use a "queued message handler" design pattern because otherwise you need a lot of work arounds to ensure that state-queues aren't written by 2 instances at the same time.


If anyone is interested, the VI is attached.


Thank you all very lot for taking a look and advising me with the problems.

Best regards, Stefan

Download All
Message 17 of 17