LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW IMAQ: How to free up a one-shot buffer space

Solved!
Go to solution
Highlighted

Hello,

 

We are using IMAQ version 14.5.0.

 

We are having trouble managing the buffered memory that IMAQ uses to hold acquired images.

 

We are triggering a line-scan camera at very high speeds (~145,000 lines per sec) using an external clock pulse sent through the RTSI cable.

 

In our LabVIEW program, we configure a ~200-element buffer list and set the 'Continuous?' parameter to "One-Shot", so that the buffer spaces will be sequentially filled by the camera and no data is lost. (We CANNOT use "Continuous" or else data is lost)

 

Then we enter a software loop where in each iteration:

 

1. The camera receives ~200 clock pulses to snap ~200 images (lines) to fill up the buffer list.

2. The computer extracts all ~200 buffer images sequentially and saves the data elsewhere.

 

So we want to be able to reiteratively fill the same buffer list. The problem is, after the first iteration of the loop, the "One-Shot" buffer spaces are filled and cannot be released for subsequent iterations. So we end up "extracting" the first ~200 images over and over again, which obviously is not useful.

 

We have tried to release the buffer spaces using "IMAQ Extract Buffer VI", by inputting "-1" to 'Buffer to extract.' But no avail.

 

We have considered using 'IMAQ Dispose' to completely destroy the images and clear the buffer space, then using 'IMAQ Create' to make fresh buffer spaces. But we would have to do this in every iteration of the loop - this is not practical as we want to use the camera's high-speed capabilities.

 

Is there a method to "clear" a 'One-Shot' buffer space for subsequent iterations?

 

Attached is a test version of our code. Sync_Camera_v3 is the main VI.

 

I deeply appreciate any suggestions anyone has for our predicament! Thank you.

0 Kudos
Message 1 of 13
(1,869 Views)

I'm not sure if your situation is the same as ours (certainly our cameras are very different), but what we did was to allocate 3-5 times more buffers than we expected to use at one time.  I'm not certain about "one-shot" vs "continuous" -- I think we were using Continuous (and were able to save without dropping frames) with these extra buffers.  As I understand it, the Camera will uses these buffers as though they were circular, wrapping around and overwriting old images (yeah, this is sounding like Continuous), so as long as you can "stay ahead" of the camera and get the buffers processed before they are overwritten (which is why you need more camera buffers), it should work.  Or at least it did for us ...

 

Bob Schor

 

 

Message 2 of 13
(1,846 Views)

did you just save the images for post processing or you also done some processing before save image ?
also what is you camera fps rate for  grabbing  images 

0 Kudos
Message 3 of 13
(1,808 Views)

did you just save the images for post processing or you also done some processing before save image ?
also what is you camera fps rate for  grabbing  images 

 

Hatef,

 

We enqueue the images (lines from the linescan camera) to a queue for post-processing. We process the saved images in a separate background loop that receives and dequeues the images as they come.

 

We use the GL2048R InGaAs High Speed Linescan Camera, from Sensors Unlimited, which will be used to acquire images at up to 147,000 fps.

0 Kudos
Message 4 of 13
(1,772 Views)

 I think I could fix your problem in some methods but my labview is 2012 could you convert your imageing vi to 2012 ? also 
could you send me one of your image to simulate your deivce for vi test or atleast tell me what is resoulosion of image that you get 
147,000 fps realy is big enough to worry about the buffer and RAM about for your code in your pc 

0 Kudos
Message 5 of 13
(1,735 Views)

Attached is the 2012 versions of the VIs we used to test the camera. Also attached is a spreadsheet containing pixel information from a sample image.

 

We use a linescan camera, so images are one-dimensional. The image size is 2048 x 1 pixels. The issue is consistent regardless of camera speed.

0 Kudos
Message 6 of 13
(1,700 Views)

Here is the sample image.

0 Kudos
Message 7 of 13
(1,698 Views)

Hello Bob,

 

Thanks for your quick reply. "One-Shot" and "Continuous" are settings you can switch between on the "IMAQ Configure List" VI, which we labeled as "Configures buffer list" in our code.

 

Following your suggestion, we set the camera to "Continuous" and allocated several times more buffers than the camera acquires in each iteration of the loop. This implementation was initially successful in that no frames were dropped. However, something weird happens once the buffer list wraps around.

 

In each iteration after the wraparound:

1. The first image of each iteration is successfully acquired and written to the buffer.

2. However, all subsequent buffers receive that same first image.

3. Thus we extract that same first image ~200 times.

 

It's probably not an issue of the buffers not getting released, since the first image changes with each iteration of ~200 images.

 

0 Kudos
Message 8 of 13
(1,688 Views)

hi ippinator your Sync_Camera .vi  still is in 2014 version and I could not to be open it 

0 Kudos
Message 9 of 13
(1,669 Views)

Hatef,

 

Sorry about that. Here are the proper 2012 versions.

0 Kudos
Message 10 of 13
(1,653 Views)