incremental encoder selection?

[seyyah]

I have a motor control project. In this project, i need to measure the speed. To measure the speed, i planned to use a 100ppr incremental encoder. With the ucontroller's ability it can count 400 pulses per revolution.(It counts decreasing and increasing edges of phase A and phase B) This means that, in order to measure the speed with 1 rpm resolution, i have to wait at least 150ms. This is a very long time i think, for a speed feedback in a control loop. If we decrease resolution, obtaining the speed takes less time. But resolution isn't good enough for those cases. I tried to implement a stepped algorithm for obtaining speed. (From low resolution to high resolution, step by step) It sometimes gives good results but sometimes the calculated speed deviates from the real speed largely for a very little time (like a spike). I'm hearing that 100ppr suffices for most cases in a commercial drive. If so, how should be the way that i follow? Or what kind of technique should i use to obtain the speed? Please, help me.

 

[IanP]

If 100ppr in 400ppr configuration is still not enough then the only solution is to replace 100ppr encoder with 1000ppr (150ms/10=15ms) or even 2500ppr (the same price; 150ms/25=6ms, and that would be more than acceptable, I guess) ..
And I wouldn't say that 100ppr encoder is the commercial standard; more often you can find 1000ppr units ..
Regards,
IanP

 

[artem]

what is your motor's rpm range and how do you read encoder ? By polling its output via mcu?

 

[echo47]

If your encoder has perfect quality, and your timer has excellent resolution, then it would be sufficient to measure the period between two consecutive pulses. However, your encoder probably has noise and non-uniform spacing, so you will want to measure the period of serveral pulses. How many depends on encoder quality. Also, if your timer has poor resolution, then you will need to further increase the number of pulses to average out the quantization error, or use a better timer.

 

[seyyah]

Motor will run upto 3000rpm. I can choose higher ppr encoders but i want to know what my bottom limit is. (I know i must try it, but approximately. My system doesn't need very very high dynamic response). So it seems that there is no other technique. The most logical way is measuring the time between consequtive edges and calculate the speed from this info and if resolution doesn't enoguh increasing the resolution of the encoder.

 

[artem]

That means 1 roate per 20 msec and one encoder pulse per 200 usec (if revolution equ to 1 rotate) . What you need is timer to measure duration between 2 consequititve pulses from encoder and that is quite achievable either with qlue logic or CPLD . With glue logic you need counters and latches , so it starts counting pulses from encoder at each pulse from encoder and writes data to latch at second one. To increase accuracy you can take weighted value of few consequitive measurements.
That could possibly help to fight jitter in encoder otput signal (if there is any). CPLD will be of course better.

You need to supply about 20 MHz clock to counter input - that is no problem to conventional logic.

 

[echo47]

Encoder pulse jitter is a key factor, and it probably varies with rpm.

Let's try one example calculation to determine the minimum number of encoder pulses to count, and the minimum timer clock frequency:

Speed = 3000 rpm.
Encoder = 100 ppr.
Pulse period = (60 sec/min) / (3000 rpm) / (100 ppr) = 200 us/pulse.
Pulse jitter = 5 us. **** this is just a wild guess - you must research it ****
Required resolution = 1 rpm.

Minimum measurement duration = (3000 rpm) / (1 rpm) * (5 us) / (200 us/pulse) = 75 pulses.
If you get a non-integer, round it upwards.

Minimum timer clock = (3000 rpm) / (1 rpm) / (75 pulses) / (200 us/pulse) = 200 kHz.

 

[artem]

echo47, one question - is 2,5 jitter usual for encoder?

 

[echo47]

No, I pulled that jitter value out of thin air. Your encoder may be much better or much worse, and it probably varies with RPM.

 

[artem]

Yes , it looks like jitter could be worse than you mentioned, so the method i offer to measure rpm by one pulse could be error prone .
As you said - worst condition measurement must be setup at test plant to estimate maximum expectable jitter and then deal with it accordingly .