01-26-2017 10:14 AM
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.
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.
Same with the auto jpeg state.
01-27-2017 03:40 AM
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
01-27-2017 04:21 AM
@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?
/Y
01-27-2017 04:24 AM - edited 01-27-2017 04:24 AM
The last descriped problem does allready happen in "idle mode", when nothing gets saved.
01-27-2017 05:51 AM
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.
01-28-2017 02:40 PM
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
02-11-2017 11:17 AM - edited 02-11-2017 11:23 AM
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