NI 1433 high speed stream to disk with ring acquisition

[drummaniac83]

I'm currently using an NI 1433 with a Camera Link Full 10tap camera.  I am attempting to stream data at 2000fps to disk at 640x480.

This seems to work fine using the method described by Brent Runnels at NIWeek 2007 (ppt attached).  However, whenever I set my acquistion buffer size greater than 64, my fps crashes to 150fps.  I am using the queued ring mosaic acqusition method, and the bottle neck seems to be the insert into the writing queue 

The reason I need to increase the # of buffers is so I can display the image on the front panel without losing frames.

Thanks for any insight someone can offer.

Josh

[Ever_Song]

Hi drummaniac83,

First off, could we get your code (or a screenshot thereof)? Second, could we get a little more information about your setup? Such as:

- What camera are you using?

- What version of LabVIEW are you using? Also, is it 32 or 64 bit?

- What version of the IMAQ driver are you using?

Also, I am curious if we see a similar fps drop when running the LL Ring shipping example (albeit not at the 2000fps) just to see if it is the allocation of the buffers that is causing the slowdown.

[drummaniac83]

Ahhhh an AE....good I wanted to bring you guys into the loop as well.

K back in 2007 an NI employee (nameless for public purposes) devised a way to truly get ridiculous streaming speeds for vision applications since the built in storage methods have difficulty over 200MB/s

The library that he developed is attached.

I am using 10_ll_ring_write_mosaic_queue.vi with a vieworks VC-3MC-M280C.  This camera is 10tap 85mhz rated and pushes 830MB/s maxxed out.  Our customer wants to run 2 of these simultaneously with an ROI reduced to 640x480 for 2288fps.

The VI that I mention takes images, groups them into a mosiac and then writes the mosiac image to a binary file using win32API.  It uses queues with a ring acquisition to prevent lost frames and maximize streaming speed by writing in largers chunks (mosaic image is 4MB).

For some reason when I set my # of acqusition buffers to anything above 64, the system gets bottlenecked inserting them into the write queue.  However, once I increased the number of images in the mosiac to 250, this bottleneck disappeared and I was able to write at maximum throughput.

So while I have solved my issue, I'm not sure why.  I'm hoping someone can re-create this, but beyond that I wanted to share this knowledge to anyone trying to do really high speed image recording (1400MB/s)

I think somewhere around labview 8.6, the binary file VIs were updated and optimized, so perhaps this method doesn't require the win32API anymore

Let me know if you have anymore questions.  I hope this can help someone else!

[Ever_Song]

First, thanks for posting the code. The algorithm is very impressive and should definitely be helpful for anyone who needs to stream an acquisition to disk very quickly. Kudos.

As for why we were seeing the fps drop when using the larger number of acquisition buffers, and the subsequent solution of increasing the number of mosaic images, it think what is going on is that we are seeing an issue with memory allocation with the queue. Increasing the number of buffers causes a bottleneck at the enqueue since it is dealing with a larger list of buffers. Increasing the number of mosaic images effectively increases the size of the memory allocated for the queue and thus we do not see the drop in fps as there is enough memory space.

One way that might help would be to pre-allocate memory for the queue by first enqueueing elements and then flushing the queue (as discussed in the help here). If necessary, I can try to duplicate the issue but I will need to track down a 1433. Once again, thanks for posting this fantastic example.

[drummaniac83]

Bill,

I've finally gotten all the nuts and bolts hammered out on my acquisition but upon adding the second camera I've run into a CPU issue.  Utilizing the framework I already posted, I am trying to run 2 simultaneously.  I've found that when processing larger frames at lower frame rates the system functions fine (think 1700x1700 at 285 fps).  However, when running at a lower resolution at a higher frame rate the architecture can't keep up (640x480 at 2400fps).  Remember I am running 2 cameras at a time.  One camera works fine, but 2 is where it starts to choke.

Because the system runs fine at a high total data rate, I dont think it is a hard drive bottleneck.  I think it is related to the IMAQ extract buffer or possibly the IMAQ copy being too CPU time intensive.  Does anyone know if you can pull off an array of buffers from a Continuous Ring IMAQ Acquisition?

I've tried pipelining the IMAQ Extract Buffer VI so that the IMAQ copy and the IMAQ Extract Buffer VI can be done in parallel.

Anyone have any advice?

Thanks so much

Josh

[Cameron-T]

Josh,

I work on the same team as Bill. I believe the example LL Sequence.vi (found in Help >> Find Examples...) does something similar to what you are looking for. It creates an array of buffers using a for loop.