Help developing rpm calculation from encoder pulses

Question

I have having a bit of difficulty calculating rpm of a motor using feedback from an encoder. The encoder datasheet is attached here: Encoder datasheet.

The encoder has two channels at 1000 PPR, so 4000 PPR that I can count with my FPGA, as I am counting both the rising and falling edges. The max motor speed is 4500 rpm.

I have synchronized these pulse edges with the FPGA 100MHZ clock and I generate a pulse on each rising and falling edge that lasts for one 100 MHz clock cycle. I then have a counter that increments by one on the falling edge of the 100 MHz clock if an edge pulse has been generated. This counter value is clocked into a register every 100 ms which is the count value from the encoder. I then display this count value on a seven segment display to test it.

I have inputted a 20 kHz square wave into the FPGA to simulate one channel of the encoder and the display reads a count value of 4000 on the display. So the hardware on the FPGA end is working perfect, as the counts per 100 ms from 20 kHz is 4000.

I am unsure how I can scale this count value from the encoder mathematically into an RPM value that I can display? At 4000 rpm, the encoder inputs will be 66.6 kHz each. So for around 4000 rpm, the count value per 100 ms will be 26640. I tried to use the following algorithm:

$$ RPM = \frac {(CountValue per 100 ms) (600)} {EncoderPPR} , $$

But to remove the division by 4000 and to shift right to divide by 4095:

$$ RPM = \frac {(CountValue per 100 ms) (600\frac{4095}{EncoderPPR}) } {4095} , $$

So this leaves:

$$ RPM = \frac {(CountValue per 100 ms) (614.25)} {4095} , $$

With the encoder my display is not displaying 4000 rpm so would like to know if anyone can spot a mistake in my calculations.

EDIT

So I actually changed the shift value from 12 (4095) to 14 (16383) and the rpm is not being displayed correctly as far as I know. I have a digital tachometer to measure the speed of the motor shaft as they fluctuate within 2 rpm of each other. I am guessing the extra to shift bits was because 614.25 has two places after the decimal point?

Answer 1

There are two methods: period and frequency measurement. You have chosen the frequency method. My old books say:

$$f_x = \dfrac{N}{T_M} \pm \dfrac{1}{T_M}$$

Where \$T_M\$ is a measuremnt period (0.1s in your case) and \$N\$ is the number of counts.

$$f_x = \dfrac{RPM_x}{60s}\cdot 4000\ inc$$

$$RPM = \dfrac{60}{4000}\lbrace \dfrac{N}{0.1} \pm \dfrac{1}{0.1} \rbrace$$

$$RPM = 0.15\cdot N \pm 0.15$$

check:

26640*0.15 = 3966, actually it should be 26666 counts to mach my formula.

EDIT:

At 4000 RPM the frequency is 4000*4000/60= 266,666 kHz, so within 1/10s you should count 26666 pulses. Multiply with 0.15 and you get 3999.9 RPM. Next time you will count 26667 pulses that gives 4000.05 RPM, the difference is exactly 0.15 RPM which is the measurement error.

EDIT2:

This is a processor I have developed on the FPGA and the ALU can only divide by powers of 2 so yeah I am not able to divide by 20

That would be easily solved if you would be using an encoder with PPR with power of 2, that's why they do exist. For example 1024 PPR, then you could change the measurement interval so you could get 512/4096. Still you can change the measurement interval to 0.12s then you get:

$$RPM = \dfrac{60}{4000}\lbrace \dfrac{N}{0.12} \pm \dfrac{1}{0.12} \rbrace$$

$$RPM = 0.125\cdot N \pm 0.125$$

Et voila: $$RPM = \dfrac{N}{8} \pm 0.125$$

Set to 120ms and shift right 3 times.