ni6602: strange delay between start of single and finite pulse train

[reszelaz]

Dear all,

in my setup I use ni6602 card and linux nidaqmx 8.0.1 driver. I want to configure two counters: one in single pulse train generation mode and the other in finite pulse train generation mode. To both of them I route the same timebase source, generated by the other counter (exactly TC of the other counter). I start both of the train tasks before any timebase tick is generated. I have configured 0 delay, 3 ticks length high state and 2 ticks lenght low state in both of them.  The only difference between these two tasks is that single pulse train is configured to generate one pulse and  
finite pulse train is configured to generates 2 pulses.

What is surprising me, is that pulses which they generate do not start simultaneously. Could anyone explain me why? I suspect that it has to be
related to the fact that finite pulse train uses two counters.

I attach the pseudo code which I use:

//here I set up another counter which will generate timebase source for the following two

DAQmxCreateTask("SingleTask", singleTask)
DAQmxCreateCOPulseChanTicks(singleTask, "Dev1/ctr4", "Channel_4", "/Dev1/RTSI0", DAQmx_Val_Low, 0, 2, 3)
DAQmxCfgImplicitTiming(singleTask, DAQmx_Val_FiniteSamps, 1)
DAQmxStartTask(singleTask)

DAQmxCreateTask("FiniteTask", finiteTask)
DAQmxCreateCOPulseChanTicks(finiteTask, "Dev1/ctr6", "Channel_6", "/Dev1/RTSI0", DAQmx_Val_Low, 0, 2, 3)
DAQmxCfgImplicitTiming(finiteTask, DAQmx_Val_FiniteSamps, 2)
DAQmxStartTask(finiteTask)

//at some point timebase source will start to be generated

I also attach the screenshot from scope.
Description:
yellow signal - timebase source for single and finite tasks
green signal - single pulse generation task (1 pulse)
purple singnal - finite pulse generation task (2 pulses)

My questions related to what we can observe on the scope:
1) Why both tasks ignores first tick?
2) Why finite pulse train has delay of 2 timebase ticks in respect to the single pulse.

Anothter question:
DAQmxCreateCOPulseChanTicks function allows delays from 2 up to 4294967295 for Single Pulse trains
and from 4 to 4294967295 for Finite Pulse trains. Why?

Using trial and error method, I have found that setting up delay of 4 for singleTask, synchronize start of both tasks.

Cheers

[AlexanderRyabov]

---

@reszelaz wrote:

I have configured 0 delay

---

Hi,

you cannot configure zero delay, zero means default value.

Single pulse: delay = 2 ticks

N Pulses: delay = 4 ticks

Specify delay = 4 ticks for both and they will start simultaneously

--

Alexander

[reszelaz]

Hello Alexander,

thank you for your reply, do you know from where comes this restrictions? 

Cheers

[AlexanderRyabov]

Delay used for loading program into board memory for buffered operations, use pause trigger for starting immediately.

[Julio Lidón]

Hi both,... 

I also experienced that problem in another application I've been working on...

I found also the same value 4 to get both synchronised,... but I don't understand why,..

Can  you explain why do you think that pause trigger work? the delay I got between both signals had a systematic value,... It didn't look to me as if it was a software related thing.

I would really appreciate if someone could cast some light on the hardware-related reasons of that behaviour?

Thank you very much in advance for your time!!!

[AlexanderRyabov]

Hi Julio,

Each counter requires at least 2 ticks delay for arming.

if you generate single pulse or continuous pulse train, it requires one counter, initialisation delay for these operations is 2 ticks.

if you generate finite number of pulses two counters are used, each of them requires delay, total delay is 2+2=4 ticks

But you can arm first counter manually to produce timebase you needed with pause trigger, and gating it with another one, in this case start delay will be 2 ticks!

--

Alexander