80 MHz timebase as counter source

[bhpowell]

I am translating a Traditional DAQ Counter application to DAQmx.  The old hardware was a PXI-6602, the new hardware is a PXIe-6614.  Both have 80 MHz clocks.  They are very similar hardware devices.

I'm not a counter expert, but I'm pretending for this application.

One of the counters is used for "gated event counting", where the counter counts down a specified number of 80MHz clock while the gate is high, and toggles the counter output when the counter reaches zero.  Here's a subset of the Traditional DAQ code.  (I didn't bother with a snippet, since most people don't have Traditional DAQ installed.)

My understanding is that the "internal max timebase" will be 80M, which is then set as the "source selection".

Based on this post, I tried:

(Oops, I just now realized that these snippets left out the "Start", but the read autostarts, so it returns the same error.  This was a test VI that I derived from my actual code.)

This returns an error:

Error -200452 occurred at Property Node DAQmx Channel (arg 1) in Test GEC.vi Possible reason(s): Specified property is not supported by the device or is not applicable to the task. Property: CI.CtrTimebaseRate Channel Name: Dev1/ctr3 Task Name: _unnamedTask<52>

I've also read this post: Why Can't I Choose the Internal Clock in DAQmx Counter Input Example Programs?

I am using all 8 counters and don't have a spare counter to recreate the 80Mhz clock.

Here are a couple of other things I've tried, to no avail:

Calling the DAQmx Timing VI, which returns a similar error:

Error -200303 occurred at Test GEC.vi Possible reason(s): External sample clock source must be specified for this application. Unspecified Property: SampClk.Src Channel Name: Dev1/ctr3 Task Name: _unnamedTask<53>

And also trying to use the CountEdges terminal to /Dev1/Ctr3SampleClock, which returns the error

Error -89136 occurred at Test GEC.vi Possible reason(s): Specified route cannot be satisfied, because the hardware does not support it. Property: CI.CountEdges.Term Property: CI.CountEdges.ActiveEdge Source Device: Dev1 Source Terminal: Ctr3SampleClock Task Name: _unnamedTask<55>

Given that this was possible with Traditional NI-DAQ, I assume that I'm just missing something obvious.

But given that there's a KB entry that implies that you have to use an extra counter, I'm worried.

Another part of my app needs to use "CI Two Edge Separation", and I think it will have the same problem.  I want to count the 80 MHz clock in between two pulses.

Any ideas?

[Kevin_Price]

Hoo boy, lots to unpack here.  But I'd say you're doing a pretty fair impression of a counter expert from the things you've figured out already.   Let me try to help fill in some blanks.

1. The 6614 has a max timebase of 100 MHz and does not have an 80 MHz timebase.

1.1.  When I configure one of the internal timebases as a counting source for a counter, I typically wire up the Timebase.Src property.  I don't think I generally bother wiring the Timebase.Rate property, though it shouldn't hurt if you get it right.

1.2.  Not all internal timebases are readily available from the terminal constant by default (grrrrrrrr!).  You might need to right-click the terminal constant to change "I/O Filtering" and then enable "Advanced Terminals" to get access to the particular signal of interest (such as the 100 MHz timebase).

2. Are you actually going to read and use the count value?   Because what you're doing with the count down and output toggle is exactly the behavior of a pulse (train) output task, EXCEPT that your edge-counting task will only toggle once where a pulse task will do it twice per pulse.

2.1. Your edge count task will reach 0, toggle the output once, and continue counting down through 32 bits of counts.  But at 100 MHz, that only takes something like 43 seconds (2^32/100e6).  Then the output will toggle again, and so on.

2.2. While "toggle" is the default output "style" (as opposed to "pulse"), I think it might be correct and necessary that you configure it explicitly because the default *behavior* for an edge count task is not to route the internal output to a PFI pin.

