IMAQdx Grab images using buffer in memory

[Baturin]

Hello!

I am writing an app which is intended to grab video from GigE camera AVT Prosilica GX 1050C and save it in AVI with loseless codec (or uncompressed at all). Camera gives 112 fps at 1 Mpix through two aggregated GigE ports. Such data stream is quite fast and it is not possible to just save it to HDD. Although I will soon experiment with RAID, I would like to ask several questions about buffered acquisition in IMAQdx.

I don't need to ackquire video indefinetely, bit it is required to make it as much long as possible. One or two minute would be enough.

1. I am using Configure Acquisition witn continuous mode and N nmber of buffers and then continuously run "Get Image" in a loop adding it to AVI file. If I undertand correctly, specified number of buffers are allocated in RAM and GigE driver continuously acquire images into this ring buffer. When I run Get Image specifying buffer number and increment it in each cycle I should obtain continuous sequence of images from camera taken one after another. This will continue untill requested frame will be already overwritten by newer one.

Is such approach correct?

2. I can only specify about 3000 buffers. 3500-4000 already gives "Not enough memory" error. LabVIEW process in this case takes approximatey between 1.5 and 2 Gbytes of RAM while the total amount is 16 Gb. Is this limitation due to 32 bit LabVIEW? Does LabVIEW x64 works with IMAQdx as well?

3. How is it possible to check for a buffer state? I am trying to use "lost buffers count" property node, but always get zero.

Else, if I set Overwrite mode to "Fail" the error that "requested buffer number unavailable" is thrown out.

I there any way to monitor the ring buffer "level"? Or just compare the difference between acquired number of frames and frame rate multiplied by time elapsed...

4. Is it possible to get already acquired, but not read buffers when acquisition is already stopped, but not unconfigured?

Thanks in advance for any replies 🙂

[AdnanZ]

I will try to answer some of your questions. I believe you are correct in your approach.

The amount of memory LabVIEW can utilize depends on the version and operating system used. Have a look at the following:

How Much Memory can LabVIEW 32-bit or 64-bit Use?

As a rule of thumb, always try to use LabVIEW 64-bit when developing Vision applications especially if you have to do high rate acquisition and analysis. You will notice that LabVIEW Vision Development Module is one of the few modules supported for 64-bit precisely for taking advantage of the memory available with 64-bit. https://www.ni.com/en/support/documentation/compatibility/09/national-instruments-product-compatibil...

[BlueCheese]

Yes, your approach is correct to make use of ther ring buffer.

I second the idea to use 64-bit LabVIEW. You will then have no limitations (besides host memory) on how many images you can allocate. With 32-bit LabVIEW the processes's memory space gets very fragmented and it is hard to allocate huge amounts of images.

"Lost buffers count" returns images that were dropped at the driver level, not at the ring level. If you are using a large number of buffers in the ring then this should never drop images there because the driver can always get extra buffers. Whether your loop is keeping up or not is independent (if you never grabbed any images, the driver would just keep looping over the same ring again and again). If you want to see images that your loop skipped, you have to do it in your code. You would compare the output buffer number to ther input number (or set the overwrite mode to fail, like you did; this makes it fail when the buffer you requested is not available anymore).

Sorry, it is not possible with our aquisition model today to get images after stopping the acquisition (but before the buffers are free'd by Unconfigure). We are looking to this for a future release though.

Eric

[Baturin]

BlueCheese, AdnanZ, thanks for your answers. Nice to hear that I more or less correct in my understanding of the approach :).

LabVIEW x64 is being installed, I will try tomorrow.

[foxx]

I tried to make the same with IMAQdx.

Its a pity that there are only examples from 2006:

https://forums.ni.com/t5/Example-Code/Pre-and-Post-Trigger-Saving-to-Disk/ta-p/3996167

i think they could be good but it refers on IMAQ.

So, the configure list vi is no more available in IMAQdx...

does someone has newer versions from the examples?

[GuenterMueller]

Did you take a look at the "Low-Level Grab.vi" that is part of the examples that come with NI IMAQdx?  It calls "IMAQ Configure Acquisition" which allows to specify the "Number of Buffers" - which does what you are looking for.

[foxx]

Servus Guenter,

thank you for your reply.

What is the best-practice sequence for the IMAQdx?

My proposal (in IMAQdx not IMAQ Elements wording):

IMAQdx Open Camera --> (IMAQdx Read Attributes) --> IMAQdx Configure Grab --> IMAQdx Configure Acquisition --> IMAQdx Start?

Are there any example anywhere with IMAQdx elements?

thx

[Prickly_Pear]

There would be no need to do an IMAQdx Configure Grab and IMAQdx Configure Acquisition. Configure Grab is just like configure acquisition except that that it automatically sets the Continuous? attribute equals Continous and Number of Buffers equals 1. Also, Configure Grab will automatically start the grab, so the Start function would not be necessary.

I think that you whould look at the Low-Level Sequence VI in the NI Example Finder. It first opens the camera, configures the acquisition, then starts. Then, it has a For loop in the Get Image function. The iteration terminal of the loop is connected to the buffer number of Get Image, which places the images into their appropriate buffers.

Jeremy P.

[Baturin]

The idea with large buffers in LabVIEW x64 works OK. But there seems to be only half of the buffer available. The acquisition fails (overflow) exactly when  "total acquired frames" - "processed frames" becomes equal to buffers/2.

Is it correct?

The really interesting thing would be the ability to get all acquired frames from ring buffer after acquisition has stopped. But according to the above discussion this is currenty impossible. 😞

[LV_Warrior]

I saw that too. Before the difference between the write buffer number and the read buffer number becomes zero, the acquisition fails.

If that is true, you cannot use the full potential of the ring buffer, nor calculate the number of frames you can have before it fails.

I also noticed that the in buffer number mode the output buffer number is no longer equal to the buffer number input after a buffer overrun.

This output changes it's behaviour when a buffer overrun happens.

I attached a modified verion of the Low-Level Grab Async.vi demonstrating this