Re: ATM steppers & microcontrollers

[Mel Bartels <mbartels@efn.org>]

>>> achieve microstepping by applying current to one winding at a time,
first one winding, then immediately after the second winding, such that
the inverse square of the ratio of applied current properly positions
the rotor

When I first experimented with using PWM to digitally compose a sin/cos
waveform to steppers, I tried your scheme of powering only one winding
at a time, and it caused too much vibration in the motor rotor.  I
surmised that this was caused by the effects of non-synchronous current
collapse in the windings along with the non-synchronous application of
current for certain microsteps.

So, my code starts both windings at the same time, then turns off the
windings when their proportion of current is finished.

The low current draw is thanks to the digital control of the pulse width
modulation.  For instance, I can power the 10 ton 32" scope at the local
observatory with a couple of AA batteries (at least for tracking for a
couple of hours).

>>> microcontrollers controlling the low level motor functions

You might want to get in contact with Jack Brindle and his group that is
porting my computerized dob system to a Mac.  They have elected to move
some of the low level motor functions off to microcontrollers.

The issue to watch out for is with altazimuth mounts: the drive rates
must vary constantly in order that the scope proscribe an arc across the
sky.  Otherwise the actual movement outlined upon the sky by the scope
is a series of short lines.  These lines cannot deviate from the stars'
arcs across the sky by a significant fraction of an arcsecond.  So, a
rule of thumb is that the motor drive rates need to be updated 10 times
to 20 times a second.  This can be much less for certain parts of the
sky.  If you send one way instructions to the microcontrollers operating
the motors, without constant feedback, the scope slowly diverges from
the desired position.  That's because you don't know if the stepper
managed to get that last microstep in or not because the timing cannot
be perfectly synchronized between microcontroller and the overall
controlling PC or laptop.  If you do a BOEC, you get values like 1/4
degree drift in 15 minutes of tracking, so this is bad news.  So, you
are faced with either needing to communicate constantly with the
microcontrollers so that you can correct for this, or give the
microcontroller enough cpu power to do the altaz drive rate calculations
itself, or screw the microcontroller and let the laptop or PC talk
directly to the motors, the approach I chose.

Then, other low level functions that you want the motor controlling item
(either software in the laptop or PC, or, the microcontroller) to do
such as backlash, periodic error correction, and so forth, come up, and
you need to figure out how you are going to handle these.  In addition,
when autoguiding, you need instantaneous control of the motors, so that
you minimize the lag between the guiding chip output and the reaction of
the scope and motors.  If you rely on intermittent serial link, where
the OS or other factors prevent guaranteed instantaneous communications,
then you may be up a creek with no paddle.  Not to say that it can't be
done, these are issues to think about though.  Probably best if you wish
to pursue the microcontroller avenue is a controlling laptop or PC with
a microcontroller that does higher level functions talking to a
microcontroller for each motor that handles low level stuff.

--
Clear skies, Mel Bartels    Programmer/Analyst, amateur astronomer
Eugene, Oregon, USA         homepage: http://www.efn.org/~mbartels
mailto:mbartels@efn.org     atm, atm-digest list-owner
Motorize A Dob: http://zebu.uoregon.edu/~mbartels/altaz/altaz.html