2.3. On the other hand I'm pretty sure there's also a way to query the instantaneous count from an output pulse task, but don't recall for sure how.  Probably a property node rather than a call to DAQmx Read.  I KNOW I relied made use of this ability for an app in traditional NI-DAQ and think I recall confirming the capability back in the early days of DAQmx.

3. The article about the internal clock is referring specifically to a *sample* clock.  Most devices (including the 6614, I *think*) can't derive their own sample clock from the internal timebases.  (Though I learned relatively recently that some common devices *CAN* actually use the 100 kHz timebase directly.)

4. Do you *need* to do hw-clocked sampling as well as hw-driven counting?  Or were your attempts to set up a sample clock just part of a "hey, let's just try some stuff" troubleshooting effort?  I do a lot of those myself...

5. The problem referencing Ctr3's sample clock is probably related, especially if Ctr3 wasn't configured to have one (and perhaps also already started, or at least reserved/committed). 

5.1. I have a vague and untrustworthy recollection that even though the MAX routing table shows terminals like "/Dev1/Ctr3SampleClock" being readily routable, I got errors when trying to do so.  But I think I was just briefly dabbling with it for the sake of answering a question on the forums here.  I didn't dig too awfully deep.

Summing up, I think your first snippet would probably start working once you specify the 100 MHz timebase terminal (whether or not you also explicitly specify a 100 MHz rate).  But it's possible that a pulse output task would be a more appropriate choice.  I don't know your app enough to say one way or the other, just that your edge-count task is being configured to have partly similar behavior.

-Kevin P

[bhpowell]

Thank you, as always, Kevin, for your knowledgeable reply.

I'll need to digest it fully, but a few initial comments...

1. Hmm, I was confused by the 6614's spec sheet talking about a Maximum Source Frequency of 80 MHz on the PFI lines, but you're right, there is no 80MHz timebase.  I'll need to fall back and regroup on what this means for the application.  It was written assuming 12.5ns ticks, and gets timing information (in ticks) from an external program that I cannot change.  I may have to stick with the 6602, unless I can convince myself (and my customer) that we can internally convert 12.5ns ticks to 10ns ticks without affecting the program.

2. The events this system is measuring occur within a span of a millisecond, so I'm not worried about overflowing counters.  A toggle on the output is a one-time occurrence, and soon everything is reset.  Counts are harvested from several counters as part of the report of "what happened?" back to the external program.  I believe these are included in that, but I'll double check.  Since they count from a known value down to zero to do their thing, what happens after they hit zero may be irrelevant.

3. If I stop and think about it, I understand the difference between reference clocks and sample clocks, but that doesn't mean I always stop and think about it.  See #1. 🙂

4. I'm not sure I understand your question here.  I'd say my initial efforts were driven by, "Let's try and find the DAQmx concept that matches what Traditional DAQ was doing."  Sometimes that's really straightforward.  And other times, I go off into the weeds.  Maybe I just need hardware-driven counting and unsure how to configure it.  Everything has to be under hardware control because the events all happen so fast (sensing inputs that trigger outputs at precise times).

5. Figuring out what's routable has just been trial and error for me.

My next steps:

a) see if I can at least make the 100MHz timebase be a source without getting an error

b) decide whether I can deal with a 100MHz timebase instead of an 80MHz timebase

[Kevin_Price]

4. I was mainly just getting at the key idea that *counting* (based on signals coming into the SOURCE pin) is distinct from *sampling* (based on signals coming into the GATE pin).  Much of the discussion didn't seem to involve hw-clocked sampling, but one of the late code snapshots did.

   This distinction has been a source of confusion in many past threads because it's just plain *different* than the other kinds of I/O.  But it's clear enough to me now that you get it, and don't need the emphasis or reminders.

5. MAX is pretty useful for figuring out what's routable where.  Just select the device and then go to the tab (at the bottom of the window) for Device Routes.

-Kevin P

[Kevin_Price]

P.S. RE: signal routes.  The yellow-coded indirect routes typically need to consume a counter to accomplish their route.  I don't know how DAQmx decides which one though.

-Kevin P