Prescaling

[MikeGI]

Is it possible to prescale a period counter task on 6602 board?

I've tried using 'DAQmxSetCIPrescaler', but nothing happened with no errors returned.

[Robert_F]

Hello Mike,

Below is an excerpt from the DAQmx C Reference Help document. (Start >> All Programs >> National Instruments >> NI-DAQ >> NI-DAQmx C Reference Help)

“Prescaling allows the counter to count a signal that is faster than the maximum timebase of the counter. The TIO counters offer 8X and 2X prescaling on each counter. You can disable prescaling. Each prescaler consists of a small, simple counter that counts to eight (or two) and rolls over. This counter is specifically designed for this application and can count signals that are faster than the general purpose counters. The CtrNsource signal on the general purpose counter is the divided signal from the simple counter.”

You would use the DAQmxGetCIPrescaler function. (int32 __CFUNC DAQmxSetCIPrescaler(TaskHandle taskHandle, const char channel[], uInt32 data);)

You should be able to use this function with the PCI-6602.  You are not getting an error?  What is the frequency of the signal that you are trying to measure?  How do you have your signal connected?

[MikeGI]

Hi Rob,

It's been a while but I'm finally back on this issue.  I used the Set function to set the prescale to either 1,2, or 8.  Then I used the Get function to check that the prescale actually did get changed, which it did.  So I can perform those 2 functions without error.  But there is no difference when I look at the counts themselves. 

I split a TTL wave into two counters and made one a prescale of 1 and the other a prescale of 2, then plotted the samples.  There were no differences between the two counters except maybe 1 or 2 ticks apart.

Is it even possible to use prescalers with the internal clock?  Or is it only used with an external?

-Mike

[MikeGI]

Also my TTL wave is outputted from a calibration box, which can create 300, 600, 1200, and 2400 Hz waves

Message Edited by MikeGI on 08-01-2007 10:06 AM

Message Edited by MikeGI on 08-01-2007 10:06 AM

[Kevin_Price]

I *think* but don't know for sure that the prescalars are only for external signals, not for the internal timebase.  Also, while they can be applied to counter "Source" signals, I'm not sure if they can be applied to counter "Gate" or "Sampling Clock" signals.  I'm a little surprised that your tests gave you unexpected results but no errors.

Why are you trying to pre-scale the internal timebase?  If there's a good reason for it, a workaround is simply to perform a prescaling-like function by generating a clock with one of the counters.   You could then divide the internal timebase by any integer >= 4 (both High Ticks and Low Ticks must have a minimum value of 2), and use this counter's output as the timebase for your period measurements.

However, I'm having a tough time thinking of a good reason to pre-scale the internal timebase.  Avoiding counter roll-over is about the only reason that occurs to me, and you can almost always achieve that by selecting a slower internal timebase in the first place.  The choices are 80 MHz, 20 Mhz, and 100 kHz. 

-Kevin P.

[MikeGI]

Hi Kevin,

I am thinking of the prescaler as a divide ratio.  Where a divide ratio only stores the count on every 1,2, or 8 gate events.  I am not sure if that is correct, though.

Here is the situation I am thinking about using it in:

If we have two gears, one with 100 teeth and the other with 800 teeth, that are running at that same speed, they will ahve a sampling ratio of 1:8.  If we have an encoder on each gear we want to use the 6602 card to count x amount of times a gear tooth passed by it.  If each channel had a divide ratio of 1, channel 1 would run 8 times as long as channel 2, since it has a slower sampling rate.  To make the channels run for the same amount, channel 1 would have a divide ratio of 8, causing it to run 8 times longer.

Hopefully that made sense.

We are using the 80MHz internal clock on all channels.  I guess if the internal clock can not have a prescaler, then the channel could be explicitly told to capture 2 or 8 times as many samples.  Or maybe may idea of a prescaler is just all wrong.

[Kevin_Price]

Not quite sure what the overall big picture is, but there are a variety of approaches that are probably in the neighborhood of what you need.  Sounds like you've got sensors that emit a single pulse per gear tooth, right?  Will testing only take place during continuous motion in one direction?   More comments:

1. In period measurement, it will be the tooth sensor signals that act as a kind of external sampling clock.  They are probably not eligible to be "prescaled" directly.

2. With an 8:1 ratio, the faster gear produces period samples at 8x the rate of the slower gear.  If you want to collect for the same amount of time on both gears, simply size your finite buffer or your read requests to account for the factor of 8.  You mentioned this near the end of your last post, and it is definitely a viable option.  In fact, I'd recommend it over any attempts at prescaling.

3. If you sometimes measure non-integer ratios, you'll have to be just a little more careful with the approach.

4. What I'd probably do:

A. Configure both counters to start on the same digital "Arm Start" trigger, available only in the DAQmx Trigger property node.

B. Collect all period measurement data from each counter into a single array.  For fairly short test durations, you may be able to simply use Finite Sampling and read all the data once at the end of the test. 

C. Ignore / Delete the very first period measurement.  It measures the time from when the counter was armed with the trigger until the next tooth is sensed.  In most cases, this interval will be a random fraction of a period, and is best simply discarded.

D. Create "timestamp" arrays that correspond to the periods.  Timestamps are just the cumulative sum of the periods.  Also, convert the periods to frequencies using the 1/x node.

-Kevin P.

[MikeGI]

Hi Kevin,

That sounds great, thanks.  That is pretty much what I've been doing so far.  I agree with you in maunally collecting more samples in a faster channel to match up the time.  It will involve a little more coding but in the end I think it will be more efficient.

Thanks for clearing everything up.

-Mike

[MikeGI]

Hi Kevin,

I had a talk with my coworker and we realized our understanding of the prescaler was wrong.  Our old Legacy card was able to place a divide ratio on the counter gate signal, which is what we want to achieve with the 6602.  The prescaler, though, places the divide ratio on the counter source signal, correct?  Is there a way to place a divide ratio on the counter gate signal?

Thanks

Mike

Message Edited by MikeGI on 08-02-2007 09:26 AM

[Kevin_Price]

Well, yes and no.  Kinda like I described earlier, there's a way to get a prescaling-like effect by using an additional counter to perform frequency division.  You'd measure periods of of that divide-down counter and could choose any integer divisor >= 4.

I would only see this as a particular advantage if the raw pulse rate were quite high, like at least high 10's of kHz.  Otherwise, you're just discarding information.

-Kevin P.