DC motor at very slow precise "clockwork" speed

Hi, this is something that comes up on the forums from time to time, with things like solar tracking and clock mechanisms etc.

It's a system using a cheap common PIC microcontroller to run any DC motor at a very precise speed, including error correction if the motor is bumped forward or backward etc.

**broken link removed**

It requires that the DC motor has an encoder fitted (a standard quadrature encoder), or in my case I just pulled an encoder disc from an old Microsoft mouse and glued that to the motor. (Motors with encoders already fitted are commonly available on ebay and from hobby robot suppliers like Sparkfun and Pololu etc.)

**broken link removed**

As you can see the circuit required is very simple with practically no parts, just enough to get the encoder working (3 resistors) and something to drive the motor with PWM (a transistor and a diode).

The "precise stuff" is all done in software using a Bresenham math system to make a precise xtal-locked reference frequency and a simple algorithm so the motor must maintain the same average speed as the reference frequency (and it auto-corrects any short term speed errors).

Like any good clock system it can be tweaked with one number to set the motor speed, in very fine adjustment steps.

You can set the DC motor to exactly 1 rev per second, and it will keep clock accuracy for weeks or months afterward.

This is a viable alternative to using stepper motors for clock type applications, and will run much quieter, smoother and many times less energy consumption than a stepper motor, and no motor driver IC's are required.

The whole project is here, with C source code supplied;
https://www.romanblack.com/onesec/DCmotor_xtal.htm

Hi Roman,


Interesting circuit and setup.

What are the sensors detecting, the gear teeth? It's a little hard to see here.

Im not sure what your long term accuracy goal was for this project and im sure it's pretty good, but for 'clockwork' accuracy long term a better frequency reference would be required as a regular crystal can easily develop several seconds inaccuracy over one day so the 'clock' would have to be reset maybe once per week. Alternately, a true clock reference generator could be added and sampled at regular intervals to adjust the crystal 'clock' to be quite accurate over some months maybe as long as a year.

Hi MrAl, the sensor I pulled from from an old mouse and is a standard quadrature output. The IR LED beam is interrupted by the teeth and slots, and on the other side of the disc there is a dual photodiode so it produces two square waves which are 90 degrees out of phase when the disc turns.

Re the crystal, it's as accurate for clock apps as any other type of digital clock someone might make with a PIC or AVR, so it would have initial accuracy of the normal xtal variation of 10-80 PPM (Parts Per Million) ie as accurate as many cheap household clocks.

One of the good points of my software is that the timing is set with a large constant number whose value is in the millions, so that constant can be tweaked faster or slower in extremely fine steps. So that means even if the xtal is slightly off, you can still adjust it compared to any good reference clock to be extremely accurate.

Nice.. I can see the point here. Motor speed control is nothing new, but slow speeds are difficult. Can't get much torque though at low speeds.
You could time the width of the pulses from the encoder. You would get more accurate speed info at higher sample rate. Just an idea. Counting pulses over time is dead-accurate (depending how accurate your clock is), but if more "dynamic" control is needed then timing the pulse width could work.

Mr RB said:

Hi MrAl, the sensor I pulled from from an old mouse and is a standard quadrature output. The IR LED beam is interrupted by the teeth and slots, and on the other side of the disc there is a dual photodiode so it produces two square waves which are 90 degrees out of phase when the disc turns.

Re the crystal, it's as accurate for clock apps as any other type of digital clock someone might make with a PIC or AVR, so it would have initial accuracy of the normal xtal variation of 10-80 PPM (Parts Per Million) ie as accurate as many cheap household clocks.

One of the good points of my software is that the timing is set with a large constant number whose value is in the millions, so that constant can be tweaked faster or slower in extremely fine steps. So that means even if the xtal is slightly off, you can still adjust it compared to any good reference clock to be extremely accurate.

Click to expand...

Hi Roman,


I wasnt implying that it would not work, just that crystals dont work as well as they should in clocks because of drift, bot basic accuracy or adjustment. But what i was saying that by adding a real time clock chip it would actually improve the design and also remove the need to adjust (real time clocks have built in auto drift adjustment). But that might be an overkill anyway

What i would like to see is the output of the detector. So it has two outputs that are 90 degrees out of phase. So lets say we have output A and output B. Then if output A comes before output B (high) that means it is rotating in (say) clockwise, and if B comes before A then it is rotating counter clockwise ?
Any chance seeing a waveform picture if you get a chance?

MrAl said:

What i would like to see is the output of the detector. So it has two outputs that are 90 degrees out of phase. So lets say we have output A and output B. Then if output A comes before output B (high) that means it is rotating in (say) clockwise, and if B comes before A then it is rotating counter clockwise ?
Any chance seeing a waveform picture if you get a chance?

Click to expand...

I think the website linked has screenshots of those waveforms.

Nice post RB....
Your posts and website are always interesting.

misterT said:

I think the website linked has screenshots of those waveforms.

Click to expand...

Hi,

Yes thanks, nice pics

Top Notch project and documentation RB.

Thanks for the nice words guys.

misterT said:

... Can't get much torque though at low speeds.

Click to expand...

Actually it's pretty good for that! My test setup used prop gain of 10, so for every pulse behind that the motor lags, PWM is turned up 10%. By the time the motor rotation was 10 pulses behind (only 25 degrees behind in rotation!) it's running at full 100% PWM and has the full torque the motor can produce.

misterT said:

...
You could time the width of the pulses from the encoder. You would get more accurate speed info at higher sample rate. Just an idea. Counting pulses over time is dead-accurate (depending how accurate your clock is), but if more "dynamic" control is needed then timing the pulse width could work.

Click to expand...

Yep, that's a good point. I've done PID systems etc where stability was first, but in this case it's a digital "I" (integral) system, so the highest priority is being "dead-accurate" over time as you say. Then there's a secondary "P" (proportional) factor which gives a good enough stability for normal load variations.

In fault load situations the stability goes out the window BUT it will fully recover later to the exact position and time keeping. For instance you can stop the motor for a second and when you let the shaft go it will spin up fast to get back to where it should have been and then slow to exact speed again. Kind of the opposite of PID because the stability is very secondary, while the timekeeping it of top priority.

Hi Roman,


Yes nice pics and good detail on the web site. I missed the link in the thread but i see it now

Thanks MrAl, I guessed you had missed the link before.

Hello again MrRB,


Yeah i think it is because of my monitor colors. It's a decent size monitor but the colors are too washed out i think and if i adjust them for text then pictures dont look right. I have been looking around for another one but havent gotten around to picking anything up yet. The standards on monitors makes it impossible to compare.