High speed velocity measure with quadrature encoder and NI 9401 on cDaq

[DsX]

Greetings,

We are using a quadrature encoder with 360 pulses/rev on both tracks (track A and B), and no Z track to measure motor velocity during startup. For data acquisition we are using an NI 9401 in a cDaq 9178 chassis and a pc with LabVIEW. The problem is that the startup period is relatively short (less than 1 second), during which we must measure velocity as accurately as possible. The velocity range is from 0 to 10000 rpm.

What kind of measurement method would you recomend.

Here are some mehods we have already tried:

- Measurement with DAQmx CIFreq --> High frequency with 2 counters: sufficient speed of measurement but with very big error (+-166rpm),

- DAQmx CIFreq --> Large range with 2 counters: good velocity data but slower measurement,

- DAQmx CICntEdges (separate counting of both tracks, conversion to speed): very inconsistent velocity data.

Thank you in advance for your help.

Matej

[Kevin_Price · Accepted solution]

I would definitely suggest a 4th option -- the one called low freq measurement with 1 counter.  (Frankly, I've never been

fond of the name because it's useful for much higher freqs than what I expect most people consider "low freq".)   This

is the method I pretty much *always* use for counter frequency measurements.  It works really well for capturing transient

speed variations.

At 10000 rpm and 360 cycles/rev, you're looking at a maximum freq of 60 kHz.  The 1 counter frequency measurement mode

will count 80 MHz internal clock edges per encoder cycle, so you'll be getting over 1000 counts per measurement.  The point

being that the 1 count of quantization error you can expect will only mean < 0.1%

Further, you could average across, say, 10 samples to give you even better precision and you'd still be capturing data at a

rate well above the likely bandwidth of your mechanical system.  (The averaging would just clean up jitter/noise and wouldn't

hide any real mechanical response characteristics.)

-Kevin P

[DsX]

Thank you for your quick response,

I was already out of office on Friday so I've implemented the solution today and it seems to work fine with my development system.

Unfortunately I couldn't test the solution on our test platform due to work being done on it.

I do have another question though;

I've used DAQmx Timing (Implicit) with this method. Does this translate into acquisition being hardware timed or is that up to the acquisition loop?

I've attached my vi.

Best regards

Matej

[Kevin_Price]

The acquisition is hardware timed.  "Implicit" means that the sample timing is not something you can predefine because it is implicitly defined by the frequency of the incoming signal.  Each captured sample is still a hardware-based frequency measurement based on the board's internal clock.

You've put a software loop around the acquisition, so the loop itself will be software-timed.  Each iteration you'll read whatever # of new samples have come in since your previous read, and you can expect a pretty regular loop rate.

-Kevin P