Controlling Throughput of CI/CO Tasks with cDAQ-9178 and DI/DO Module

[ccp1999]

Hi everyone,

I’m using the cDAQ-9178 along with a general-purpose counter and a DI/DO module. I need some advice on how to control/figure out the throughput of a Counter Input (CI) or Counter Output (CO) task effectively. I am able to do this on analog modules and it was fairly simple: number of channels x sampling rate x ADC resolution. But how is it with counters? Do I need external sample clock? I have seen examples that use one counter on DO to create a clock signal and use another counter on DI to count the edge. I am very confused on using Sample Clock.vi with counters....Say if I wanna achieve 1 MB/s from a CI task, is it possible? 

Any insights, suggestions, or examples from your experiences would be greatly appreciated!

[Kevin_Price]

A phrase I've found myself writing lots of times over the years in these forums is, "counters are just different" than other I/O types.

With AO and DO, you set a specific output state on a terminal pin.  You can measure and confirm the output with a voltmeter.  For all DO I know of and many AO as well, that state persists until your program chooses to change it.

With AI and DI, you can measure and capture a specific input state from a terminal pin.  You can measure and confirm the input with a voltmeter.

Counters are, well, different.  Counters are not generally "interested" in static states, they are meant to control or characterize digital transitions, often doing so relative to a another set of constant frequency transitions issued by a fixed timebase clock.

With CO, you set up timing parameters that designate when the rising and falling edges need to occur, typically based on time as determined by a fixed-rate timebase clock.  With many kinds of CI, you'll be characterizing intervals between transitions, again typically based on time as determined by a fixed-rate timebase clock.

Then there are some further considerations people get used to around AI, DI which simply don't apply the same way with counters.  Such as Nyquist rules that require "sampling" at >= 2x the max frequency of interest.  When you use a counter to measure frequency, you're *actually* much better off sampling at maybe <0.01x the frequency of the incoming signal because your most important measurement constraint is *quantization* error.

So when you ask about 1+ MHz CI, the answer is that yes you can probably accomplish that with a CI task.  But a pretty significant majority of the time I've gotten into threads here where someone wants to sample that fast, we eventually find that someone's erroneously applying Nyquist to their CI plans and that they really *ought* to be sampling much much slower.

    (CI using encoders tends to be an exception.   Encoder tasks tend to have much more in common with AI and DI.) 

So having said all that, can you describe the particular needs of your app in detail?  I can probably answer specific questions, but counters are awfully versatile so I don't yet know which of their many optional usages to focus on.

-Kevin P

[ccp1999]

Hi. Yes indeed I have observed that counters are very different and tricky. I'm trying to control the throughput of CI and CO applications, but let's start with CO first. If I'm not mistaken, the data size of counters should be 4 bytes. Given this, how to control its rate and make total data throughput, say, 1 MB/s? (If this was AI, I could just simply set the rate to 250kHz)

I started with the LabVIEW example: Counter (Buffered) - Continuous Output.vi. I played around with elements in the array and most of the time I get buffer underflow error. Why? But I do notice that the throughput gets higher when the time unit is in microseconds.

In addition, I would like to confirm if I'm understanding counters correctly. We have the general purpose counters in the cDAQ chassis, and I'm using them to generate pulse train. Now we can control the frequency of this pulse train by specifying frequency, high/low time, or ticks? 

And also depending on the output terminal (two cDAQ PFIs or DO modules?), maximum allowable output frequency would be different? 

Sorry for the late reply. Things were on hold. Thanks.

[Kevin_Price]

---

I started with the LabVIEW example: Counter (Buffered) - Continuous Output.vi. I played around with elements in the array and most of the time I get buffer underflow error. Why? But I do notice that the throughput gets higher when the time unit is in microseconds.

By default, continuous buffered output tasks will regenerate their buffer of samples by repeatedly delivering the data from PC memory down to the DAQ device.  The smaller the task buffer, the more often the DAQmx driver needs to negotiate bus access to deliver that data in smaller chunks.

    When the output is predefined and known ahead of time, one very simple technique to avoid underflow error is to simply write multiple copies of the pattern to be generated before starting the task.   If your pattern needs 10 samples, instead of only writing 10 samples to the task buffer you could concatenate a copy of those 10 samples end to end 100 times for a buffer size of 1000.  The same repeating pattern is still represented, but now DAQmx has a much easier time avoiding underflow errors.

