The mathematical and computational aspects of stepper motor control turn out to be quite interesting. The goal is to write an efficient microcontroller algorithm that can issue step signals to 3 (or more) motors simultaneously so that the drill bit follows a pre-defined path with a desired, possibly changing velocity profile.

The opponents are the limited microcontroller processing power, and complex modeling dynamics of real-world stepper motors.

I've started on my own home-brew version, but for now, a bit of an introductory summary with pointer for more reading...

**Stepper Motor Modeling**
At level one, we are interested in modeling stepper motor behaviour. A very nice introduction to this topic was published by

D W Jones - Control of Stepping Motors - A Tutorial. It's an all-round introduction to stepper motors and discusses stepper motor types, stepper motor physics, basic control circuits, current limiting circuits, H-bridges and decay modes, micro-stepping and torque issues, and real-time control algorithms. The algorithms are a bit theoretical, but nevertheless, they provide a sound foundation to the topic.

Some more mathematical approaches are listed below - perfect for your lonely nights...

Without making you wade through pages of maths, just imagine a stepper motor like a damped pendulum that is subject to viscous friction. A model should take into account physical behaviour (inertia, friction, etc) as well as electrical characteristics (LR-circuitry, etc).

Interestingly, the actual approximation algorithms (discussed below) effectively ignore stepper motor modeling complexities and simply assert that three values, namely maximum acceleration, maximum deceleration, and maximum velocity, are all that are needed to build a working algorithm. They probably know why!

The proposed algorithms I've found are based on the concept of constant acceleration. I'd be interested to know why "constant acceleration" seems the accepted norm as the starting point, other than for mathematical elegance and simplicity? My car does not have constant acceleration. Every time I reach 150km/h in my local suburb, a car with flashing blue lights gets in the way and slows me down.

Maybe I should put my z-axis through some load testing to see what type of maximum acceleration profile works best, just to check against the maths.

For good measure, some more maths of my own...

*It was raining outside...*

**The G251 Controller**
The Gecko G251 controller sits between the Arduino and the stepper. Modeling stepper motor physical behaviour and then creating an acceleration algorithm based on the model will be difficult, as the G251 itself applies optimisation and I don't know its internal algorithm. For example, it smoothly changes from micro-stepping to full-stepping at higher speeds and also avoids mid-band resonance. This reinforces the suggested approach of "all you need to consider is maximum acceleration to get your stepper model".

**Acceleration Algorithms**
The microcontroller algorithm needs to issue a pulse train to the stepper/controller. The time between each pulse can be calculated from the desired velocity/acceleration profile. To cut to the chase, for constant acceleration, you need to calculate square-roots, which isn't the kind of thing a microcontroller wants to do 50,000 times per second.

A few good approximation schemes to get you started can be found here:

- Atmel - Linear Speed Control of Stepper Motors (pdf): Outlines acceleration algorithm, including Taylor Series approximation. Also touches on resonant frequency issues.
- D Austin - Generate stepper-motor speed profiles in real time: A very detailed derivation of Taylor Series approximation and enhancements. Probably the best article of the bunch, but it requires division, which is an expensive instruction for an Arduino (in the order of 100 clock cycles).
- Aryeh Eiderman detailed the Leib Ramp (pdf), which is an approximation that does not require divisions. Probably the fastest version. Notably, he makes a possibly unintended (incorrect but workable and simplifying) assumption in equation 7 where he calculates the "real time delay" using the instantaneous velocity "vi' instead of the integral of velocity over the time period in question. Someone tell me if I'm wrong here.
- There is also a compact implementation proposal by Atmel: Atmel AVR360: Step Motor Controller (pdf). They describe a 10-byte interrupt service routine to drive a stepper. Not exactly applicable to my needs, but interesting nevertheless.

A number of semi-related topics can be found in this list of articles:

Discover Circuits - Motor Control Circuits.

**Multi-Dimensional (2D, 3D, and beyond)**
Once you've figured out how to drive a single stepper to its edge, you are left with the challenge to orchestrate all 3 of them to work together.

The guys at RepRap (

forum,

site) seem to have solved the problem by using a linear

Bresenham algorithm and a single "interrupt" (discussed in

this post). That means, they track the fastest axis and pull along the slower axes.

I think there is a flaw in that logic. Consider the extreme example of a path for a line with an dx:dy ratio of 1.5:1, for example from (0,0) to (15,10). The Bresenham algorithm steps x nicely and regularly by one step for each interrupt (assume constant velocity throughout). However, y is stepped as (0,1,1,2,3,3,4,5,5,6,7,7,8,9,9,10). This means y velocity changes by 50% up/down every other step. I guess it is workable because the stepper just smoothes over these bumps, but I'm not sure about all-over efficiency or issues with resonance. I'd be happy to stand corrected on this one.

*Bresenham example: y-movement is not smooth.*

So where to go from here ?

Firstly, I'm still interested in first-principles and would like to see if I can squeeze some nice maths & approximating algorithm out of a simplified physical stepper motor model, but I'm also aware that time is moving.

Second, none of the above methods suit my multi-dimensional requirements. I can either keep browsing, or continue my own path to enlightenment. DIY is much more fun. My constraints are going to be a challenge. Since the G251 is fixed at 10 microsteps, I will have to be able to run my steppers at around 50,000 steps per second. The Arduino clocks at 16Mhz, so that's only 320 clock cycles (and fewer instructions) per step. And that's for one axis only. I may have to accept some compromises, for example, not all axes might run at full throttle at the same time.

But only time and maths will tell...

Speaking of maths: I discovered that "router project progress" is indirectly proportional to "amount of sunshine". But you knew that already...