Optical encoder selection for a motor control project.

[abfer]

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 enough for those cases. I try to implement a stepped algorithm for obtaining speed. (From low resolution to high resolution) 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. 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.

 

[itsmoked]

Not sure of your situation but what about a tachometer generator. That gives instantaneous speed whenever you read it, since it is a straight speed to voltage transducer. Then at whatever rate you want you can read the analog value and know the speed.

If you need position information then that's different and you will need A/B encoders.

You have never said what speed you are trying to measure...

 

[denison]

I agree with "itsmoked". For speed and direction, a tach would be the way to go (though a resolver needs to be used in some circumstances, like a tach and encoder combined). The only time I've ever seen an encoder used for something to do with speed was with displaying RPM's and it used the "Z" (or reference) pulse. Once per revolution.

 

[Skogsgurra]

Going to a tacho generator is against current trends and should be avoided. There is maintenance involved. The tacho generator also needs an A/D converter with at least same resulution and precision as you need in motor speed.

If you have a high resolution timer in your system, you can implement reciprocal speed measurement. It counts time between edges instead of counting number of pulses/time unit. Reciprocal speed measurement is what is used in drives that have high precision and fast response. It can be adapted to various needs and can be made "constant precision/constant period" by adjusting number of edges to actual speed. I have written about encoders in general in

http://www.gke.org/rapporter/Glossary for the encoder world.pdf

There is also a presentation of the SKF Sensor Bearing (which is an encoder in a ball bearing) on

http://www.gke.org/presentationer/SKF Sensor Bearing 1a.pdf

Slide no 41 shows how Siemens does it - at least what the relation between PPR and speed range is.



Gunnar Englund

http://www.gke.org

 

[sreid]

You have rediscovered the classic sampled servo system "Velocity Estimation" problem. If you wait long enough to capture the number of pulses required for resolution, you introduce a delay in the feedback that limits how much gain you can use thus limiting the servo stiffness. Furthermore, the slower the RPM, the worse the +/- one encoder count problem becomes.

High resolution encoders are relatively inexpensive today (see BEI, Heidenhain, EPC, etc.) 1000-2000 line encoders usually cost no more than 100 line encoders in the same Model Number. I routinely use 5000 line uninterpolated encoders and 25,000 line interpolated units.

The best way to do velocity estimation is called "Delta P/Delta T." There are two counters, one to count encoder pulses and the other to count time with a high frequency clock (usually meaning two counter/timer registers in a processor). You start the timmer on an encoder edge and a after a fixed delay (to accumulate pulses in the "Position Register), you wait for the next encoder edge to stop the timer. Then calculate Delta P/Delta T. The Velocity Estimation accuracy is now determined by the timer clock frequency.

 

[abfer]

Ok i got it, i think. I don't think to use tacho. My speed can go up to 3000rpm. As i've said i don't count pulses, i count edges. I was using fixed time intervals and calculating the speed by counting edges. I'm constructing the speed from 256 rpm resolution (~0.59ms) to 1 rpm resolution (150ms). With this method and with real values estimating speed is faster and since motor can't change it's speed very fast it gives "not bad" results. It oscillates a bit around the actual speed but low. I should try it in a complete system to be sure whether it works or not. But your offer, "Delta P/Delta T.", technique senses more. As you said more ppr encoders doesn't differ so much. But i want to know what the bottom limit is. As i don't need a very high dynamic response system, may be 100ppr also suffices. Thanks to all.

 

[cswilson]

sreid: I'm a little confused about exactly what you are proposing. I'm with skogsgurra that the simplest improvement for a velocity application would be reciprocal time between edges. In that scheme, each edge of the encoder signal would latch the present value of a high-frequency timer and clear the timer. At the control interval, the most recent latched timer value would itself be latched into a register that can be read by the processor (or just read, if you don't want to be that fancy). This value is inversely proportional to the velocity, which can be computed mathematically, or through a look-up table (the last generation of HP vector pen plotters used a lookup table, but that was back in the 1980s).

This simple method will have very little phase lag from delays and very little quantization noise, even with a 100ppr encoder. At 3000 rpm (50 rps, 5000 lines/sec, 20000 edges/sec) a 10 MHz timer would be accurate to one part in 5000 -- less than 1 rpm, with a delay of less than 0.1 msec in the measurement. At lower speeds, the resolution is proportionally better, but the delay is proportionally worse (but still very small for this type of application). If it's a pure velocity-control application, you wouldn't even need a counter, and you might be better off without the "times-4" decoding that generates a count on every edge.

 

[abfer]

I think they say basically the same thing. Start the timer on one edge or pulse, stop at the next edge or pulse. Calculate the speed from the time passed. I wonder about near zero speed problem. Do we need high resolution encoder to solve it? or are there any other techniques?

 

[cswilson]

There is a whole range of techniques depending on the amount of sophistication you need and are willing to create. Most are hybrids of the techniques that skogsgurra and sreid suggested. For the fairly loose velocity requirements that it seems you need, I was suggesting the simplest approach that I thought would work. The nice thing about timer-based approaches is that they actually have higher resolution at low speeds, unlike "delta-P" techniques. However, you do need to handle zero-velocity cases with special logic.

Possibly you may want to treat this as a sort of positioning application with proportional plus derivative control. At your control intervals, you latch both your edge-counter value, and your most recent time-between-edges value. You compare your counter value to your command-counter value that you are incrementing by your desired speed (keep lots of fractional resolution in your command counter value to avoid integration errors). Multiply this difference by a proportional-gain term to compute a corrective output term.

Next, take your actual velocity value as derived from your timer and subtract it from your command velocity (which is just your increment to command position). You will need a scaling term to make these two values have the same units. Multiply the difference by a derivative gain term and add the result to the proportional corrective term.

By closing a position loop as well as a velocity loop, you are also guaranteeing zero steady-state error in velocity.

Curt Wilson

 

[sreid]

Curt,

Good to see you here. You are, of course, exactly correct in what you say. In my old age, I like to teach and I believe that Delta P/Delta T velocity estimation is often not mentioned in most control classes. The hardware to do it is implemented in both TI and AD Motion Control DSP products. And as you well know, having a clean position derivative (velocity estimation) is key to feedback control.

On encoder resolution I (roughly) quote you; "My old Professors would be appalled, but sometimes the solution is to throw resolution and speed at the problem."