Counter pulse generation issues when synchronizing with analog output sample clock

[b!tmaster]

Hello,

The device I am using is a NI USB-6229 USB. I have written a program that produces a finite sine wave on the analog output that consists of 200ms worth of samples. In addition to the analog output, I am trying to turn on 2 counters for the duration that the analog output is active.

I experience an issue depending on how many high ticks I define for the counter. The counter output works as expected as long as the number of high ticks is less than the number of samples I am generating for the sine wave. For example, if I configure the counters to use a number of ticks equal to 100ms I get the following output on my oscilloscope.

Note: Analog output shown in yellow, counter 0 is D0, counter 1 is D1, & D2 is my start trigger signal.

The counter output does not work as expected if the number of high ticks is equal to the number of samples I am generating for the sine wave. For example, if I configure the counters to use a number of ticks equal to 200ms, I get the following output on my oscilloscope.

The expected behavior is that the counters would have been set to low at the same time that analog output 0 returns to 0V. But, one will notice that D0 & D1 (counter 0 & counter 1 respectively) stay high for longer than expected. If we zoom in, in-time on oscilloscope we can see that counter 0 turns off roughly 5ms after the analog output returns to 0 (this is shown in the screenshot below). We can also see that counter 1 turns off roughly 1ms after counter 0 returns to 0.

This behavior is not acceptable for my application. I need to get the analog output & counters synchronized such that the counters turn off when the analog output is complete.

I have attached a sample project that demonstrates this behavior.

How can I solve this issue?

[b!tmaster]

Just to be clear, I would like to explicitly mention that in the attached example program, one can change the counters to use high tick values of 500 and the counters will work as expected.

[Kevin_Price · Accepted solution]

I've done a lot with counter/timers and am unaware of a bug or idiosyncrasy that should leave you stuck with what you've observed.  I do my programming in LabVIEW, but I did take a look at your code to see if anything major jumped out.  Nothing did.

The "initial delay" parameter is one that I generally feel the need to research or experiment with whenever I have crucial timing to consider.  It has seemed to have variations in behavior for different boards, different driver versions, maybe triggered vs not, maybe multiple pulses vs single.  I've been around this stuff a long time but am not dabbling in the intricacies all that frequently any more, so I don't really trust my memory.

As defined in your code, your AO task will generate 1000 sample clock edges.  Your counter pulse parameters *ask* for 0 ticks worth of initial delay, 2 ticks worth of low, 1000 ticks high. 

However, most counter parameters require no less than 2 timebase edges.  When you ask for 0, it may coerce up to 2 or it may ignore the illegal input and use some unknown default value.  It also could throw an error but that doesn't seem to be happening in your case. The behavior will be defined and repeatable, I just can't tell you with 100% certainty what it'll be.

Thus, the counter pulse you've programmed will require *at least* 1002 AO sample clock edges, possibly 1004 or more.  The task *might* use (coerced) init delay ticks and high ticks, it might use low ticks and high ticks, it might use all three.  Again, it will be defined and repeatable, I just don't know for sure off the top of my head.

There is probably something in your code that stops the counter task in software after the AO task ends, otherwise I wouldn't expect to *ever* see it transition back to low.  Put a breakpoint before stopping the pulse task and see if the counter doesn't just "hang" in the high state.  If so (as I think it will), then you can experiment to find out whether you need to define the parameters as (2,2,996) or (2,2,998).  If the latter, one of those '2' values is being ignored, though I can't tell you which one with confidence.

You could further refine the behavior by adding some dummy samples of 0 Volts AO so that you could have 1002 total samples, 1000 of which are the real sine wave which line up perfectly with counter pulse edges.

-Kevin P

[b!tmaster]

Kevin,

I have confirmed that my counters were being created with an implicit 2 ticks for their initial delay. I modified my function generator code to add 4 0's to the end of my analog output data array (2 for the counters initial ticks & 2 for the counters off ticks) and it appears that my counters are now working as expected.

Thank you for your suggestion!

For others who come across this post in the future,

Something I just learned about working with counters and the .NET API is that if you request an initial delay of 0 ticks, the counter will use an implicit 2 ticks for the initial delay without throwing any errors but if you request an inital delay of 1 tick, you will get a runtime error. This is a serious inconsistency IMO (if you pass the CreatePulseChannelTicks function a value of 0 or 1 for low ticks you get a runtime error).