"buffer number in" confusion with IMAQdx get image

[halvorka]

I have just started using the low level "IMAQdx get image.vi" and I'm a bit confused on the use of "buffer number in" for certain cases.

I have a couple of questions regarding this vi, which I couldn't find answers for in the documentation:

1) Is "buffer number in" simply ignored when the vi mode is set to "last" or "next"?

2) How does "IMAQdx get image.vi" behave when the "buffer number in" is either in the future or in the past beyond the total number of internal buffers specified in "IMAQdx configure acquisition.vi"?  For example, if the camera is processing buffer 10, what happens when I ask for buffer number 20?  Will the program simply pause until the camera puts 10 more images on its internal buffer?  In the other case, what happens if instead of asking for buffer 20 I ask for buffer 5, but have configured the number of buffers in "IMAQdx configure acquisition.vi" to 3?

Thanks in advance for any help.

Ken

[VGA_CD-ROM]

Hi Ken,
I've actually been working on an issue related to buffered acquisitions in IMAQdx over the last week. Let me see if I can address your questions.

1) Yes, Buffer Number In is ignored when the VI is set to get the last or next buffer in the acquisition

2) According to the detailed help for the IMAQdx Get Image VI,  the description for the setting for Buffer Number Mode states "Buffer Number, which specifies an exact buffer number to wait for." The VI will sit and wait until you have reached the desired buffer number to continue. When you have only a size of 5 buffers configured, you are not restricted to getting buffers 0-4. Acquired images will continue to count up from 0 until you stop the ring acquisition (all the way up to the limit of an I32 or U32 number I think) and continually roll over the preallocated buffer whenever it fills up. The Developer Zone Tutorial on Ring Acquisitions is a good primer for the subject, even though it deals with NI-IMAQ rather than IMAQdx.

So if you request buffer 5 in a 3-buffer acquisition, it will actually wait until buffer 5 is acquired in hardware (after 0-4):

[0][1][2] => [3][1][2] => [3][4][5] and then it will extract it from the buffer for processing.

Another thing to keep in mind is that in IMAQdx, approximately half of the allocated buffers in memory get locked by the driver for performance reasons so they can be overwritten for the acquisition process. Then the user can only request the last half of buffers to be acquired. In a 10-buffer acquisition, for example, suppose you're at [10][11][12][13][4][5][6][7][8][9]. The next buffer to acquire, 14, would be placed in the slot of 4. If I recall correctly, the driver will actually lock out 4, 5, 6, 7, and 8 to ensure that acquisitions go smoothly and would only let you request (extract) buffers 9-13 at that point. The acquisition attribute Overwrite Mode (settable in Measurement & Automation Explorer for the camera or programmatically using a property node under the Acquisition Attributes category of properties) determines what happens when you try to request a buffer that's no longer available to be extracted anymore (in this case, buffers 0-8). By default it gives you the oldest buffer available, but you can also set it to instead give the newest buffer available or fail and return an error.

[halvorka]

Thanks Vijay,

Your explanation was very helpful.

Ken

[Oliver734]

Hi,

I just read your interesting statement and have a question slightly different.

I have an application which triggers a camera via increments from a motor.

My apprehension is that my image processing, following the IMAQdx Get Image VI, could be to slow and some frames are missed.

Is it possible to allocate enough buffers (the application grabs approx. 2000 frames and then waits for some seconds) to avoid skipped frames?

regards

Oliver N.

[Eric_R]

Hi Olvier

Try using the Sequence.VI located in the example finder under Hardware Input and Output>> IMAQdx >> High-Level. This example generates a buffered allocation of images and then captures at the frame rate set in Measurement and Automation Explorer.

[Oliver734]

Hi Eric,

Thanx for your quick response!

I had a look at the Sequence and I think it could work.

Can I detect eventually missed frames using a similar technique as is used in the Grab and Detect Skipped Buffers.vi or should I use time stamps on each frame to do this?

Thanx again!

 regards

Oliver

[Eric_R]

Hi Oliver I looked into the Grab and Detect Skipped buffers, this VI functions very differently from the sequence function. In grab and detect skipped buffers you acquire and and then process the image then acquire again. Since you are processing during the acquisition there is a chance that you may skip a frame. With a sequence VI you allocate your resources prior to the acquisition, it will capture at the set FPS in Measurement and Automation Explorer. Since acquisition and processing are separate this will provide you with the maximum acquisition speed and should not skip frames unless you specify for it to.

[Oliver734]

Thanks for your answer!

Do you think a "Producer / Consumer Pattern (Data)" Design Pattern would work with your suggested Sequence.vi? (As mentioned before a queue isn't working with normal image acquiring - but in this solution it seems to me, that the reserved buffers should be readable).

Thanks again

Oliver

[Eric_R]

Hi Oliver

If you are looking to timestamp images coming out of the camera from a sequence I recommend using the Low Level Sequence.vi. In the aquistion for loop you could add a get time and date in seconds or tick count function. This would not slow down the process as the most processor intevise task is allocating space for the images. If this doesn't cover your goals for the aquisition I would reference Vijays post above and use a Ring acquisition similar to that of the IMAQ example. 

[Oliver734]

Thanx again - I´ll try that tomorrow!

regards

Oliver