Max continuous fps using imaq and LabVIEW

[BlueCheese]

---

@BruceAmmons wrote:

 I still think the Extract adds unnecessary complexity - if you get to a situation where it makes a difference, you are already a full buffer behind and you will get a processing error.

Bruce

---

Sure, but I guess it matters whether you want an buffer overridden error to be a fatal error and possibly generate some bad side effects in the meantime or have your application just continue by dropping a few frames. If you don't use Extract, you can only detect the condition _after_ doing your processing. This is fine if all you want to do is throw up an error and abort and ignore some of your previous data. However, in the given scenario of logging to disk, you can't really go backwards and remove the incorrect data from disk in realtime and continue processing new data using that method (well, I suppose you could, but that would be fairly painful). If your processing has side effects such as interacting with external systems, processing possibly-corrupt data might be an issue. The solution with Extract prevents any bad data from ever being processed/recorded in the first place.

Eric

[BruceAmmons]

You could just monitor the difference between Last Valid Frame and the last image processed.  If it gets bigger than the buffer size (or some percentage of it), you could skip some frames to catch up, log an error, warn the operator, or whatever.  I would probably turn on a warning indicator if the difference is greater than half the buffer size in most cases.

This approach has worked well for me in several applications, and it minimizes the overhead of IMAQ calls.  Perhaps it only works well with large buffers and fast processing, but I like it.

Bruce

[drummaniac83]

Currently, the extract/array method is being implemented mainly b/c I already had that extract function...so a little easier to modify.  However, I think both would work well and I agree with Bruce that if you're falling behind, you'll eventually overrun your buffer anyways.

For my application, there is very little processing.  Basically just a copy into a large mosaic image of 16 smaller images so I can write them to disk in one big packet (4MB roughly).  This optimizes my write speed for my SSD RAID array. 

My system ran fine when I was pushing 1600MB/s of data to disk, but I was capturing larger images at 285 fps (2 cameras).  Now, trying to capture 640x480 at 2400 fps is when the system can't keep up.  This is less data, so I think the extract is definitely the limiting function.  I tried disabling the copy function just to verify that wasn't the problem.

Manually managing the IMAQ references seems like such a duh solution now.  Embarrassed I didn't think of it 🙂

[drummaniac83]

We eventually finished this project.  I have some best practices if anyone has problems doing this in the future.  Just message/reply and I can provide some guidance.

[Optics_Eli]

Hi drummaniac83,

I'm trying acquire frames at 90KHz, using NI-IMAQ. We have a line scan camera (1024 pixels, 12 bits each) and a PXIe-1435 frame grabber.  We're triggering at 90kHz, but only getting ~2kHz. I've only tried running Labview Example VI's and "Producer-Consumer Stream to Disk.vi". I'm pretty new at this. In my understanding, each time "extract" is called, it only extracts the buffer corresponding to number supplied to it. Buffer numbers are supplied to extract at a rate of  2kHz, so we only are getting a "processed frames per second" of about 2k, while the "acquired frames per second" is 90k.

How can I make sense of these conflicting numbers and what is their significance? Also do you have any ideas for getting up to the full triggering rate?

Thanks very Much!