09-18-2007 02:14 AM
09-18-2007 08:57 AM
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.
09-19-2007 02:22 AM
09-19-2007 06:37 AM
06-22-2010 02:11 AM
Hi:
Can you give a example about the 2nd method?