---

...Now we can control the frequency of this pulse train by specifying frequency, high/low time, or ticks? 

Yes.  (But ultimately, all those methods get converted to Ticks because the counters themselves work on integer counts)

And also depending on the output terminal (two cDAQ PFIs or DO modules?), maximum allowable output frequency would be different? 

I don't have expert-level knowledge about cDAQ hardware, but your interpretation appears correct.

-Kevin P

[ccp1999]

I figured that by frequency would be the most straightforward way. And the data size is actually 8 bytes. 3MHz x 8B = 24MB/s and I did monitor this much of throughput from PC to cDAQ. 

---

    When the output is predefined and known ahead of time, one very simple technique to avoid underflow error is to simply write multiple copies of the pattern to be generated before starting the task.   If your pattern needs 10 samples, instead of only writing 10 samples to the task buffer you could concatenate a copy of those 10 samples end to end 100 times for a buffer size of 1000.  The same repeating pattern is still represented, but now DAQmx has a much easier time avoiding underflow errors.

Is my for loop doing what you saying here? But the problem with my VI is, I couldn't go for higher frequency. With 4MHz, underflow occurs almost instantly and I also couldn't set a larger array size. Max I have tried is up to 60M. 

[Kevin_Price]

I think we're back to my msg #2 -- remember, counters are *different*.   For a case like the one you show in the latest screencap, when freq & duty cycle are constant you don't need to write any buffer at all.  See the example for continuous counter output that doesn't mention a buffer.  Config one time for 3 MHz pulses and 0.5 duty cycle.  Those values go down to the DAQ device ONE TIME ONLY, then the hardware does all the work with no further bus traffic and no possibility of underflow.

(Note: you cannot actually generate 3 MHz exactly.  You'll get a neighboring integer divisor of your 80 MHz timebase, dividing down by either 26 or 27.)

Can you describe more about your overall app's needs?  I'm starting to get the feeling that at least in part, we might be working to solve the wrong problem...

-Kevin P

[ccp1999]

I'm trying to understand how counters generate traffic and if I can control them. I agree with you that it is pointless to write that large array into counter. I have combined CO and CI:

• CO, ctr0 generates pulse train 
• CI, ctr1 counting edges

The ctr0 pulse train is used as sample clock source of ctr1, and regardless what ctr1 is counting, ctr1 is counting at the speed of the ctr0 pulse train...then given data size is 4B, the traffic can be calculated and I did verify it. For example, 1MHz sample clock gives 4MB/s, 3MHz 12.33MB/s (as you mentioned, it is not exactly 3MHz actual frequency).

So given sample clock source, the CI works like AI, but would take up two counters for this application. cDAQ-9178 has 4 counters, so I can only have two instances like this at a time, or one CO can sourced to 3 CIs?

[Kevin_Price · Accepted solution]

1. Generally, 1 CO can source to 3 CI's, especially when you're using internal routing within the chassis.  When you source to external things, you can sometimes run into current limit issues, but those don't tend to occur for internal routes.

2. Be careful about the difference between *sampling* and *counting*.  Ctr1 will *count* at the speed of the signal being counted.  It increments the count register value once per active edge.   INDEPENDENT of the counting that's going on, you can also SAMPLE the count value.  So yes indeed a 1 MHz sample clock will sample those 32-bit count values at 1 MHz, resulting in the need to support 4 MB/s bus traffic.

3. But I'm a little skeptical about whether you *need* to sample at such a high rate, as mentioned back in msg #2.  The counter will increment its count value whether you sample it or not.  Unlike Nyquist rules for AI, you *don't* need to sample at >= 2x the count frequency.  It's far more common to sample at <= 0.01x the count frequency, allowing time for the count value to change appreciably between samples.

-Kevin P

[ccp1999]

Got it. Yea I understand the concept of "counter counting" and "reading the counts", but I needed the traffic so need high sampling rate. Thanks for your help.