Stepper Acceleration in RWTS
Sheldon Simms
I figured it must be related to some characteristics of the stepper motor used, but upon opening various floppy drives I have found that quite different stepper motors were used in different drives. The stepper motor in my oldest Disk II is a North American Philips A82709-M2, for which I have not been able to find any official documentation, but it's pretty clear from various sources, that it is a 7.5 degree per step, 12 V, 4-phase motor similar to this one: http://www.hurst-motors.com/sasdirectdrive.html
Still, nothing about that motor enlightens me as to why the phase-on/phase-off table values were chosen as they were. Was it just trial and error for a particular motor? If so, why was it ok for other motors?
Another question that comes to mind is why is the motor driven by alternating between one phase energized and two phases energized? Why not have two phases energized all the time until you've arrived at your track?
Michael J. Mahon
> Hi everyone. I was looking at RWTS and I'm wondering where the values in the phase-on/phase-off tables used to accelerate the stepper motor come from. Clearly, the idea is to start stepping slowly and then accelerate. But why were these particular values chosen and why is the minimum value $1C (2.8 ms)?
>
> I figured it must be related to some characteristics of the stepper motor used, but upon opening various floppy drives I have found that quite different stepper motors were used in different drives. The stepper motor in my oldest Disk II is a North American Philips A82709-M2, for which I have not been able to find any official documentation, but it's pretty clear from various sources, that it is a 7.5 degree per step, 12 V, 4-phase motor similar to this one: http://www.hurst-motors.com/sasdirectdrive.html
The stepper motor winding has a certain inductance, L, and its
resistance, plus the driver impedance, forms a series resistance R.
The time constant for current changes in such a circuit is L/R, and
any driving pulse must be one or two time constants for the drive
current to attain near maximum values--which corresponds to near-maximum
torque.
Therefore, for any given L and R, there is a minimum pulse width that
ensures developing maximum torque. Woz may have determined the minimum
pulse width based on this.
> Still, nothing about that motor enlightens me as to why the phase-on/phase-off table values were chosen as they were. Was it just trial and error for a particular motor? If so, why was it ok for other motors?
I suspect that the code was verified for the gutted Shugart SA390, and
that subsequent stepper motors were enough better that the constants
became more and more conservative.
When split-band actuators became common (typically in half-height
drives), it was common to POKE a much smaller value into the basic
time delay unit in RWTS so that all the stepping times were cut in
half (or more). Seeking became very fast, and the newer drives
could easily follow the faster pulses. (I used to remember the
POKE, but now I'd have to find it again. For a while, some drive
sellers published it in their ads!)
> Another question that comes to mind is why is the motor driven by alternating between one phase energized and two phases energized? Why not have two phases energized all the time until you've arrived at your track?
The state of two phases energized corresponds to a "phantom" pole
between the two actual poles. Thus A-AB-B-BC-C is a higher-torque
way of getting from A to C. The "real" poles are geometrically
determined, and the stepper angles they represent are more stable
than the "virtual" poles, which are based on current and field
balance between the two actual pole windings. Therefore, it is
reasonable to base the track positions on real poles only, so
any stepping sequence must begin and end with single windings
energized.
FWIW, it is posible to "microstep" virtual poles by using high
frequency pulses, pulse-width-modulated to produce an effective
current balance anywhere between all one real pole and all the
other.
As a practical matter, energizing two windings requires twice the
current and generates twice the heat, so you don't want to hold the
windings on for an extended period.
-michael
NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Sheldon Simms
>
> Therefore, for any given L and R, there is a minimum pulse width that
> ensures developing maximum torque. Woz may have determined the minimum
> pulse width based on this.
Ok that's helpful, but I don't see any of this specified on any motor datasheets.
Would one just determine this empirically?
Assuming that a later motors have higher enough torque/faster enough response,
then wouldn't the motor turn to an energized phase and bounce around it for
a bit until it settles, only to have to start from zero angular velocity again
when the next phase is energized? If that's the case, then the whole idea of
"accelerating" the motor is kind of silly even though the code may successfully
seek to the correct track.
> The state of two phases energized corresponds to a "phantom" pole
> between the two actual poles. Thus A-AB-B-BC-C is a higher-torque
> way of getting from A to C. The "real" poles are geometrically
> determined, and the stepper angles they represent are more stable
> than the "virtual" poles, which are based on current and field
> balance between the two actual pole windings. Therefore, it is
> reasonable to base the track positions on real poles only, so
> any stepping sequence must begin and end with single windings
> energized.
> ...
> As a practical matter, energizing two windings requires twice the
> current and generates twice the heat, so you don't want to hold the
> windings on for an extended period.
Right. I wasn't suggesting putting tracks on a "virtual pole" (although I'm
pretty sure that was actually done for various reasons) but just wondering
about the one-two-one-two pattern for seeking in the light of the fact that
most datasheets I've looked at assume a two-two-two-two pattern for
stepping.
Thanks for the reply.
vladitx
> Ok that's helpful, but I don't see any of this specified on any motor datasheets.
It's not the motor only, but the whole mechanical construction. Floppy
drive specs have track-to-track min seek times.
> Would one just determine this empirically?
That works, too. :) As mentioned, newer drives got faster at seek.
> Assuming that a later motors have higher enough torque/faster enough response,
> then wouldn't the motor turn to an energized phase and bounce around it for
> a bit until it settles, only to have to start from zero angular velocity again
> when the next phase is energized?
After the oscillations upon decelerating reduce, there are further
oscillations while "keeping" the position. That's why it's not
recommended to read/write with coils still on.
> If that's the case, then the whole idea of
> "accelerating" the motor is kind of silly even though the code may successfully
> seek to the correct track.
Probably. You can't control different torque motors and different
mechanic loads equally effective with the same fixed timing.
One of the reasons the floppy drives got more intelligent.
Since there is no current control and plenty of time, the torque is
high enough to do the job.
> Right. I wasn't suggesting putting tracks on a "virtual pole" (although I'm
> pretty sure that was actually done for various reasons)
Quarter (0.25) tracks.
> but just wondering
> about the one-two-one-two pattern for seeking in the light of the fact that
> most datasheets I've looked at assume a two-two-two-two pattern for
> stepping.
Going through smaller steps, like the A-AB-B sequence, results in more
smooth travel.
Probably less mechanical stress, too.
martin_haye
> ... If that's the case, then the whole idea of
> "accelerating" the motor is kind of silly even though the code may successfully
> seek to the correct track.
I can add that my own experience developing NakedOS involved
empirically determining values that would work, and that I found
acceleration to be definitely necessary. If I started out stepping to
fast, the stepper wouldn't move at all.
There were some mentions in Beneath Apple DOS (I think) about Shugart
specs, and I suspect Woz actually had access to technical docs for the
stepper and used a table computation to arrive at the acceleration/
deceleration values.
I'm fascinated to learn about POKEing new speed values in for newer
drives into DOS. That's so cool I have to try it with my IIc.
--Martin
Michael J. Mahon
> On Dec 28, 7:51 pm, Sheldon Simms <wsspa...@gmail.com> wrote:
>
>>... If that's the case, then the whole idea of
>>"accelerating" the motor is kind of silly even though the code may successfully
>>seek to the correct track.
>
>
> I can add that my own experience developing NakedOS involved
> empirically determining values that would work, and that I found
> acceleration to be definitely necessary. If I started out stepping to
> fast, the stepper wouldn't move at all.
>
> There were some mentions in Beneath Apple DOS (I think) about Shugart
> specs, and I suspect Woz actually had access to technical docs for the
> stepper and used a table computation to arrive at the acceleration/
> deceleration values.
While that may be so, acc/dec head movement was virtually unknown
in the floppy world at that time, since seeking was done with very
simple "step up/step down" logic.
I think that Woz, who was doing all the drive control in software,
simply saw an opportunity for speedup and persued it. I'd bet that
the values he used were at least partially the result of experiment.
The Disk ][ was the fastest-seeking Shugart floppy drive on the
market because of his more sophisticated control (not to mention
the higher effective data rates from his use of GCR).
> I'm fascinated to learn about POKEing new speed values in for newer
> drives into DOS. That's so cool I have to try it with my IIc.
I suspect you'll find significant seek speedups!
Michael J. Mahon
Here's the delay routine used for seeking and motor control
in DOS 3.3:
39FD: 2 **************************
39FD: 3 * MSWAIT SUBROUTINE *
39FD: 4 **************************
39FD: 5 * *
39FD: 6 * DELAYS A SPECIFIED *
39FD: 7 * NUMBER OF 100 USEC *
39FD: 8 * INTERVALS FOR MOTOR *
39FD: 9 * ON TIMING. *
39FD: 10 * *
39FD: 11 * ---- ON ENTRY ---- *
39FD: 12 * A-REG: HOLDS NUMBER *
39FD: 13 * OF 100 USEC *
39FD: 14 * INTERVALS TO *
39FD: 15 * DELAY. *
39FD: 16 * *
39FD: 17 * ---- ON EXIT ----- *
39FD: 18 * A-REG: HOLDS $00. *
39FD: 19 * X-REG: HOLDS $00. *
39FD: 20 * Y-REG: UNCHANGED. *
39FD: 21 * CARRY: SET. *
39FD: 22 * *
39FD: 23 * MONTIMEL, MONTIMEH *
39FD: 24 * ARE INCREMENTED ONCE *
39FD: 25 * PER 100 USEC INTERVAL*
39FD: 26 * FOR MOTON ON TIMING. *
39FD: 27 * ---- ASSUMES ---- *
39FD: 28 * 1 USEC CYCLE TIME *
39FD: 29 **************************
39FD: 0003 30 DS 3,0 ;AVOID PAGE BOUNDARY
CROSSING...
3A00:A2 11 31 MSWAIT LDX #$11
3A02:CA 32 MSW1 DEX DELAY 86 USEC.
3A03:D0 FD 3A02 33 BNE MSW1
3A05:E6 46 34 INC MONTIMEL
3A07:D0 02 3A0B 35 BNE MSW2 DOUBLE-BYTE
3A09:E6 47 36 INC MONTIMEH INCREMENT.
3A0B:38 37 MSW2 SEC
3A0C:E9 01 38 SBC #$1 DONE 'N' INTERVALS?
3A0E:D0 F0 3A00 39 BNE MSWAIT (A-REG COUNTS)
3A10:60 40 RTS
This is the unrelocated "master" code, so $8000 should be added
to all addresses to correspond to a 48K "slave" DOS.
The location to patch to speed up all the mechanical delays is
$BA01, which has a standard value of 17 ($11). With a fast (modern)
drive you can safely change it to 8 or so. Just drop it until seek
errors start to occur, then bump it up a bit. ;-)