Overhead between two grabs

[alfarossi]

Hello LabVIEW enthusiasts, 

I have a project in hand where I have to trigger 4 LEDs sequentially and have to take 4 different images. the whole thing should be done within 250 milliseconds. The LED flash time and exposure time for the image is 20 ms. So even some small overhead between the acquisitions are permissible. I am using a flat sequence structure where I configure the Grab on the first sequence. Then I turn on the first LED and use Grab (with softwire trigger) on the next sequence. Then on the next sequence I turn off the LED. On the next sequence I turn on the second LED and use  Grab for the second image. After capturing four images, I can see that there is a gap of 130 ms between each capture. (I turned on the phone clock and imaged it). How can I solve this problem? I am using DFK37BUX camera. 

Thanks in advance. 

[Gregory]

You can try with triggering turned off, so the camera is continuously acquiring data and through your code you enforce that you turn the LED on before grabbing the frame. If that isn't suitable, you may need to use a hardware trigger instead.

[stevem181]

Check out this example:

 IMAQdx Continuous Grab & User Triggered Snap

In the example, the Get Image button will "snap" an image.

You can replace the GI button with your own logic (LED1 on, LED 2 on, Only one LED On, etc).

When you get an image: Use a queue or channel wire to send it to another loop for processing.

Note: With default settings, the Grab vi will wait for the next image (which is what you want).

 

[alfarossi]

Hello Gregory! I did what you told me earlier and still its the same. Do you think using a flat sequence might cause some problem? Hardwire trigger is something new for me and I am not sure how to acquire the image from the camera after I give the trigger pulse to the camera.

[Gregory]

No, while I'm not a fan of the flat sequence structure, the overhead should be very tiny. Do you know what kind of framerate you can achieve if the camera is freely running?
For a hardware trigger, you would have to get some hardware with a digital output (cheap USB DAQ) and connect it to the trigger input of the camera. Then when you try to grab from the camera, you will send the trigger and it should wait until the frame is ready before returning.

[alfarossi]

Hi Gregory,

I can get upto 60 fps when the camera is running. I removed the LED part and just tried to get four sequential images, still the overhead is too long for me. I used some benchmarking and found out the grab function actually causes the delay.

[alfarossi]

Another interesting think which I have noticed is, if I use 20 ms exposure for the sequential images, the time gap between the two image is 100 ms. But if I increase it upto 50, still the gap is same. 

[Gregory]

Interesting, how did you measure 60 fps? This corresponds to 16.7 ms between frames.

[alfarossi]

I am sorry I misunderstood your question. The camera can go upto 60 FPS in IC-capture softwire. Now i have benchmarked the while loop inside the free-running mode and it seems like each iteration takes 100ms time if the exposure time is any value below 100. But if I increase the exposure time above 100, then the loop time is almost equal to the exposure time. (similar to the case for sequential imaging). Hope you can see some pattern here. By the way, I really appreciate you replying to me!  

[alfarossi · Accepted solution]

Hi Gregory,

I just found out the issue. The framerate was capped at 10fps in NI-Max. I know its a stupid problem, but I am glad that I learned a lot of things about LabVIEW and camera because of this stupid problem. Thanks for those super-useful hints! Cheers!