Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

counter roll-over when measuring period

Hi,
 
I'm using PCI-6251 counter 0 to continuously measure the period of a signal, and I notice there are occasionally  error readings. Since the counter can roll over when it reaches 2^32-1, I need to know what will happen to the period measurement when counter roll overs. Would anyone please help me?
 
Thanks.
David
0 Kudos
Message 1 of 5
(7,410 Views)

The count value will simply wrap-around back to 0 and then continue to increment.  I can think of a few ways to handle this:

1. Specify a slower timebase for the measurement.  If you go from, say, 80 MHz to 100 kHz, it'll take 800 times as long a period to cause rollover.  This method is pretty simple to implement, but not all apps can accept the loss in precision.

2.  You can use a 2nd counter to be sensitive to the 1st counter's "terminal count".  This gets a bit complex, so you may need to do more research on some of the terms that follow.

An internal pulse signal is generated on the board when the 1st counter rolls over from 2^32-1 back to 0.  It's commonly known as "terminal count" or TC.  You'll need to configure a 2nd counter that also measures periods of your external signal, but which uses those TC pulses as its timebase signal.  You may need to fiddle with the "Duplicate Count Prevention" property on the 2nd counter so that it will buffer values of 0 during the majority of intervals where no TC pulse occurs.  During the intervals where rollover happens, the 2nd counter will count how many times it happens.

You would further need the 2 counters to be started off a common "arm start" trigger to keep their data sync'ed.

3.  Software method.  You can query the DAQmx Channel property "Counter Input -> General Properties -> More -> Terminal Count Reached".  When you get a 'True' output, the property resets such that subsequent calls will return 'False' until the next rollover occurs.  The problem here is trying to correlate this software-detected rollover with a specific period in the 1st counter's measurement buffer.  You'd probably also need to be querying and tracking the DAQmx Read property for Total Samples Acquired both before and after the TC event.  Even then you might not always be able to determine unambiguously which interval had the TC event.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 5
(7,404 Views)
Hi, Kevin,
 
What you mentioned seems to be edge count function, not period measurement. When doing edge count (DAQmxCreateCICountEdgesChan) , the counter will roll over and start from zero again. But when doing period measurement (DAQmxCreateCIPeriodChan), the reading will be difference of the counter values between two input signal rising edges. So I would like to know what the difference value will be when counter roll overs. For example, what will be the returned value when 3000- (2^32-1)?
 
David
0 Kudos
Message 3 of 5
(7,389 Views)
David,

1. Hmmm, I see rollover happen during period measurement as well as during edge counting.  I'm using an E-series board under DAQmx in LabVIEW.  The measurement type is the one for single counter period measurement.  I used the other counter to generate a freq just slightly lower than the rollover rate (1.192 Hz for the 24-bit counter and a 20 Mhz timebase).    The "TC Reached" property pulsed as expected and the data values were very small (1307 ticks, i.e., about 65 microseconds after rollover).

2. Maybe I misunderstood your question.  In fact, during "Period Measurement" mode, the actual hardware count register on the board resets to 0 on each incoming edge to be measured.  It doesn't just keep incrementing up to the rollover point, and the driver isn't doing a subtraction behind the scenes.  Rollover only happens if 1 single interval is too long.

3.  If you are careful with your datatypes and make sure that your values are 32-bit Unsigned integers (U32), then the result of 3000-(2^32-1) = 3001, just as you would hope.  Be sure to read your counter data as u32 values.  But note again that this kind of software-based subtraction shouldn't be needed for period measurement -- the hardware will do the grunt work.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 5
(7,380 Views)

Hi:

Can you give a example about the 2nd method?

0 Kudos
Message 5 of 5
(5,775 Views)