Gen Digital Pulse Train Finite Retriggerable - Initial Delay is only for first trigger

[SteveP]

The DAQmx example Gen Digital Pulse Train Finite Retriggerable has an Initial Delay parameter. It appears (6602 and an E series card) that this Initial Delay only delays the pulse generation for the first trigger. Subsequent triggers show no delay. Is this the designed behavior ? Any way to get the Initial Delay to occur for all triggers ?

Steve

[AlanArmstead]

So, yes, you are seeing the appropriate behavior. However, it is possible to get a re-triggerable finite pulse train with an initial delay. What you have to do is set up a re-triggerable pulse, and have that pulse act as a pause trigger for a continuous pulse train. Let me explain further with an example.
1) Set up counter 0 as a re-triggerable single pulse (Gen Dig Pulse-Retriggerable.vi). Set the low time = initial delay = X, and high time = Y. The re-triggerable pulse will be low for X, then high for Y after every trigger (it applies the initial delay to the first pulse, and the low time to every pulse after the first). The trigger source is your actual trigger.
2) Set up counter 1 as a pause-triggered continuous pulse train (Gen Dig Pulse Train-Continuous-Pause Trigger.vi). This pulse train will be the frequency of the finite pulse train you want. The pause trigger source will be the output of counter 0.

I have attached the VIs I used to accomplish this. There are three VIs, the two mentioned in 1) and 2) and another VI I used just to monitor the signals. These could be combined to a single VI if you would like. Hope this helps!

-Alan A.

[SteveP]

Thanks Alan,

So the Counter 0 is acting as a Gate to control when Counter 1 is allowed to generate its pulse train ? Counter 0 duration would be set to match the desired total time over which pulses are wanted to be generated. My application deals with the number of pulses to generate as a parameter, hence re-triggerable finite pulse generator is used. So perhaps a similar approach of generating a single pulse (counter 0) with zero initial delay whose initial portion is low for the desired delay time, then use its high transition as trigger for the re-triggerable finite pulse generator I'm currently using. i.e. Just add another retriggerable single pulse generator which serves as the initial delay.

Steve

[AlanArmstead]

Steve,
That approach would work fine, but there is one small caveat. It would require three counters. Any finite pulse train generation requires two counters. So if you were using one counter to trigger a finite pulse train, you would need three counters total. This would of course be ok, and is a great solution using your 6602, because it has eight counters. But your E Series board only has two. The reason I went with my earlier solution was that it only uses two counters, so you could use either the E Series or a counter/timer board. Good questions!
-Alan A.

[AlanArmstead]

Steve,
If you are interested: I touched up the earlier example, and combined it all to one VI. It is much nicer to look at now (and runs great!).
-Alan A.

[SteveP]

Thanks for this additional effort Alan. I actually need a 6602 (or 6601) since I am also doing event or period measurement, thus requiring at least 3 counters. Be nice if the original re-triggerable finite pulse generator could have an additional parameter of "use Initial Delay for All Triggers" if the hardware would allow this as is.

Steve

[AlanArmstead]

FYI - I have brought this up, and it is being considered for future versions of NI-DAQ. Thanks for your feedback!
-Alan A.

[pavanbabut]

Hi,
Does anyone have this implemented in VC++?? I am having the same situation, I have a input trigger signal which I use to produce a finite pulse train at each rising edge of the trigger signal. Now I want to dealy the pulse traing generation for sometime before starting the pulse train. I am using 6602 board, so I think its possible. I would really appreciate any help.
thanks,
-Pavan

[CKap]

Hello Pavan,

Like you said, it is possible to do what you have stated. The way to do that would be to define a property for the DAQmx trigger. The specific property is "StartTrig_Delay". This property basically specifies an amount of time to wait after the Start Trigger is received before acquiring or generating the first sample. This value is in the units you specify with another trigger property called as "StartTrig_DelayUnit". The syntax for using these properties is as below:

int32 __CFUNC DAQmxSetStartTrigDelay(TaskHandle taskHandle, float64 data);

int32 __CFUNC DAQmxSetStartTrigDelayUnits(TaskHandle taskHandle, int32 data);

For more information regarding these function please refer to the NI-DAQmx C reference help.

Regards,

Chetan K

Application Engineer

[pavanbabut]

Hi Chetan,
Seems like these commands are incorporated in the newer version of DAQmx. In my C reference help there are no statements like that. So, I doubt my header/lib file will have those. May I know what version of DAQmx are you referring to? if possible can you link me to the reference help file and also for the new NIDAQmx.h file and also the libaray files of it?
thanks,
-Pavan