Synchronize external event with IEEE1394 camera exposure time?

[kbaker]

I am using a LED illumination source for a IEEE1394 camera.  I am turning on/off the LED with a digital I/O.  I am using the NI-IMAQ for IEEE 1394 grab acquire in Labview 7.1  to capture an image.  I have a Sony DFW-X700  camera, and it takes ~ 70 ms to transfer the image data.  It is my understanding that the grab acquire is running for this time plus whatever the exposure time is.  I would like to turn on the LED right before the exposure time, and turn it off right after the exposure time is over.  I don't know how to turn the LED off for the ~70 ms image transfer time?  Is their a way to turn the LED off while the grab acquire is still transferring the image data?  I want the LED to be on for the least amount of time without decreasing the exposure time anymore, and this is the only way I can think to do it.  Thank you in advance for any assistance.

Kevin Baker

[ryanm]

Hi Kevin,

One way of having the led on only while the camera is acquiring data is using the Sony DFW-X700 camera's trigger input.  It looks like the camera triggers on rising edge.  If this is the case, you can create a signal that is asserted for the length of the exposure time.  When the signal is asserted, it would trigger the camera and turn on the LED for the exposure time.  When the signal is not asserted the LED is off.

Regards,

Ryan M.

Applications Engineer

National Instruments

[kbaker]

Thanks Ryan.  It looks like that will work.   One more question.  Sometimes I would like to use a grab sequence after I use the trigger, but I don't want to unconfigure everything for the trigger because I want to go back to it later.  Is there a way to do this without closing the session everytime I switch back and forth?  Thanks again.

Kevin Baker

[ryanm]

Hi Kevin,

If your program is acquiring as a triggered grab, you must stop this acquisition before you can acquire in the "normal" mode.  This requires closing the current session and starting a new one.  Similarly, if you are acquiring in "normal" mode and wish to perform a triggered grab, the current session must be stopped and a new started.  You will be able to do this all from the same program, but as you mentioned, the session must be closed every time you switch back and forth.

Regards,

Ryan M.

Applications Engineer

National Instruments

[kbaker]

Thanks Ryan.  I would like to just use the trigger as a continuous grab with 10 different image buffers.  It looks like to me that the DFW-700 only triggers on the falling edge of the trigger pulse.  Therefore I used another I/O make the pulse. 

There is a sequence of 10 LEDs that is continuously repeated until it is stopped with a while loop.  For each while loop iteration I use a for loop to take 10 images with a different LED turned on each time.  For each for loop iteration I turn the trigger pulse I/O high, turn LED on, turn pulse low, wait the exposure time of 20ms, turn off the LED, and then use the get image to acquire that image.  The problem is it only works for a little while, before the program stops responding?  After a few while loop iterations it goes really slow?  I am starting the acquisition right before the for loop, and ending it right after the for loop. 

I also would like to use IMAQ1394 Occurrence Config frame done and wait for occurrence VI instead of using the wait VI for 20ms.  It still seems to have the same problem, but it occurs faster?  Is using the IMAQ1394 Occurrence Config a good idea in this application?  Thanks for any help.

Kevin Baker

[ryanm]

Hi Kevin,

The IMAQ 1394 driver should not cause your program to run slower with each iteration of the while loop.  However, certain programming practices lead to memory leaks which can cause the behavior you are describing.  For example, the IMAQ create.vi will allocate memory each time it is called.  If this VI is in your main while loop, memory will be allocated in each iteration.  If IMAQ Dispose is called in the main while loop then the memory will be deallocated and there will not be a memory leak; however, if IMAQ Dispose is outside the while loop then the amount of memory allocated keeps growing with each loop iteration.  Memory leaks are very easy to test.  If you open the task manager and select the performance tab, you will be able to monitor your computers memory.  If this keeps growing over time, then there is probably a memory leak.

As far as using the occurrences, the frame done could be useful in your application.

Ryan M.

Applications Engineer

National Instruments

[kbaker]

Thanks Ryan.  I fixed the problem, but it still doesn't work using an occurance instead of a wait for the exposure time?  I tried it with both true and false for the ignore previous for the wait for occurance VI, and it still dosesn't work?  I am attaching a sample VI that might illustrate the problem.   I don't know why simply exhanging the two will not work.  Thank you again.

Kevin Baker

[ryanm]

Hi Kevin,

One potential problem is that the frame done occurrence is based on when the data is received by the computer.  This can be quite different from the exposure time which would be based on the camera.  The LED Control.VI was missing from the attached vi, so I am unsure exactly what was occurring.  I have attached an example which uses an occurrence to wait for a frame.  If the frame is not sent within the timeout period a message is sent to the user.  If the fame is sent within the timeout period, the fame is displayed.  I hope this helps.

Ryan M.

Applications Engineer

National Instruments