drive.doc

一个C style Assembler的source code

                      8051-Based Stepper Motor Driver

(0) Introduction
   This software is part of a larger real-life test system that was designed
to test gear ratios on registers.  The stepper motor was used to precisely
control the total amount of rotation of the gear train in order to get precise
measurements on this ratio.

   The system was configured as follows:

           * 1 microprocessor-based server, connected to a keypad and display
           * 4 microprocessor-based client units, each driving a stepper
             motor in open loop configuration.
           * One RS-485 serial link between the units.

The server unit was set up to be as non-linguistic as possible (using numbers
and pictures), because (1) people can see faster and more reliably than they
can read, and (2) the unit was to be used abroad.

(1) Multi-tasking Control
   Each unit operates in real-time.  That means correctness requires not only
that correct outputs be produced for given input, but that it also be
produced AT THE CORRECT TIME.  This implies the need for process synchronization
and points to the need for an underlying multi-tasking architecture.
   The kernel library routines provided with the 8051 package were custom fitted
to this application (KC.lib).  This kernel differs from the kernel used in the
other demo software in that it operates at 3 distinct priority levels, instead
of the usual two: (1) from within a high-priority interrupt, (2) from within a
low-priority interrupt, and (3) outside all interrupts.  As in other
applications, since this is I/O-bound software, there will not be any foreground
processing, so that the last level is effectively disabled.  All processing
occurs inside of interrupts.

(2) Hardware Configuration
   A driver unit is connected as follows:
      (1) A stepper motor unit via 4 I/O lines.  These lines are for:
          P1.0 ... PULSE OUTPUT to control the motor.
          P1.1 ... DIRECTIONAL SETTING to control which way the motor rotates
          P1.2 ... ENCODE PULSE SIZE to control how many encoder pulse outputs
                   make up one rotation of the motor (200 or 400).
          P1.3 ... ALL WINDINGS OFF to set or reset the motor so that it can be
                   run.
      (2) Two LED units to display the status of the most recent test.
          P1.4 ... Red LED
          P1.5 ... Green LED.
      (3) A placement unit for the stepper motor, with inputs for:
          INT1 ... MICROSWITCH to sense the placement of a register unit.
                   Activates the motor unit on a falling edge.
          INT0 ... DIAL SENSOR to sense the position of the register needle.
                   Produces a falling edge for a sensor interrupt.

(3) Speed Control and Synchronization
   (A) Overview
   The stepper motor is controlled by sending out pulses of around 20 to 50
microseconds for each step.  Depending on the setting of the motor, either
200 or 400 steps will generate one full rotation of the motor.  The speed of
the motor is therefore inversely proportional to the delay between consecutive
pulses, and the length of time spent at a given speed is equal to that delay
multiplied by the number of pulses sent out.  In this setup, 200 pulses per
rotation is always selected.

   The easiest way to accomplish acceleration or deceleration is to use a
look-up table for converting desired speeds into desired pulse delays, and
to "accelerate" the motor by driving it incrementally at higher and higher
speeds.  I have set up such a look-up table for this application that lists
delays for multiples of 25 RPM, which comes out to 250/3 pulses per second at
200 encoder pulses per rotation, with the list ranging from 25 RPM to 2000 RPM.

   The natural time unit in this application is 3/250 second (the inverse of
25 RPM).  To drive the motor at N multiples of 25 RPM for T time units will
therefore require that N x T pulses be sent out: N pulses per time unit.

   The machine's instruction cycle rate is 921600 Hz, and this is also the rate
of the internal clock used to measure pulse delays.  So the delay for a 25 RPM
pulse would be 921600 * 3/250 = 11059.2 cycles.  Similarily, the delay for N
multiples of 25 RPM will be 11059.2/N.  These are the values stored in the
table.

   So accelerating the motor simply comes down to driving it at 25 RPM for a
