Create two pulses using usb 6211

[Jaclyn]

I have a USB6211 board, and want to use it to trigger a high speed camera and fuel injection system for imaging.  I need to create two pulses, one to trigger the camera to begin taking pictures, and one to trigger the fuel injection system, delayed relative to the first pulse.  i.e. the user will start the program which will start the camera, and after a user defined delay, the fuel injection system will be triggered to begin.  The duration that the pulse is on is also important, in regards to the length of the fuel inejction.  Any advice or sample programs on how to create two trigger pulses using the USB 6211 board would be helpful.  Thanks!
-Jaclyn

[TroyK]

You can assign two digital channels to the one task, then when you run the task they will be synchronized.

If you generate two digital waveforms, one for the first trigger, one for the second, you can wire it into your write function.

This will preload the digital waveforms and output them at the same time, giving you precise timing.

 See attached vi for quick example.

Message Edited by Troy K on 07-09-2007 02:36 PM

[Jaclyn]

Troy,

Thank you for your response.  I am very new to LabVIEW, so this may not be possible using the sample program which you provided.  I need to be able to control when the pulses are sent, i.e. the delay time for the pulse, and for how long the pulse remains on.  I found an example program in LabVIEW, under hardware input and output, generating digital pulses, Gen Dig Pulse.VI, which seems to fit the requirement of pulse duration and inital delay.  However, I need to send two pulses, and am unsure if I can just duplicate the program twice in one VI to get it to run simultaneously, and if this is possible with the USB 6211.  Or, is there a way to alter the program which you provided me in order to provide information about pulse length and delay.

Thank you.

-Jaclyn

[TroyK]

You should be able to modify the counter example you found to have two counter pulses triggered simultaneously.

Similar to what I mentioned in my previous post, set up two counter operations on the one task. (The first 'DAQmx Create Virtual Channel.vi' automatically creates a task, the second one just adds another channel to the task.) Then because thay are the same task, they start at the same time (by the 'DAQmx Start Task.vi').

I don't have a USB6211 but it works OK when I simulate it.

This is just a slightly modified version of the 'Gen Dig Pulse.vi' you mentioned.

Once you get it working how you want, save it and call it as a sub-vi wherever/whenever you need to.

Message Edited by Troy K on 07-10-2007 02:27 AM

[Jaclyn]

Troy-

Thank you for the program suggestion.  It works correctly when the times are all in seconds.  My application requires microsecond timing, i.e. a time delay of ~3000 microseconds.  I know that there is a units option on the CO pulse time Daqmx, however, it seems that the units can only be in seconds.  The smallest amount of seconds you can input seems to be 0.01 seconds, which is not close to my required timing.  We tried to input data time in seconds, and in the program divide the inputed value by 10^6 to reach microsecond inputs, and the program runs, however, when the two pulses have all the same settings, they are delayed on the scope screen, when they should be identical. 

I was wondering if you know of a way to change this program to allow for microsecond timing, or if you have any suggestions for the cause of this delayed behavoir, or if it is not even possible to achieve microsecond timing.

Thank you.

-Jaclyn

[TroyK]

You should be able to input your time in milliseconds and multiply the ms value by 0.001 to get the value in seconds to input to the CO function. The numeric controls are currently set to only display 2 significant digits, this doesn't mean it wont accept smaller or greater precision values. You can change it to 3 significant digits by right clicking on the control and selecting 'Format and Precision...', then increase the amount of significant digits...(see image).

One of the other Counter Output functions allows you to define the pulse times in timebase ticks, the counter has an 80MHz clock, so you should be able to define it down to 12.5 nanoseconds.

The delay I'm not sure about. How much of a delay? Perhaps if you could post your vi I'll have a look at it.

Message Edited by Troy K on 07-11-2007 01:21 PM

[Jaclyn]

Thank  you for your previous post, that helped me with my units issue.  However, I have ran into another problem.

I will post the two different VI's that I have been using, to determine which one works better before implementing it into my experimental setup.  For now, I have been connecting the counter outputs to an oscilloscope so that I can see the pulses which are created and their timing, to ensure that the program functions as I expect. 

I recently found that even if the inital delay to generate the pulses for both counters is 0 seconds, the output pulse of counter 0 leads counter 1 by approximately 1.2 ms.  This is the case with various delay settings.  i.e. if I set counter 0 to 0 seconds initial delay, and ctr 1 to 3.3 ms initial delay, ctr 0 leads ctr 1 by 4.3 ms - an extra 1 ms.  This is the case with multiple initial delay settings I have used.  For these cases, the first co daqmx in the block diagram corresponds to the camera counter, which I set as ctr 0, and the second co daqmx in the block diagram corresponds to the fuel injector, which I set as ctr 1. If I alter the ctr settings, i.e. set the camera counter to ctr 1 and fuel injector to ctr 0, then ctr 1 leads ctr 0 by 1.2 ms. It seems that the first co daqmx which is used in the block diagram always leads the second counter by approximately 1 ms, no matter what the initial delay time.  This is based on the program Triggering Program 3.vi

When I use the program triggering program.vi, a similar trend occurs, however, the lead time is closer to 4 ms. 

I am unsure if there is some sort of delay in the oscilloscope, or problem with the program.  How I understand the labview program is that it sends out the two pulses simultaneously because it writes to the ctr channels, however, this does not appear to be the case due to the consistent 1 ms delay.  It seems that overall the program Triggering Program 3.vi works best, however, I am unsure how to overcome this 1 ms delay.  Any suggestions on causes for this delay would be appreciated, I am unsure if it is caused by an internal delay in the USB board in that both counters can't run simultaneoulsy, or if there is a way to adjust the program so that it ensures there is no delay.

Thank you.
-Jaclyn

[Gryphon]

Hi Jaclyn, Troy,

I modified your code, Jaclyn to use the approach which I found successful where counter 0 is explicitly used as the trigger for counter 1. 

I too found there is always find a fixed delay even when you define an initial delay of 0 for counter 1.  The magnitude of this will depend on the timebase that is used. When you use time for the counter output instead of ticks, labview works out what time base to use.  If you want to always be in control, then use the ticks version where you explicitly define the ticks.  Using the 80Mhz timebase, the duriation of the delay with initial delay =0 was 50 nanoseconds (4 ticks) +/- 12.5 nanoseconds which is 1 tick. 

 Once you know what the dead time or fixed delay is , you could code this into your vi so that when you specify the gap between the pulses, you do something like the following

initial delay cntr1 = (pulse gap - dead time)/seconds per tick.

  Comments on my approach are much appreciated.  Let us know how you go.

 Thanks Troy for your examples, was an approach I had not considered and I will test it at some point.

Cheers

Peter

[TroyK]

It sounds like the counters/hardware aren't working how we would expect them to. Your approach Gryphon, seems like the only way to do it if you want to get perfectly timed outputs for the two counters.

I would have generated on the fly two custom digital waveforms based on the timing required and pumped it out of 2 digital outputs (as I suggested in my first reply). It adds a bit of complexity in generating the waveforms, but then at least you don't have to 'fudge' the timing to account for the hardware anomalies.

[Jaclyn]

Thank you for your advice... I would like to look into your suggestion, however, I have LabVIEW version 8.0 and am unable to open the VI you attached to the post. I looked for suggestions on how to convert the VI to an earlier version... however, I couldn't find anything.  I didn't know if there was a way that you could save the VI in LabVIEW 8.0 or if you could let me know how I can open this VI using LabVIEW 8.0. 

Thanks.

-Jaclyn