Showing results for 
Search instead for 
Did you mean: 

IMAQdx Buffer Number rollover discrepancy (?)

I am finding a rollover discrepancy in the Buffer Number when streaming images from IEEE-1394 cameras.  The Buffer Number appears to roll over at 2^24, but not consistently.  I'm curious to confirm whether this is expected behavior and/or whether the behavior is determined by the IMAQ drivers or by the camera hardware itself.


My system:

Windows 7 Pro

LabView 2013

Vision 2013

Camera: Point Grey Flea 2, model FL2-14S3M


More detail:

My system runs constantly 24/7 with a camera frame rate of 25 Hz.  I use the IMAQdx Get to collect images which are then processed in real time by my VI.   Before the acquision is started I set the Number of Buffers parameter of IMAQ Configure to 128 and the Buffer Number Mode to Buffer Number. 


Each iteration I set the BufferNumberIn parameter on IMAQdx Get to one plus the BufferNumberOut value from the previous iteration. To track the number of un-read buffered images (ie keep track of whether my VI is keeping up with the camera or whether the buffer is filling up) I read the property node IMAQdx:StatusInformation:LastBufferCount.  When my VI is successfully keeping up with the camera frame rate, the number of unread frames (buffer utiliization) is one, ie the difference between LastBufferCount and BufferNumberOut is one. When my VI is not keeping up, the buffer slowly fills up and this number grows, and is capped at 64 (ie half of the number of buffers, 128).  So far so good.


The trouble I run into is that after just over a week of runtime the number of unread frames computed as above appears to jump to over 2^24.  This is because the BufferNumberOut parameter appears to roll over to 0 every 2^24, but the LastBufferCount does not.  At 25 Hz, one would expect 2^24 to happen every ~ 7.8 days, which is what I observe.


My questions:

1.  Is the roll over behavior of BufferNumberOut from IMAQdx Get determined by the IMAQdx drivers or by the camera hardware?  The Help file for  IMAQdx Get seems to indicate that it's just a count of Buffers which I interpret to mean that the driver is counting. (?)

2.  Is it expected behavior that BufferNumberOut from IMAQdx Get would roll over but  IMAQdx:StatusInformation:LastBufferCount would not?

3.  Can I trust this behavior and if so is a valid work-around to simply compute the number of unread frames (buffer utilization) modulo 2^24?


all of these parameters are delivered as U32 from their corresponding IMAQdx functions.


Any assistance is appreciated.






0 Kudos
Message 1 of 4

Hi mjaspan,


The camera sends data but the buffer operations are handled by the driver. There is more information regarding buffers with acquisition in the NI-IMAQdx Concepts Help (that installs with Vision Acquisition Software). This can be located via All Programs >> National Instruments (folder) >> Vision >> Documentation >> NI-IMAQdx Documentation >> NI-IMAQdx Help >> niimaqdx_concepts.chm. Once you’ve opened the NI-IMAQdx Concepts Help you can navigate to NI-IMAQdx Concepts Help >> Basic Acquisition with NI-IMAQdx >> Acquisition Flow >> Acquistion.

There isn’t any officially released documentation that specifies the roll over per function (with few exceptions where it’s mentioned in the Detailed Help). If you’ve experienced the roll over behavior consistently then you should be able to count on that, and your mentioned work around would work. However, I believe that eventually you could see the IMAQdx:StatusInformation:LastBufferCount roll over as well. It might be better to consider implementing some form of programmatic restart, or manually restart the program more frequently.


I hope this information helps!


- Kale

0 Kudos
Message 2 of 4

Since you only have 128 buffers, if you calculate the difference mod 128, that would also work (and would continue to work if the next release of IMAQdx changed that hidden U24 quantity to a true U32, or even to a U16) ...


Why are you doing this, NI?


Bob Schor

0 Kudos
Message 3 of 4

Thanks for the feedback.  And good point about trusting that the workaround would survive future revisions to IMAQdx.  



0 Kudos
Message 4 of 4