Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

"CO Pulse" clock division

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?

Brian Powell
Stravaro, LLC


Learn more about the DSH Pragmatic Software Development Workshops.
0 Kudos
Message 1 of 17
(2,983 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 17
(2,935 Views)

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.

Brian Powell
Stravaro, LLC


Learn more about the DSH Pragmatic Software Development Workshops.
0 Kudos
Message 3 of 17
(2,931 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 17
(2,916 Views)

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?

Brian Powell
Stravaro, LLC


Learn more about the DSH Pragmatic Software Development Workshops.
0 Kudos
Message 5 of 17
(2,911 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 6 of 17
(2,882 Views)

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.)

 

Screen Shot 2021-06-01 at 8.56.10 PM.png

 

Brian Powell
Stravaro, LLC


Learn more about the DSH Pragmatic Software Development Workshops.
0 Kudos
Message 7 of 17
(2,875 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 17
(2,859 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 17
(2,829 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 17
(2,805 Views)