Fastest way to Reset IMAQ Buffered Acquire Window Height

[ColeV]

I am doing an IMAQ Buffered Acquire, where I need the ability to reset my IMAQ Acquisition Window Height as fast as possible. From my experience, the following steps are required to start, acquire and stop a buffered acquisition (see attached .vi and .jpg):

1. Open the interface and configure the Number of Buffers
2. Set the Acquisition Width, Acquisition Height and Timeout
3. Allocate Image locations for each buffer to be set to size Acquisition Width by Acquisition Height
4. Acquire Data until complete
5. Stop the IMAQ interfaces
6. Deallocate the image locations

I need to change the Acquisition Height as fast as possible (step 2) and get back to acquiring as fast as possible (step 4). Is there any way to do this without a) deallocating all of the memory and allocating a new set again and b) reinitializing the IMAQ interface?

If I was willing to only have two values for Acquisition Height and was willing to preallocate one set of Number of Buffers with Acquisition Width by Acquisition Height #1 and another set of Number of Buffers with Acquisition Width by Acquisition Height #2, is there anyway to hold onto that memory and switch between the two sets?

At the moment, the only way I have been able to change the Acquisition Width is by going through all of steps 1-6 every time I need to change that value.

[rrobe]

If you are using a line scan camera, there is a notion of variable height acquisition where you can receive images of different heights without having to stop the acquisition and reconfigure each time.  http://www.ni.com/tutorial/2939/en/

Have you tried changing the width and height after stopping the acquisition and then trying to start it again?  IMAQ Stop -> Change Width/Height -> IMAQ Start.  That would be the fastest way if it's possible.

Another option could be to always use the largest image size that you need, and then only use the subset of the image that you need at the time. 

I don't think you can allocate two sets of buffers ahead of time and then swap between them as needed. 

[Jacobson-ni]

I tried to stop, configure, and then start the acquisition to see if something that would work. What I found is that if you start acquisition with height N and move to a new height that is greater than N you will receive error -1074397170: buffer size used is too small for acquisition frame. If you move to a height that is less than N though you will acquire an image without an error, however the bottom most pixels will display what was on each image in the buffer before the height was changed (basically you are only overwriting each image with the information returned which leaves the bottom of the image untouched).

I also found that you are able to preallocate two image buffers and switch between them. One thing I did find out when trying to do this though was if I stopped, configured the window size to be the same value it was previously, put in the same image buffer array that I was currently using, and then start again, it would return error -1074396065: cannot resize an image in an acquisition buffer. My thoughts on this is that I think it could be used for two buffer sets but would be pretty error prone if it were to be extended to M different heights.

One solution that might work out well would be to initialize the images in the buffer to be the maximum acquisition height. Then when you change the acquisition height by issuing a stop, property write, start, you can feed the image returned through the IMAQ Extract 2 function and use the Optional Rectangle input to crop out the unwanted bottom portion of the image. I haven't benchmarked this to see how expensive the operation is which may be an issue though.

[ColeV]

rrobe and Jacobson, thanks for the responses! We are using a line scan camera for this application along with a PCIe-1433 framegrabber. One thing I didn't note earlier is that we are triggering each and every line off the camera with a custom trigger period which is synchronized with a physical process that doesn't have a fixed period.

From what I am seeing in the LL VHA Ring.vi, the trigger in that example seems to only be applicable for line scan cameras that are free running rather than line scan cameras that are externally triggered. Perhaps I am misunderstanding the situation though.

At least I know I can create two buffers and reset the acquisition height if needed. Before I acquire a buffer, I always know how many lines I am going to acquire (10, 10, 100, 897, etc...) so if there was a way to feed this in and not have to wait for IMAQ Extract Buffer.vi to timeout that would be ideal.

[BlueCheese]

If your process can generate an extra physical signal that is high for however many lines you want to record, then you can use the variable-height acquisition facilities existing in IMAQ for this. You still get images of the "full" height, but IMAQ Extract returns data of how many lines were actually filled in before that physical line goes low and will return the buffer as soon as that occurs.

[ColeV]

BlueCheese, thanks for the suggestion. I have a number of questions regarding it:

• How would this signal be piped into the framegrabber? The PCIe-1433 externally has the 2 cameralink channels and the one external digital I/O connector, which we are currently using to trigger the acquisition of each line from the line scan camera.
  
  Would your suggestion require a second digital signal to act as a gate and that signal would have to be piped in via the Cameralink I/O Extension Board?
  
  
• On the software side is this done using the IMAQ Configure Trigger3.vi?
  
  
• Do you know if IMAQ Configure Trigger3.vi can be called multiple times? I noticed there was a "line number" input which indicates that it's for a specific line on the I/O extension board but it's not clear that it can be called multiple times. It feels like I would need to set one line to indicate that I am triggering each line off of the camera and another line to indicate that it is acting like a gate.

[BlueCheese]

I think you may have a few options for getting the signal, assuming you are already using the external connector for line trigger:

-The mentioned I/O extension board

-Connecting to the RTSI connector on the board via some sort of breakout cable

-Breaking out one of the CC lines within the CameraLink cable (these are separate LVDS lines from the actual data), but I'm not sure these can be used as a trigger for this purpose, so maybe this option doesn't work

The idea behind VHA acquisitions is that you have a per-buffer trigger signal that starts capture of an image and continues capturing lines until the trigger is de-asserted (up to the configured maximum number of lines). I think you would just use Configure Trigger3 twice, once to setup your line trigger and a second time to setup the per-buffer trigger, and you'd have different external signals for each. Definitely look at the VHA example for this--it just would need to be extended to add the line trigger.

Eric