Machine Vision

Showing results for 
Search instead for 
Did you mean: 

Trying to understand how the buffers work in Imaqdx aquisition




I'm trying to configure a  Basler Ace USB3.0 (acA640-750um), to do triggered burst acquisitions. Eventually I'll use hardward to trigger the acquisitions, but now I'm testing it out using a software trigger. I think I have it working, but I came across something that confused me.


I configured a  continuous low level acquisition with 10 buffers. Then I acquire the images using Imaqdx Get Image2 in a subsequent loop, but that loop executes 50 times. I manually trigger the camera 5x to get the 50 images. Initially I thought it would re-use the 10 buffers, but when I look at the buffer number for each image it goes from 1-50. Why is this?


If anyone could explain or point me in the right direction I'd appreciate it. So far I haven't found anything that would explain why this is the case.

Thank!Annotation 2019-11-08 155252.png

0 Kudos
Message 1 of 3



Unfortunately I don't think we have good resources that explain this concept, but that's something we've identified as an issue and we're actively working on improving that documentation.


When you call Configure Acquisition with 10 buffers, that is indeed the number of buffers allocated in the driver that will be acquired into by the camera. When you call GetImage, you're copying from one of those internal driver buffers into that separate MainImage that you allocated. The buffer number coming out of GetImage is basically the frame number from the acquisition. We return it like this so that the user can distinguish between an old image and a new image, as no two images will share a buffer number (well, until you overflow the 24-bit buffer number). Otherwise you could have a problem where you could potentially get the correct number, but the numbers would have wrapped around and overwritten the image you thought you were getting. You should be able to use the buffer number % number of buffers to deduce which internal buffer is being used if that's something you're interested in.


I have a few other comments now that I'm looking at your code:

  • You should configure at least 20 buffers if 10 is your burst count
    • At all times, the driver tries to have half of the total buffers reserved for acquisition. This is to avoid a problem where the camera is streaming data and there's nowhere to put the data and it just gets thrown away. When the buffer is reserved, you won't be able to get it when you call GetImage because it's basically already considered overwritten and not available for the user to use. This percentage being reserved is configurable by the attribute HardwareRequeueBufferListThreshold (defaults to 50.0), but I really would not recommend changing it except in special circumstances. So if you're thinking of acquiring a burst of 10 images at a time, you probably want 10 buffers available to be acquired into by the camera, and at least 10 other buffers that have already been acquired that you can be reading out with GetImage. 
  • Use "Every" for your GetImage mode instead of "Buffer Number"
    • This is just as good as buffer number (and you can get the buffer number out still) but has the added advantage of handling buffer number overflow for you.
    • If you want to be alerted about missing any buffers, you should use it in conjunction with setting the attribute OverwriteMode to Fail (see attachment)
      • This will throw an error if you get into the scenario I described above where you ask for a buffer but it's already been requeued or overwritten. If you use Every mode and OverwriteMode you should get every image and get an error if that's not possible.


Let me know if you have any other questions.


Hope this helps,


Message 2 of 3

Hi Katie,


That all makes sense.



0 Kudos
Message 3 of 3