NI 6602 time between executions of retriggerable task

[VadB]

I am trying to use a TTL-level signal from one device to trigger a pulse train from the NI 6602. I have no problem getting the 1st pulse train but subsequent pulse trains are delayed and no longer synchronize with the new incoming TTL signals. I've been testing this with pulse trains consisting of just one pulse with no luck. Is there some finite period of time that a Retriggerable Task needs to "reload"?

It might be worthwhile to note that the originator of the TTL trigger produces the trigger as a 5V increase from 0 and can source only up to 0.7mA.

Vadim

[John_P1 · Accepted solution]

Hi Vadim,

The trigger should be re-armed within a timebase tick or two (12.5 - 25 ns if using the 80 MHz timebase) of when the previous pulse has completed, so this probably isn't the issue.

What I expect you are running into is a peculiarity of how DAQmx treats the initial delay property for retriggerable counter tasks.  You can find a description here, but essentially the behavior is the following for generating a single retriggerable pulse:

First trigger:  Will remain in idle state for the Initial Delay, then generate a single pulse of the desired High Time.

All subsequent triggers:  Will remain in idle state for the Low Time, then generate a single pulse of the desired High Time.

This behavior is true for most DAQ hardware.  Newer hardware (X Series, cDAQ chassis other than the 9172) actually use the more expected behavior of using the initial delay instead of low time on every retrigger (with the option of going back to the old behavior by setting a property).  On your 6602 though, my recommendation when generating a retriggerable single pulse is to always set your low time equal to the initial delay (the minimum value would be 25 ns).

Best Regards,

[VadB]

Hi John, thank you for the response. Regarding your first point, how do you choose the timebase for both the pulse generation and the trigger acquisition? I'm not sure I understand - even if the counter I am using is configured to work in finite mode with 0 initial delay, I have to configure it with an artificial delay (at 25ns if I actually want it to be zero)? Vadim

[John_P1]

Hi Vadim,

By default the driver chooses the fastest timebase that accomodates your signal.  As long as your pulse width is less than ~53.69 seconds (which is when the counter would roll over if counting the 80 MHz timebase) then the 80 MHz timebase will be chosen.

If you specify an initial delay of "0" this actually gets coerced to 25 ns, so they should be equivalent.  I don't believe Low Time is coerced the same way (I would have to verify this), so you need to specify a Low Time of 25 ns to avoid the delay on a retriggerable single pulse generation.

Best Regards,

[VadB]

Hi John, So if I understand correctly, regardless of whether you set the output type of the counter to either Time, Ticks, or Frequency, you still need to define the Low Time (say, through a property node)? Also, does this only apply to retriggerable counters generating a single-pulse on each trigger or does this also apply to cases of finite number of pulses per trigger? Thank you again for your help. Vadim

[John_P1]

Hi Vadim,

The minimum time would be 25 ns, the minimum ticks would be 2.  When using frequency it becomes a bit more complicated, as you would need to pick a frequency and duty cycle that corresponds to 2 ticks of the timebase of low time (it's probably best to avoid frequency for retriggerable single pulse generation).

I'd have to set this up to validate what happens when generating more than a single pulse to be honest--I know the "initial delay" is only used on the first trigger, but I'm not sure offhand if the high time starts immediately on subsequent triggers or if you must wait for the low time first.  This should be easy to validate either way--if it turns out the low time must be generated you will probably want to implement the finite pulse train yourself by using two counter tasks like mentioned in the KB I linked previously.

Best Regards,

[VadB]

Hi John,

Thank you for the helpful advice! Based on your recommendation, I changed the counter output from frequency-based to time-based with 0 initial delay and 2.5e-8 low time, 0.020 high time and I think it's working (I'm monitoring the original TTL trigger and the output of the 6602). 

A slightly related question: if the source TTL trigger signal is quite noisy and I have digital filtering option for one triggered counter channel (10us minimum pulse width), do I have to explicitly specify the same filtering for another triggered counter channel as well (both counters should start outputing pulse trains simultaneously)?

Vadim

[John_P1]

Hi Vadim,

The digital filtering implementation is actually on a per-PFI line basis, so if you want your different tasks to use different filter settings you will just need to use a different PFI line as the trigger source for each task.

The PFI filters have a few pre-defined values that you can select, or you can choose to use a user-programmable pulse width (see the user manual).  You cannot have different user-programmable pulse widths on different PFI lines, but you can use any combinatino of pre-defined values and the single user-programmable pulse width that you intend to use.

Best Regards,

[VadB]

Hi John,

So if I understand correctly, I can trigger multiple counter output tasks off the same PFI line (i.e., same start trigger), but I can't use digital filtering within each task for that same line? or can I just specify the same filter setting (say one of the pre-defined 5us min pulse width) within each task?

I guess the bigger picture question I have is how multiple channels sample the same trigger source PFI line, i.e., if all counter output tasks run from the same clock, each task would sample the trigger PFI line at different pulses of the clock, so each task could theoretically run its own filtering resulting in a slight delay between the outputs of the different tasks? Is this correct?

Thank you!

Vadim

[John_P1]

Hi Vadim,

You can trigger multiple counter tasks off of a single PFI line as long as they have the same digital filter settings.  If you want to use different filter settings per task you will have to use separate PFI lines (at least 1 PFI line for each unique filter setting).

If the counter output tasks are armed they should all start generating together when the external trigger occurs (within 1 tick of the timebase anyway).  If the external trigger signal is free-running such that you can't guarantee that all of the counters will be armed together based on a software call to DAQmx Start Task you can configure an Arm Start Trigger and use a digital output to trigger all of the counters together such that they start on the same edge of the external trigger signal.

Digital filtering does result in a delay (between 1 and 2 periods of the filter clock on the 6602), so if you have different filter settings on different counter outputs you will see varying amounts of delay between them.  Any counters using the same filter settings as eachother should remain synchronzied (but will still be delayed).

Best Regards,