Precise DC motor control with optical encoder

I am working on a CNC build from old printer parts. I want to run it from dc motors with optical encoders build in. But I have to find a way to do this more accurate then looking for a state change and counting a step. Does anyone know a better way?

need more information on your encoders. if they have multiple rings. then you have multiple state changes and can determine direction.

Also, most printers have much more accuracy than you need on a CNC machine. one option is to get encoder wheels from a scanner.

if you make your own wheels, you can just add a second sensor to the wheel, shifted over 1/2 step and double your resolution.

bobbiy: I am working on a CNC build from old printer parts. I want to run it from dc motors with optical encoders build in. But I have to find a way to do this more accurate then looking for a state change and counting a step. Does anyone know a better way?

More accurate then looking for a state change and counting a step? Counting every State Change is the most accurate way.

When you say "... looking for a state change ...", do mean Polling vs Interrupt Driven? Polling: "looks for" a state change Interrupt Driven: "reacts to" a state change.

mrsummitville: More accurate then looking for a state change and counting a step? Counting every State Change is the most accurate way.

When you say "... looking for a state change ...", do mean Polling vs Interrupt Driven? Polling: "looks for" a state change Interrupt Driven: "reacts to" a state change.

I am polling by storing the last value and if old value != new value I count a step. But by doing this it work fine but after a while It gets inaccurate and shows a small error. If I make it loop back and forward 100 steps it will eventually shift a bit.

bobbiy: If I make it loop back and forward 100 steps it will eventually shift a bit.

Then you're doing something wrong.

If these are quadrature encoders (very likely) then you should be able to track each transition.

Since you're polling, it sounds like you're not polling frequently enough. You probably need to use interrupts to catch all the transitions with an Arduino.

As far as I know the control system in a printer can tell very precisely where the print head is (so it knows to squirt a drop of ink) but it does not need to and cannot stop the print head at a specifc location.

I think of it like the paperboy in American movies throwing the paper at each door as he cycles past. If he stopped he would fall off his bicycle.

But a CNC device has to be stopped at a precise step so it can move backwards or just hold position while something else moves. Gettingt that to happen with a DC motor is not trivial.

...R

Robin2: Gettingt that to happen with a DC motor is not trivial.

Agreed, not trivial, but absolutely possible.

I noticed in the last few printers I've taken about they use DC motors with super fine quadrature encoder disks (they look grey).

Moving a DC motor with quadrature encoders to an exact position is a common robotics task. Though I completely agree, it's not a trivial task.

DuaneDegn: Moving a DC motor with quadrature encoders to an exact position is a common robotics task. Though I completely agree, it's not a trivial task.

May I ask a follow-up question. Am I correct in thinking a DC motor would have to oscillate slightly between two positions rather than stay at a fixed position like a stepper motor?

If so, I wonder how much variation in position is necessary.

...R

Hi, For precise motor motion and postion you need what is called a resolver on the motor shaft.

http://www.amci.com/tutorials/tutorials-what-is-resolver.asp

Tom.... :)

Robin2: Am I correct in thinking a DC motor would have to oscillate slightly between two positions rather than stay at a fixed position like a stepper motor?

If so, I wonder how much variation in position is necessary.

The examples I've thinking of (controlling a robot's position) the motor doesn't need to oscillate. The control algorithm would slow the motor as the target pulse count approaches and remove power to the motor once the exact count is reached.

Of course the behaviour of the motor will depend on how well the control algorithm can reach this target count. I'm sure it's much harder to maintain a set encoder count if there's a force pushing against the motor's final position. If the motor has to fight some force to maintain it's position, then I'm sure there will be some oscillation.

There will be a trade off between how fast one can decelerate to the final position, and how precisely one wants the final encoder count. I think there would also be a trade off between deceleration and if it's acceptable to oscillate a bit to find the final position.

I personally haven't attempted using motors with quadrature encoders with an Arduino yet. My quadrature encoder experiments have been done using the Propeller microcontroller.

One experiment I found interesting was how using different h-bridges affected my ability to precisely control the motors. I could get my robot to stop at the exact encoder count when I used Parallax's HB-25 motor controllers but when I used a pair of MC33926 chips, my algorithm had a hard time getting the motors to the exact encoder count. My algorithm caused the motors to oscillate around the target count. I ended up allowing the count to be off by one count to keep the motor from oscillating. I'm sure this one tick error could be eliminated by moving the control algorithm to assembly (or possibly by improving on the algorithm I wrote).

@DuaneDegn, Thank you.

...R