Counter Initial Delay 10 msec too long

[Steve_TDiode]

I am observing a counter task taking 10 msec too long to start generating its pulses.  

Tested by running a counter task with an Idle State that is then Stopped and Cleared. 

A second counter task is then configured with opposite Idle State.  When that second task is started, the counter output first transitions to that opposite Idle state for at least 10 msec before beginning to generate pulses. 

When the second counter task's Initial Delay is 0, the counter output changes to the second Idle state for 10 msec before starting to generate pulses. 

When the second counter task's Initial Delay is 0.05 sec (50 msec), the counter output changes to the second Idle state for 60 msec (an extra 10 msec) before starting to generate pulses. 

An oscilloscope, set for single sweep and to trigger on the slope of the second Idle state, can be used to monitor the counter output.

DAQmx 21.3, LabVIEW 2017, USB-6343

Example attached,

[Kevin_Price]

Try the following experiment to help diagnose:

1.  Set up triggering for the second- pulse.  It should transition to idle state when you call Start.  Be sure you're in control of the trigger signal so you don't assert it until *after* you've started the 2nd pulse task.  Then you should see 'initial delay" from the trigger until the first pulse transition, without an extra 10 msec.

2. Did you try using different counters for the first and second tasks?  I don't think the behavior should be different, but it's an easy thing to check to start eliminating suspects.

-Kevin P

[Steve_TDiode]

I wasn't clear that the second counter task uses the same counter (CTR0) as the first.  It just has its Idle State the opposite as its first configuration.  That is done in order to be able to see when starting a task (the second one) actually starts pulsing.  Basically, if a counter task has a High Idle State and is stopped and cleared, its output will be High.  If that same counter is then created but with Low Idle State, when it is started, I would expect it to begin generating its pulses.  Instead what I observe is that its output first goes Low (to its Idle State ?) for 10 msec and then begins generating pulses.  If its Initial Delay is set to 50 msec, its output does go Low for some time before beginning to generate pulses, but it goes Low for 60 msec not 50 msec.

You can look at my example code to see that no triggering is used and that the same counter is used. 

Steve

[Kevin_Price]

Yes, I understood all that.  I was suggesting you try a couple different things as diagnostic steps.  The first thing focuses on possible delays due to the DAQmx Task State model, the second focuses on they way that some aspects of cleanup from a call to DAQmx Clear may continue on *after* the call returns.

Offhand, I'd think the 2nd thing has more chance of causing delays in the order of 10 msec, but figured both are worth looking at.

-Kevin P