certain number of time units, at 50 RPM for the same duration, at 75 RPM for the
same duration, and so on up to the desired speed.  A similar method
accomplishes deceleration.  The number of time units spent at each speed is an
empirical constant that is chosen as small as possible.  However, if it is
chosen to be too small then the corresponding acceleration or deceleration will
become so fast that the stepper motor will consistently lose coupling.  So that
determines the lower limit of the choice made.  In general, different constants
are chosen for acceleration and for deceleration.

   Driving the stepper motor past 1000 RPM will require time-critical software
so precise that the delays described above would have to be carried out by the
microprocessor down to the last clock cycle.  That means microsecond precision.

   The reason for this can be illustrated by the following observation.  At
1750 RPM (70 multiples of 25 RPM), the delay between pulses will only be
11059.2/70 clock cycles, or about 158 cycles.  The speeds corresponding to
157, 158, and 159 cycles are;

                11059.2/157, 11059.2/158, and 11059.2/159

multiples of 25 RPM, which comes out to about:

                    1761 RPM, 1750 RPM, and 1739 RPM

respectively.

   An algorithm that consistently misses its delay by random errors of merely 1
clock tick will cause a random plus or minus 11 RPM variation in the motor when
it's running at around 1750 RPM.  That will lead to vibrations that will cause
the motor to lose coupling and break to a sudden stop!

   The timing is achieved simply by using a continuously running clock that
automatically reloads itself (TIMER 2 of the 8052).  Then one can keep the
timer going without having to worry about calculating any latencies.

   (B) Example
   This example will illustrate the process that is gone through to bring
a stepper motor up to 1750 RPM, run it there for a while, and then step it
down.  In this application, motors are consistently set for counter-clockwise
motion with 200 pulses per rotation.

   First SetDriver is called.  This will delay a second to wait for the windings
to finish setting.  The value 1750/25 is placed into the accumulator, A, and
Accelerate is called.  When complete, the motor will be running at 1750 RPM.

   Then PulseTrain is called.  This routine runs the motor at its current
speed indefinitely.  It only stops when either of the external flags, Change,
or Aborting, is set by another process.  The second flag is used to enable the
operator to abort a test.  The first is used to allow the test to abort
normally.  We will assume that Change was set here.

   After PulseTrain is called, the motor is decelerated to a stop.  This is
done by placing the value 0 in the accumulator, A, and then calling Decelerate.
It is possible in this application to bring the motor to an immediate stop, if
desired, by just turning off the pulse timer after PulseTrain is finished.
Afterwards, ResetDriver is called to turn off the windings.

(4) Testing Algorithms, Operator Interface
   (A) Overview
   There are two types of processes that the driver unit will support: (1)
Test mode, and (2) Jog mode.  The first uses the sensor input to mark off
one full rotation of the register undergoing measurement, the second mode
allows the operator to set the position of the dial on a register.
   The control loop is called StepperLoop.  When a test starts, it will either
enter jog mode or test mode depending on the variable, Testing, which must be
set by another process before starting.  The WaitForActive loop is set up to
guard against spurious INT1 interrupts.

   (B) Test Mode
   A driver unit will receive a command to enable test mode and a specification
of the register unit type undergoing test.  Both the specification and mode
will remain between tests until the unit receives new speficiations.
   After test mode is enabled, then from then on each time the operator places
a register in the Client(s) selected a test will automatically start.  The
motor on the Client(s) will accelerate to full test speed (1750 RPM).  When
the dial passes the dial sensor the first time output pulses will be counted.
When the dial reaches the sensor the second time, the counting will be stopped
and the motor will be immediately stopped.
   Thus, the dial sensor will serve both the purpose of marking off one full
rotation of the register and of setting up the register's dial.

   When a test is thus completed, the driver unit will perform mathematical
calculations to determine the outcome of the test and then light the green LED
if the test passes, or else the red LED.  Accuracy control limits, for this
application, were set to 1/256 (0.4%).  On request from the master unit, the