High Level Real-Time Control of Stepping Motors

• Introduction
• - Model Variables
• - Models

• Hardware Solutions
• - Practical Examples

• Software Solutions
• - Simple Practical Examples
• - An Object Oriented Design

Introduction

The key question to be answered by the high-level control system for a stepping motor is, when should the next step be taken? While this almost always depends on the application, the similarities between different applicatons are sufficient to justify the development of fairly complex general purpose stepping motor controllers.

Stepping motor control may be based on open loop or closed loop models. We are primarily interested in open loop models, because this is where stepping motors excel, but we will treat closed loop models briefly because they are somewhat simpler. Figure z.1 illustrates an extreme example:

Figure z.1 

If the shaft encoder is rotated into a position where the output of the shaft encoder translates to a control vector that holds the motor shaft in its initial position, the motor shaft will not rotate of itself, and if the motor shaft is rotated by force, it will stay wherever it is left. We will refer to this position of the shaft encoder relative to the motor as the neutral position.

If the shaft encoder is rotated one step clockwise (or counterclockwise) from the neutral position, the control vector output by the shaft encoder will pull the rotor clockwise (or counterclockwise). As the rotor turns, the shaft encoder will change the control vector so that the rotor is always trying to maintain a position one step clockwise (or counterclockwise) from where it is at the moment. The torque produced by this method will fall off with rotor speed, but this control system will always produce the maximum torque the motor is able to deliver at any speed.

In effect, with this one-step displacement, we have constructed a brushless DC motor from a stepping motor and a collection of off-the-shelf parts. In practice, this is rarely done, but there are numerous applications of stepping motors in closed-loop control systems that are based on this model, usually with a microprocessor included in the feedback loop between the shaft encoder and the motor controller.

In an open-loop control system, this feedback loop is broken, but at a high level, the basic principle remains quite similar, as illustrated in Figure z.2:

Figure z.2 

So long as the model is sufficiently accurate, the behavior of the motor controlled by this model will be the same as the behavior of the motor controlled by a closed loop system!

Model Variables

In the example given in Figure z.1, the only control variable offered is the angle of the shaft encoder relative to the motor. In effect, this controls the extent to which the equilibrium point of the motor's torque versus shaft angle curve leads or follows the current rotor position. In theory, any desired motor behavior can be elicited by adjusting this angle, but it is far more convenient to speak in terms of other variables:

-- The predicted shaft position (radians)
_target -- The target shaft position determined by the application
V = d/dt -- The predicted velocity (radians per second)
V_target -- The target velocity determined by the application
A = dV/dt -- The predicted acceleration (radians per second squared)
A_target -- The target acceleration, may be determined by the application

S -- step or microstep angle, in radians
µ -- moment of inertia of rotor and load
h -- the holding torque of the motor

Models

The simplest model that will do the job is almost always the best. For some applications, this means the model is so simple that it is hard to identify it as a model! For example, consider the case where the application demands a constant motor velocity:

A_target = 0
V_target = Constant

t_step = S / V_target

t_step -- time per step

repeat the following cycle forever:

wait t_step seconds and then
= + S
step( 1 )

A more interesting model is required if we want to maintain a constant acceleration. Obviously, we can't do this forever, but we'll use this model as a component in more complex models that require changes of velocity or position. In this case,

A_target = Constant

A_target < h / µ

= 1/2 A t²

' = 1/2 A t² + V t V' = A t + V

1/2 A t² + V t - S = 0
t = ( -V ± ( V² + 2 A S )^0.5 ) / A

t_step = ( -V + ( V² + 2 A S )^0.5 ) / A
V' = ( V² + 2 A S )^0.5

We can combine this model for acceleration with the model for constant speed running to make a motor controller that will seek V_target, assuming that an outside agent may change V_target at any time:

repeat the following cycle forever:

if V = V_target do the following:

wait S/V_target seconds and then
= + S
step( 1 )

otherwise, if V < V_target, accelerate as follows:

wait ( -V + (V² + 2 A_accelS)^0.5 ) / A_accel seconds and then
= + S
V = (V² + 2 A_accelS)^0.5
step( 1 )

otherwise, V > V_target, decelerate as follows:

wait ( -V + (V² + 2 A_decelS)^0.5 ) / A_decel seconds and then
= + S
V = (V² + 2 A_decelS)^0.5
step( 1 )

The second shortcoming of this program is simpler to correct: As written, there is an infinitesimal probability of the motor speed reaching the desired speed and staying there with V_target equal to V. Far more likely, what will happen is that V will oscillate around V_target, taking alternate accelerating and decelerating steps and never settling down at the desired running speed.

A quick and dirty solution to this latter problem is to add code to recognize when V passes V_target during acceleration or deceleration; when this occurs, V can be set to V_target. Formally, this is incorrect, but if the acceleration and deceleration rates are not too high and if there is sufficient damping in the system, this will work quite well.

In a frictionless system using sine-cosine microstepping at speeds below the cutoff speed for the motor, the available torque is effectively constant and we can use the full torque to accelerate or decelerate the motor, so the above control algorithm will work with

A_accel = A_decel = h / µ

A_accel = ( h - f ) / µ
A_decel = ( h + f ) / µ

f -- frictional torque

A_accel = ( ( h / 1.414 ) - f ) / µ
A_decel = ( ( h / 1.414 ) + f ) / µ

