Counter Out task, initial delay, and commit

[jonasz]

I don't know whether it's a bug, a feature, or me not understanding how to do things correctly.

I create a counter-out task with DAQmxCreateCOPulseChanTime, with an initial delay. Then I set DAQmxTaskControl(stimOutTaskHandle, DAQmx_Val_Task_Commit).

When I now start the task, I don't get the initial delay, but the rest of the pulse looks like desired. If I do not commit the task, the delay is as expected.

[John_P1]

Hello again,

This is on the 6251 right?  Can you confirm if the very first trigger signal uses the initial delay or not?

If the problem only starts with the 2nd trigger and onwards, try setting the low time to be equal to the desired initial delay (I'm thining it might be similar to the weird M Series behavior that is seen with retriggerable counter output tasks).  There isn't really a downside to this since the low time isn't used for anything else when you're just generating a single pulse.

I'd probably consider it a bug, but it's how the M Series hardware works and it's not really fixable on these devices (X Series devices however correctly use the initial delay on re-triggered pulses).  I guess at this point this behavior has become more of a 'feature'.  Whenever I'm generating a single pulse I have gotten in the habit of setting the initial delay and the low time to be equal due to this behavior.

If this isn't the problem, then I'm not really sure--somebody from NI would have to look into it.

Best Regards,

[jonasz]

Thanks John,

The first one indeed has the initial delay, and it's also on the 6251. I forgot to mention that indeed I also want to possibly play more than 1 pulse, set with DAQmxCfgImplicitTiming(stimOutTaskHandle, DAQmx_Val_FiniteSamps,nPulses), with initial delay != low time. For one pulse your suggestion indeed works.

So back to square one and not commit the task then ...

[John_P1]

Generating a finite pulse train uses 2 counters on M Series (the driver configures the second counter for you--one counter gates the other one to output the desired number of pulses).  You could instead configure each counter manually.  This would allow you to effectively include the initial delay on a retriggerable sequence of pulses.  

The link in my last post has an example of it (although the example doesn't seem quite right as it doesn't set the initial delay input so the first pulse train wouldn't have the delay...).  In your case, you wouldn't configure the counter to be retriggerable or use a start trigger but instead commit the single pulse task before the loop and start it whenever you want to issue your finite sequence of pulses.  The continuous counter output task will stop when the gate goes low and resume where it left off when the gate goes high, so the gating signal must be exactly as long as the pulse sequence.

Best Regards,