Timeout errors with external triggering

[harmond]

I am trying to use the IMAG IEEE 1394 VI's to aquire images with an external trigger. My Camera is a Redlake ES4020. My external trigger source is a pulse generator that I can send commands to with labview. I'm trying to capture a single shot acquisition using a variable pulse width (1 to 250ms) to control the integration time. I've been trying to use the low level VI's to accomplish this and have been unsuccessful. I keep getting a timeout error. Can anyone give me some guidance on how to effectivly control the acquision and the pulse generator with the same program so that I no longer get the timeout error? Thanks

-Dan

[DJ_L.]

Hey Dan,

Have you tried to use the Triggered Grab.VI that comes with the 1394 driver? Are you able to trigger the camera at all with an external trigger that is not controlled by your program but manually sent to the camera? Most likely what is happening is that the camera is not getting the trigger, and therefore not sending an image to the driver, which is eventually timing out your program. I would suggest trying to implement your external trigger code into the Triggered Grab.VI example. How are you commanding your external trigger (pulse generator)? Are you able to just get a program that sends the correct commands to the pulse generator, and does that program work without any image acquisition software in it? Are you able to monitor the signals coming from your pulse generator? What Trigger Mode are you using in your program? I have attached a simple example to this post that uses the 1394 driver VI's and uses Triggering with DAQ. This is probably different than what you are doing, because it doesn't sound like you are using DAQ but maybe you are. It might just give you a good idea of where to start though.

The best guidance that I can give is to separate your code before trying to get it all working together. Once you are able to get the individual parts working, combining them becomes easier. Also, you might want to post your code on this thread, so that we can take a look at what you have already, and maybe give you some suggestions, but try to get the Triggered Grab.VI example working before posting your code. I hope this helps. Let me know if you have any questions or concerns. Thanks, and have a great day.

Regards,
DJ L.

[harmond]

DJ L.,

I am using a pulse generator to create my external trigger to aqcuire images with varing integration times. There are .VIs available to control the pulse generator which I have downloaded and run independently of any image aqcuisition software. Using these VIs I am able to communicate (GPIB) with the pulse generator to send pulses and vary the pulse characteristics. I have verified the output of the pulse generator with an oscilliscope.

Next, I ran the 1394 triggered_ grab.vi example program and manually sent pulses with the pulse generator. I was able to send different pulse widths to control the integration time of the camera (Trigger mode 1). Up to this point everything works perfectly.

However, when I combine the two programs, I had to put some delays in the program to ensure the pulse is sent during the time the camera is waiting for a pulse. I am able to play with the delay times to get the program working consistantly.

Now, when I have to make this image aqcuisition procedure part of a bigger program, the timing of the software is different depending on other things that are happening in the software (this is my theory anyway) and I will frequently get timeout errors.

I suppose my question is this: Is there a more robust way to control the timing of the aquisition portion? Where is the best place to send the command to the pulse generator to tell it to actually send the pulse?

The reason we would like to use the pulse generator as the trigger source is because once the camera recieves the trigger, there is a 20uS delay before it actually starts integrating. At that moment, the pulse generator sends a pulse to other equipment. Both triggers end at the same time.

I have attached the code for the aqcuisition portion of my program.

Frame 0 initializes the camera and enables the gamma correction.

Frame 1 sets up the pulse generator with the characteristics of the pulse the user wants,  which is the integration time. The  2e-5 constants represent the 20uS delay described above. The constant of 6 represents the time (in Seconds) the pulse generator will wait after recieving the command to pulse, to physically send the pulse.

Frame 2 is a 3 second delay to give the pulse generator time to recieve and process the command

Frame 3 sets up the trigger

Frame 4 sends the command to the pulse generator

Frame 5 Takes the snap. (It is between frame 4 and 5 that the 6 seconds mentioned above come into play. It helps make sure that the snap vi is ready for the trigger before it is actually sent by the pulse generator)

Thank you for your help. I am stumped.

-Dan

dg535 delay.vi and dg535 trigger.vi are the vis for the pulse generator.

Message Edited by harmond on 03-01-2006 09:43 AM

[DJ_L.]

Hey Dan,

You said that "when I have to make this image aqcuisition procedure part of a bigger program, the timing of the software is different depending on other things that are happening in the software (this is my theory anyway) and I will frequently get timeout errors." So I ask, what timeout error are you getting? I am assuming that you are getting image acquisition time out. If you are, then maybe you can use a delay time for the other parts of your program that you might know how long it is going to take, and wire that into the Timeout input of the IMAQ1394 Configure Trigger VI. Another thing you might want to change is where you place the configure trigger VI so that it does not happen until it is ready to sit there and wait for the trigger. If other things are going on in your code that you don't know how long they are going to take, then you should not set up that VI until later, when you know how long it should take. Last, I see you are using a 20 second delay for your timeout, but have you tried larger values?

You asked: "I suppose my question is this: Is there a more robust way to control the timing of the aquisition portion?" and the answer would be after the part of your program where you don't know how long it is going to take. You also asked: "Where is the best place to send the command to the pulse generator to tell it to actually send the pulse?" and I would suggest that you place the VI that sends the command to the pulse generator when you know that the camera will receive that pulse in a given amount of time. Basically our driver is sitting there and waiting for an image to come in during a certain amount of time, and if it doesn't then it will time out. Another suggestion would be to have something in your code that will not let the trigger set up to happen until there is time to complete the triggering.

I hope this helps. Keep moving things around until your code is ready to be timed properly so that nothing starts before another section of your code happens. I would also suggest that you use the debugging techniqes provided by LabVIEW to help you figure out where and when you need to perform certain functions. Let me know if you have any questions or concerns. Thanks, and have a great day.

Regards,
DJ L.