Note that it is not difficult to extend the above control model to account, at least approximately, for viscous friction and for the dropoff of torque as a function of speed. To do this, we merely modify the above formulas for A_accel and A_decel so that h and f are functions of V. Thus, instead of treating these as constants of the control algorithm, we must recompute the available acceleration at each step.

If our goal is to turn the motor smoothly from one set postion to another, we must first accelerate it, then perhaps coast at fixed speed for a while, then decelerate. The decision governing when to begin decelerating rests on a knowledg of the stopping distance from any particular velocity. Assuming that the available acceleration is constant over the relevant range of speeds, we can compute this from:

V = A_decel t
= 1/2 A_decel t²

t = V / A_decel

= 1/2 A_decel ( V / A_decel )² = V² / ( 2 A_decel )

moveto( _target )

-- a function of one argument

-- no value is returned

while V < V_target

and while < _target - V² / ( 2 A_decel ) repeat the following to accelerate

step( 1 )
wait ( -V + (V² + 2 A_accelS)^0.5 ) / A_accel seconds and then
= + S
V = (V² + 2 A_accelS)^0.5

V = V_target

while < _target - V² / ( 2 A_decel ) repeat the following to coast

step( 1 )
wait S/V_target seconds and then
= + S

while < _target repeat the following to decelerate

step( 1 )
wait ( -V + ( V² + 2 A_decelS )^0.5 ) / A_accel seconds and then
= + S
V = ( V² + 2 A_accelS )^0.5

V = 0

done, and _target are within a step of each other!

The control model only moves the motor one direction, it fails to plan in terms of the quantization of available stopping positions, and it doesn't account for the cyclic nature of . Nonetheless, it is a useful illustration. Note that we have used V_target as a limiting velocity in this code, but that this will only be relevant during long moves; for short moves, the motor will never reach this speed.

With the above, code, so long as the acceleration and deceleration rates are high enough to avoid dwelling for too long at resonant speeds, and so long as V_target is not too close to a resonant speed, a plot of rotor position versus time will show fairly clean moves, as illustrated in Figure z.3:

Figure z.3 

Hardware Solutions

Today, it is rare to find high-level stepping motor control done purely in hardware, and when it is done, it is usually only in the very simplest of applications. For example, consider the problem of starting and stopping a stepping motor under load. Direct generation of the quadratic functions necessary to achieve smooth acceleration is quite difficult in hardware, but it is easy to generate exponentials that are adequate approximations of these. The circuit outlined in Figure z.4 illustrates how this can be done:

Figure z.4 

With such a design, the time constant RC is usually determined empirically by setting up the system and then adjusting R and C until the system operates properly.

Practical Examples

The NE555 timer can be used as a voltage controlled oscillator, but I first saw this done with discrete components on a controller for a paper-tape reader designed around 1970.

Software Solutions

The basic control models outlined at the start of this section can be directly incorporated into the software for controlling a stepping motor, and this must be done if, for example, the motor is driving a load with a variable moment of intertia or driving a load against variable frictional loadings. Most open-loop stepping motor applications are not that complicated, however! So long as the inertia and frictional loadings are constant, the control software can be greatly simplified, replacing complex model computations with a table of precomputed delays.

Consider the problem of accelerating the motor from a standing start. No matter where the motor starts, so long as the torque, moment of inertia and frictional loadings remain the same, the time sequence of steps will be the same. Therefore, we need only pre-compute this time sequence of steps and save it in an array. We can use this array as follows to accelerate the motor:

array AV, the acceleration vector, holds time intervals
i is the index into AV

i = 0

repeat the following cycle to accelerate forever:

wait AV[i] seconds and then
step( 1 )
i = i + 1

It is a straightforward exercise in elementary physics to compute the entries in the array A. If the motor is accelerating at A_target,

_i = 1/2 A_target t_i²

_i -- the shaft angle at each successive step

t_i = (2_i / A_target) ^0.5

₀ = 0

_i = Si

t₀ = 0

t_i = k i^0.5

k = (2S/A_target)^0.5

A[0] = (2S/A_target)^0.5

A[i] = (i^0.5 - (i - 1)^0.5)A[0]

In general, we aren't interested in indefinite accelearation, but rather, we are interested in accelerating until some speed or position restriction is satisfied, and then the control system should change, for example, from acceleration to deceleration or constant speed operation. So long as friction can be ignored, so the same rates can be used for acceleration and deceleration, we can make a clean move to a target position as follows:

array AV is the acceleration vector
i is the index into AV

i = 0

D = _target -

while D nonzero do the following

if D > 0 -- spin one way

step( 1 )

D = D - 1

else -- spin the other way

step( -1 )

D = D + 1

endif
wait AV[i] seconds and then
if (i < |D|) and (S/AV[i] < V_target) -- accelerate

i = i + 1

else if i > |D| -- decelerate

i = i - 1

endif

endloop

The above code does not take advantage of the higher rates of deceleration allowed when there is friction. In general, this should not cause any problems, but if the fastest possible moves are desired, a separate deceleration table should be maintained. Here is one idea:

array AV holds acceleration intervals
array C holds coasting intervals
array T holds transition information
array D holds deceleration intervals

i = 0

repeat the following until the desired speed is reached

wait A[i] seconds and then
step( 1 )
i = i + 1

repeat the following to maintain the speed

wait C[i] seconds and then
step( 1 )

repeat the following to maintain the speed

i = i - T[i]

repeat the following until i = 0
i = i - 1
step( 1 )

Simple Practical Examples

An Object Oriented Design