Image acquisition problem: triggering, acquiring, cpu usage messed up!

[lshi]

I have an application that acquires an image whenever a LED is turned on. The camera (AVT procilica GigE GC660m) has a trigger line wired to the LED board, so that a levelHigh signal (as long as LED is on -- controled by the pulse time in ms) will trigger the camera to expose. The app worked fine before, but all of a sudden got so messed up that sometimes I got cpu usage shooting up to 100%!

I stripped the code to the simplest form: the app first configure the camera and register "Frame Done" event. Inside the for-loop (I have 40 LEDs), I'll turn on one LED at a time (send through LabjackU3 DAQ), then capture the image.

problem: for pulse time > 5ms, the code works fine; while for exposure time ~ 2ms, I will get timeout error, sometimes after 3k frames done if lucky, other times only 80s. Most weird thing is that after the timeout, even if I aboard the app and start over (with expores > 5ms), the timing completely messed up and I get frequent time out (every 5 - 10 frames)! Then I'll have to disable the "Acquire Image" block to let only the LEDs run for a while. The timing with LED-run-only is off at first, but eventually get back to normal. Only then the app works again.

1) since the code uses sequenced acquisition, loop over "triggering -> frame done -> triggering", why there's time out for small pulse time? Without image acquisition, the LED turned on and off with ~ 2ms just fine.

2) what causes the problem afterwards? the posted the picture was taken after the timing under LED-run-only got right, and there's one processor got really high cpu usage even there's no image acquisition at that time.

I'm using Labview 2012 32bit and IMAQdx (vision acquisition software 2013);

[JKMM]

That camera can only go as fast as 8ms periods (119 fps) at full resolution, maybe a little faster when externally triggered.

Is the goal to capture images as fast as possible in LabVIEW?  If so, I would not check for a frame done event and instead just use the high level and Grab VI with the Grab in a loop with no waits.

Also, what is the timeout of the camera set to in MAX?  You may want to increase it and/or add in a recovery process to reconfigure the camera if it times out, unless you can't afford for it to time out, there is no point to do that.

[lshi]

@JKMM, Yes, the camera can only run 119 fps at full resolution. Since I'm using less than half of the vertical res, it should hit 200 fps. However the trigger is never going to hit that fast. The computer first sends signal to my DAQ to turn levelHight for 5ms, and right after sending command it waits for the FrameDone event; and only after "get image" done, the computer will send another trigger signal. In this way I can control each exposure time while try to run as fast as labview/camera allowed. My MAX setting has 5s for timeout, yet the framedone event only wait for 1s.

[Emily-C]

Hi Ishi,

Could you please clarify the overall goal of your application? As JKMM said, if you want to acquire images as fast as possible from LabVIEW it would be better to move to the Grab VIs to acquire images continuously. The extra code you're adding in could be affecting the 119fps limit. Is there a reason you're using your current implementation instead?

Thanks!

[lshi]

Emily,

The application is to acquire and compare the intesensities of each frame from these LEDs, as fast as possible. I need to make sure which frame corresponds to which LED light. Every time there's only one LED on, and it is synced to the cam trigger (levelHigh). The exposure time of the camera should be the same as LED-on time which, together with sequence of LED are controled by Labview.

I'm afraid using "grab" (next/last) runing in a loop parallel to the LED contrl loop, are not able to tell me the exact sequence of LED the acquired frame is corresponding to. But of course, I'm open to better solution.

thanks,

[BruceAmmons]

The LED control loop should also output the camera trigger signal.  The camera acquisition can then run in a separate loop as fast as possible.

Set up the camera to be hardware triggered. Set up the camera acquisition to be a buffered continuous loop.  Read every frame and process it as necessary.

After the camera loop is ready, start the LED control loop.  Send out a trigger for each image at the time you want it.  Your image loop will read one image for each trigger, as long as you obey the triggering rules for the camera.  That means the trigger needs to be long enough, and the gap between triggers needs to be long enough.

If you need more correlation, you could create a queue that would pass data between the loops.  Each LED loop could send the LED configuration over to the camera loop.  The camera loop would read the queue at the same time it acquires the image and pairs the data with the image.

With this scheme you could easily run at the frame rate of the camera, but you would probably need an RT system to do the signal timing that accurately.

Bruce

[lshi]

That sounds good, I'll try it once I sort things out. Thanks.