Encoder on a low speed motor

[Taylor.Kendall]

I have a motor which will be used in a low speed application about 45% of the time, on the order of 10-20 RPM.  And the rest of the time it will be used at around 1500 rpm. 

The process varrible is a 3600 tick/rev A/-A B/-B and Z/-Z incremental encoder (BEI HS35). 

I am currently having problems getting accurate speed reading at low RPM, because sometimes with low speeds the sampling rate will be faster than the rate at whcih the pulses come in from the encoder.  For example if you sample 1000 times a second but only have 600 ticks per second. 

  I am looking at doing some simple things like impliment a rolling average filter or some such to get it to a more accurate reading. 

Anybody have a beeter idea? 

This is running on a RT desktop with a PCIe-6343 on LV2009. 

[Henrik_Volkers]

Do you use the quad decoder functionality of your card ? Didn't dig into the spec, but usually you get 4 times the resolution with quad decoders (counting each edge).

You should get a 1/240 RPM resolution while reading once a second...

[Henrik_Volkers]

Your resolution in RPM is 60/(<TicksRev>*dt) , dt is the time between your to counter readings

for 3600 ticks/rev and a resolution about 0.05 RPM you need a dt of 333ms

=> Your Samplerate is 1kSPS so buffer 333 values and calc the RPM with that value

For a better resolution with higher dynamic in the low RPM region you can wire one output also to the timer/counter input and measure the pulselength ...

[SKauth]

Hi tsksesa,

it sounds to me like you used the wrong input configuration. Do I get you right that you are actively polling a DI for encoder pulses and count samples from edge to edge to compute speed? This way you always have to keep in mind that you always have to sample much faster than your ticks come. But actually in this case you would have trouble at high speeds.

If it is the case that you query an encoder counter value with a fixed loop rate, then it is obvious that you get incorrect speed values at low speed. This is because you always have to calculate an error of one bit, and at low speed, respectively low numer of counts, the relative error is high.

A solution I could imagine would be using one method for low speed and switching to the other one above a certain speed value. But anyway you should use a counter and not a simple DI to be sure you don't miss edges.

Regards,

Simo