"CO Pulse" clock division

[bhpowell]

I've been going around with NI tech support for a few days without much progress, so I thought I'd try here.

I have an old system using a PXI-6602 (80MHz timebase) with Traditional DAQ and LabVIEW 8.2.

I am updating to a new system using a PXIe-6614 (100MHz timebase) with NI-DAQmx and LabVIEW 2019.

There's a counter set up for Frequency Shift Keying.  The input pulse (in my case, the device's timebase) is divided differently based on the polarity of the gate.

In Traditional DAQ, I set it up so that when the gate is low, the clock is divided in half:  two ticks low and two ticks high, yielding a 40MHz clock.  When the gate is high, it switches to four ticks low and four ticks high, yielding a 20MHz clock.

I want to do something similar with the new system, but using the faster clock:  I want a 50MHz output when the gate is low, and a 25 MHz output when the gate is high.

It seems like the "CO Pulse" function is the way to do this in DAQmx.  I've been using "CO Pulse Ticks", for consistency with Traditional DAQ.

However, when I try to use two ticks high and two ticks low, it seems like it's dividing the clock by four, and I get a 25MHz clock.

I tried the obvious and changed it to one tick high and one tick low, but got an error that said the minimum value is two.

I assume I'm doing something wrong here, since the newer hardware and software should have more features than the old system, right?  NI Tech Support seems to agree that it should be possible, but they've yet to provide the "how".  (If they do, I'll post it here.)

Any ideas?

[Kevin_Price]

Have you looked at the old system's signals on a scope?  I'll bet that you aren't getting *both* of the following when you configure for 4 Ticks high, 4 Ticks low:

- a 20 MHz output

- a symmetrical 50% duty cycle output with equal high and low time

The standard counter output behavior would give 10 MHz, 50%.  Configuring for a non-default "pulse mode" behavior would give 20 MHz, 25%.   Pulse mode makes the output pulse for 1 timebase cycle each time the high or low ticks count down to 0.   Dividing by 2 will *happen* to result in 50% duty cycle, but the more general case of dividing by N will give you a duty cycle of 1/N.

(Note: the default output mode is to toggle the output state when the countdown hits 0.  This makes it easy to get 50% duty cycle by using the same # high and low ticks, but you can only divide down by 4 or more). 

Here's an example to illustrate that config, and here's a thread with just a little discussion.

-Kevin P

[bhpowell]

As a matter of fact, I did use a scope on the old system with Traditional DAQ.  I didn't put a load on the output (other than the scope), so it wasn't the cleanest signal, but I did get a sense of the timing.

With 2 ticks high and low, I saw a pulse every 25ns (40MHz).

With 8 ticks high and low, I saw a pulse every 100ns. (10 MHz).

For my specific application, I just need to count edges of the output, so duty cycle doesn't matter.

(Specifically, the output of this counter goes to another counter that does "CI Count Edges", which can only count rising or falling edges, but not both.)

The examples you linked to are pretty much what I'm doing in my application for the CO Pulse.

[Kevin_Price]

You were stuck at 25 MHz in the original post, but now confirm that you're configuring like the example, which *should* let you get to 50 MHz with 2 high, 2 low ticks.

So does that mean everything's working as desired now?  Or are you still stuck at 25 MHz?

-Kevin P

[bhpowell]

I’m traveling this week, so it’ll be a week until I can try again, but in my last tests with DAQmx, 2 ticks low and 2 ticks high gave me 25 MHz in a 100MHz timebase. 

Is your experience different?

[Kevin_Price]

Once again, hmmmmmm.

Did some quick trials on a few systems during lunch break.  Unfortunately, all varied in terms of having years of separation among their DAQ devices and DAQmx versions.  Couldn't do any comparisons where only one of variables changed.

LV 2020 64-bit, DAQmx 20.1 64-bit, PCIe-6341, using 100 MHz timebase:

4 High, 4 Low, Pulse behavior: 25 MHz output

4 High, 4 Low, Toggle behavior: 12.5 MHz output

2 High, 2 Low, Pulse behavior: 25 MHz output (?!?)

2 High, 2 Low, Toggle behavior: 25 MHz output

3 High, 3 Low, Pulse behavior: 33.3 MHz output

3 High, 3 Low, Toggle behavior: 16.7 MHz output

3 High, 2 Low (or 2 High, 3 Low), Pulse behavior: 20 MHz (?!?)

3 High, 2 Low (or 2 High, 3 Low), Toggle behavior: 20 MHz

My assessment: something in that combo of driver & device seems to require a minimum of 3 Ticks to properly implement Pulse behavior, else it silently reverts to Toggle.

LV 2013 32-bit, DAQmx 9.8, PCI-6259, using 80 MHz timebase, Win Vista 64-bit:

4 High, 4 Low, Pulse behavior: 20 MHz output

4 High, 4 Low, Toggle behavior: 10 MHz output

2 High, 2 Low, Pulse behavior: 40 MHz output

2 High, 2 Low, Toggle behavior: 20 MHz output

All as expected.

LV 2016 32-bit, DAQmx 16.0, PCI-6115, using 20 MHz timebase (with old E-series era 24-bit counters), Win 10 64-bit:

4 High, 4 Low, Pulse behavior: 5 MHz output

4 High, 4 Low, Toggle behavior: 2.5 MHz output

2 High, 2 Low, Pulse behavior: 10 MHz output

2 High, 2 Low, Toggle behavior: 5 MHz output

All as expected.

FWIW, I also came across this post from John_P1, who posted the previously linked example.  John is an ex-NI insider who contributed a lot back around a decade ago and had an *extraordinarily* strong track record on DAQ hardware (maybe other things too, DAQ hw is where I kept seeing it).  His post seems to confirm support for divide-by-2 pulse mode behavior for an X-series board back in 2013.  So that makes me increasingly suspicious that the behavior I saw on *my* 6341 is a DAQmx driver bug.  

Later this week I should get a chance to try another system with an X-series board running 32-bit LV 2016 and DAQmx 16.0.

-Kevin P

[bhpowell]

Thanks for doing that investigation.  It's illuminating, and even hopeful.

NI tech support's latest response was, "that's how it works".  I asked them to escalate it to R&D.  I'm not ready to give up on this, and will use some of my backdoor escalation channels until I get a convincing answer.

For what it's worth, I'm attaching an image of my LabVIEW 8.2 Traditional DAQ example.  (Pulse specs 1 and 2 are two ticks, and pulse specs 3 and 4 are eight ticks.)

[Kevin_Price]

It's been a *long* time, but that brings back memories.  No units so effectively always just "Ticks".    Good ol' pulse spec 1-4 for defining output timing.  Seeing those reminded me of one of the few threads I've ever started here (and no one but me replied).

Since you seem to be delving into some fairly rare territory and finding anomalies, I figured I'd point you toward another one you might possibly find yourself running into.  Not likely, but not out of the question.

-Kevin P

[Kevin_Price]

Uh oh.  I saw the same pulse mode problem with an X-series board on our oldest system.

LV 2013 32-bit, DAQmx 9.8, PCIe-6341, using 100 MHz timebase:

4 High, 4 Low, Pulse behavior: 25 MHz output

4 High, 4 Low, Toggle behavior: 12.5 MHz output

2 High, 2 Low, Pulse behavior: 25 MHz output (?!?)

2 High, 2 Low, Toggle behavior: 25 MHz output

3 High, 3 Low, Pulse behavior: 33.3 MHz output

3 High, 3 Low, Toggle behavior: 16.7 MHz output

3 High, 2 Low (or 2 High, 3 Low), Pulse behavior: varied - either 20 MHz (?!?) or 33.3 MHz

3 High, 2 Low (or 2 High, 3 Low), Toggle behavior: 20 MHz

This is looking like a long-time X-series problem.  The M-series 6251 in the same PC showed correct divide-by-2 behavior in pulse mode (80 MHz timebase divides down to 40 MHz output).

I'm unaware (and fairly doubtful) that this has been documented as an X-series limitation or expected behavior.  Dunno if there's some hardware limitation (probably due to an oversight, I doubt it's on purpose) or if it's just a deeply-buried firmware bug.  Having given it more thought now, the DAQmx driver doesn't seem like a plausible suspect.  The loading of Ticks from registers in order to count them down at 100 MHz can *only* be happening in hardware on the device itself.

-Kevin P

[Kevin_Price]

Minor correction: not just an X-series problem, but likely a problem for any device based around the DAQ-STC3 timing chipset (first unveiled via X-series IIRC).  X-series use it, the newer counter boards 6612 & 6614 use it, several cDAQ chassis use it, not sure what else.

-Kevin P