Reading counter value when sample clock faster than counter clock

[cwierzynski]

I am trying to read the value of a counter whenever my sample clock goes high. The counter input, however, is much slower than the sample clock, so the counter will often be unchanged from one sample edge to the next. I am using the *SAME* sample clock to read some DIO lines.

When I use the DAQmx Counter 1D U32 NSamp vi, I only get samples whenever the value of the counter changes. So even though there may be 10 sample edges, there might be only 2 counter values returned. When I expect the last 10 counter values to be, say,

[0,0,0,0,0,0,0,0,1,1]

I get instead

[0,1].

Meanwhile, when using Digital 1D U32 1Chan NSamp to capture the digital IO lines, I get (as I expect) a sample for each edge
of the sample clock.

How can I tell the counter input task that I want to know the value of the counter at EVERY sample clock edge, and not just when the counter value changes?

I'm using a M-series PXI-6254.

Thanks very much for your help!

Cas

[Kevin_Price]

Cas,
I did a real quick test and it seemed that the way to get the (seemingly) normal behavior you expected requires you to set the property node item "Duplicate Count Prevention" to True. It's found under the DAQmx Channel property node at Counter Input-->General Properties-->More-->Advanced-->Duplicate Count Prevention.

There's online help for that property which to my eye seems to misleadingly suggest that it isn't needed for your app. I also recall doing similar sampling without needing to configure any such special properties using traditional NI-DAQ circa 6.9.x. I wonder if this is another little DAQmx surprise? (I've found a few other items that take a bunch of trial-and-error to figure out how they *really* work).

Hopefully t
his'll work for you. I can't claim to have tested it hard enough to make any guarantees, but it did look promising.

-Kevin P.

[cwierzynski]

Thanks Kevin! Actually I tried that property, but based on its name I thought I should set it to FALSE (don't I want to turn *off* the prevention?). Anyway, setting it to TRUE gives me exactly what I want!

With one small catch...when I use the onboard 10MHz clock, everything is fine. When I use the 20MHz or 80MHz clocks, though, I set samples of the counter when I expect them except the counter never increments. If I reset the property, the counter incrememnts but the samples are only taken when they change values (the original problem).

Do you notice a dependence on the speed of the counter input clock ?

(You may wonder why I am doing this -- I have cascaded two counters and the high-order bits change very very slowly, yet I want to read the
m every time I read the low order bits, which change quickly.)

Thanks!
Cas

[Kevin_Price]

Cas,

Just had a short time to try a couple things and I can't say that the results are all that clear.

Note: to avoid rewiring my setup, the sample clock was always set to use the onboard 100kHz timebase. I observed the same failure to increment count when using either the 20 MHz or 80 MHz onboard timebase, with "Dup Count Prevention" set to TRUE. The count *did* increment when set to FALSE.
With the 10 MHz reference clock, the count incremented for either TRUE or FALSE. This was also the case when using a 20 MHz timebase routed from another board in my system.

If you need a workaround, perhaps you can read the high-order bits as a non-buffered software-timed measurement. You could read it right after your
bu
ffered hardware-timed read of the low-order bits. If you see its value change, you would then inspect the array of low-order bits to determine which values belong with the old value of the high-order bits, and which with the new.

-Kevin P.,
wishing DAQmx was a little easier to love.