IMAQdx camera triggering problem

[mgulde]

Hello all,

I have some issues with the IMAQdx drivers for AVT cameras (Pike and Guppy Pro) when it comes to triggering those.

The task:

I am currently trying to record differences in diffraction images when pumped by an intensive laser source to the unpumped diffraction images. Therefore, I am using two separate image matrices and a trigger signal (fixed, between 1 and 10Hz) to decide a) when to take an image with the camera and b) on top of which matrix this information should be stored. E.g. trigger is true (laser is on), so add image to matrix A, otherwise (laser is off) add to matrix B.

So far, I am using a continuous acquisition mode with a buffernumber of one (IMAQdx Configure Acquisition.vi) and the Buffer Number Mode (IMAQdx Get Image.vi) being "Next".

The problem:

Apparently, the program sometimes stores the same image multiple times. When using the "Next" option, the trigger state changes with the correct frequency (= the laser on/off frequency), but the number of images, which are stored in the two matrices is double as high as the number given by the "ActualBufferNumber". It seems like the program is using the same image twice. Also, the actual framerate is double as high indicated by the increase in ActualBufferNumber. How can that be?

When changing the Buffer Number Mode to "Buffer Number", "ActualBufferNumber" in increasing at double the speed as before, but now the trigger is totally off, meaning more or less random distribution of the images on top of the two matrices (despite of the given alternating tigger operation).

"Last" seems to combine the two problems: "ActualBufferNumber" is only about half of the images saved with the matrices and on top, not the same number of images are saved in A and B.

I must confess that I am not fully understanding the underlying processes of the image acquisition process. Well, yes, I read the manual about the different modes, but I am all but sure how the buffernumber and the operation mode are influencing the acquisition process and why they are having such a big effect on the triggering.

For any suggestions, I would be more than thankful.

Best,

Max

Operation System: Win XP SP 3

Labview Version: 2009, 9.0 (32 bit)

[BruceAmmons]

For your application, you need every single image.  Set the buffer size to 10 or 20 (or more) instead.  When you set it to one, it is continually overwritten and triggering is useless.

With a large buffer, you can use ActualBufferNumber quite effectively.  You will get a copy of every single image exactly one time.  The large buffer gives you a second or more to process the image before it is overwritten.  This is helpful if there is an occasional lag between acquisition and processing.

Bruce

[mgulde]

Thanks for the advice, but I tried to do exactly the same and now the camera is only using every nth frame with n being the buffer size. This seems to happen independently of how the setting is for the buffer number (next, last or buffernumber).

Could it be a problem, that I am using the "FrameDone" Event to trigger the image recording?

Best,

Max

[BruceAmmons]

Possibly.  I have never used the FrameDone event, so I am not sure.

The simplest method is to request each sequential frame using buffernumber.  First request frame 0, then 1, 2, 3, etc.  The acquire frame VI will pause until that frame has been acquired, if it has not been acquired yet.

Bruce

[BlueCheese]

The FrameDone event is fraught with perils.. specifically, LabVIEW queues these events up into an infinitely-sized queue and by design will only process them as fast as your event frame executes. Thus if your processing is slower than the rate frames are being acquired, this queue gets deeper and deeper as you are further behind. There is no ability to "skip" queued up events if you get behind. Once you are behind enough, the frame numbers that are being returned are not likely to still be available and thus if you try to retrieve them you will either error or get a newer buffer (depending on configured behavior). This can cause very odd-looking behavior if you don't analyze the execution closely.

FrameDone should only be used for minimal things like displaying live images. If you do any processing on the image data, use a loop with Get Image or Grab Image like Bruce suggests.

Eric

[mgulde]

Ah, that's interesting. I will try to redesign the program accordingly and check, if the problems are still occurring.

Thanks in advance,

Max

[mgulde]

How do I access the ActualBufferNumber in case I am not registering the FrameDone Event?

Cheers,

Max

[BruceAmmons]

Not exactly sure what you are asking for.  You can use a property node to get LastValidFrame.  You can use a shift register and increment to keep track of what frame you are reading/processing.  Subtract the two to calculate your backlog.

Bruce