Stepper Motor Simulator: Step Loss and Lag Angle

Controls

The lab re-runs the entire move on every input, so the traces track the slider as you drag it rather than waiting for a Start press. There is nothing to start — the move is 30 000 integration steps and it finishes before your finger moves again.

The upper plot is position: the dashed line is where the driver believes the axis is, the solid line is where the rotor actually is. The lower plot is the lag angle between them, with the stable ±90° band shaded.

Theory

A stepper does not take steps. The driver rotates a magnetic field in increments and the rotor follows it, always trailing behind by some angle — and the torque it produces is the sine of that angle:

T = T_peak(ω) × sin(δ)

δ is measured in electrical degrees. A 1.8° motor has 50 rotor teeth, so its magnetics repeat 50 times per revolution and one full step is exactly 90 electrical degrees. That conversion is the only arithmetic in the whole topic.

Between −90° and +90° the motor is a spring: fall further behind, get pulled harder. That stable region is why an open-loop stepper works at all, and it is where any steady load has to sit. Past 90° the sine turns over, so falling further behind produces less restoring torque, which makes it fall further behind still — and at 180° the torque reverses outright and starts pulling toward the next pole. The rotor slides to the next stable tooth, one electrical cycle — four full steps — away.

Those are two different numbers and the lab keeps them apart. 90° is where the equilibrium ends; a brief overshoot past it is survivable, which is why a full-step command — a 90° kick, every step — does not destroy the machine. 180° is the point of no return.

Three things grow the lag angle:

• Load. At steady speed sin(δ) = demanded ÷ available. A load at half the available torque sits at 30°, leaving 60° of margin.
• Acceleration. Getting the rotor moving costs torque from the same budget, so the lag is worst on the ramp, not at speed.
• Speed, because T_peak itself falls as the motor turns faster.

That last one is the least obvious. A winding is an inductor, and the faster the motor spins, the harder it is to force current in and back out again — reactance rises with electrical frequency, and the spinning rotor’s own back-EMF eats the supply voltage. The result is a torque curve that is flat up to a corner speed and falls away past it, and the corner is set by supply voltage.

Which gives the two rules the lab exists to make obvious: more amps buy torque, more volts buy speed.

Algorithm

The rotor is integrated directly. Nothing in this code detects step loss, inserts it, or knows it is possible — it falls out of the sine law.

// per 20 us tick
const ideal    = sampleProfile(plan, time).position;         // mm the planner wants
const command  = Math.round(ideal * stepsPerMm) / stepsPerMm; // the driver only does whole microsteps
const lag      = rotorTeeth * (commandAngle - theta);         // electrical radians

const { torque } = peakTorque(setup, omega);                  // falls with speed
const friction   = loadTorque * Math.tanh(omega / 0.5);       // smooth Coulomb, one line
const accel      = (torque * Math.sin(lag) - friction - damping * omega) / inertia;

theta += omega * dt + 0.5 * accel * dt * dt;
omega += accel * dt;

Two details matter more than they look.

The command is quantised onto the microstep grid before the rotor sees it. That staircase is the excitation: at full stepping, each command is a 90-electrical-degree kick at a very lightly damped resonance, which is exactly why a full-stepping motor screams and a microstepping one does not.

The winding model sets the torque ceiling:

const backEmf   = kT * speed;
const impedance = Math.hypot(resistance, rotorTeeth * speed * inductance);
const current   = Math.min(currentLimit, Math.max(0, supplyVolts - backEmf) / impedance);
const torque    = Math.SQRT2 * kT * current;

It is a lumped steady-state approximation of a chopping driver, not a phase-by-phase simulation. It reproduces the shape of a real torque curve and gets both engineering answers right; it runs conservative at the very top end.

The commanded trajectory comes from the site’s existing motion profile planner, so “with a ramp” and “without one” are the same code path with a different acceleration limit — there is no separate failure mode written in.

Guided experiments

Each one isolates a single variable. Change nothing else.

1. The ramp is the whole machine. Leave everything at its defaults and flip Step rate between Ramped and Straight to full speed.

Same motor, same driver, same current, same target. The only difference is whether the step rate was ramped, and the difference between them is the entire move.

2. Find the pull-in rate. Set Straight to full speed, then raise Top speed from 100 mm/s in steps. It works, and works, and then somewhere around 200 mm/s it stops working completely — not gradually. That threshold is the pull-in rate, and it is a real number on real motors.

3. Volts buy speed. Load the 12 V supply, run fast preset: the move stalls. Now raise Supply voltage to 24 and watch it complete, with the current limit untouched. Then go back to 12 V and try to rescue it with Current limit instead — you cannot. Past the corner speed the driver was never reaching the set current.

4. Microstepping does not buy accuracy. Fix everything and step Microstepping from 1/1 to 1/16, reading two things:

The tracking improves about three times and then stops. The load error does not move at all. It was 0.044 mm at full stepping and it is 0.044 mm at sixteenth stepping — the difference is that 0.044 mm is a quarter of a full step and three and a half microsteps, so fine microstepping makes the same error look much worse in the units the driver reports.

5. Pull-out. Raise Resisting torque slowly with a modest speed set. Watch the lag angle in the lower plot climb toward the dashed line. It will sit at 30°, then 50°, then 70° — and then, over one small slider increment, sync is gone. There is no warning region, because there is no equilibrium past 90° for it to settle into.

7. Full stepping is a 90° kick. Load the Full stepping preset and read the peak lag: about 102°e. Every single step commands the full 90°, and the rotor’s momentum carries it past. It still arrives — nothing is lost — but it spends the whole move swinging through the region a loaded motor cannot afford to enter. That is simultaneously why full stepping is loud and why it leaves so little margin for load.

6. The mechanism changes the problem. Switch Mechanism to the T8 lead screw with everything else fixed. Resolution goes from 80 to 400 steps/mm, and the same top speed now needs five times the step rate.

What you should observe

• Failure is a cliff, not a slope. Nothing degrades. The lag angle grows smoothly right up to 90° and then the move is simply gone. This is the defining difference between a stepper and a servo-style closed loop, which just slows down under load.
• The machine never knows. The dashed commanded line always finishes exactly on target, because the driver counted every pulse it was given. Only the solid line tells the truth, and no real machine has that line.
• The load error is always there. Even in a perfect run the rotor sits tens of microns behind where the driver says it is. That is not a fault; it is what sin(δ) = load ÷ torque requires.
• Lost steps are always a multiple of four. Try to produce a count that is not.

Taking it to hardware

The most important difference is the last one in a different sense: a real machine gives you no lower plot. You cannot see the lag angle, so you cannot see the margin you are running on. The practical substitute is to find the failure point deliberately — raise speed and acceleration until the axis skips, then back off by 30 to 50 percent and live there.

Start from the wiring and current-limit walkthrough, calibrate steps per millimetre against a ruler, and put the whole thing together in the pen plotter build.

Source code

The ramp is not optional on a real machine. The blocking version below is what most first sketches look like, and it is the one that buzzes:

// What not to ship: the step rate jumps from zero to full.
void moveBlocking(long steps, unsigned delayUs) {
  for (long i = 0; i < steps; i++) {
    digitalWrite(STEP_PIN, HIGH);
    delayMicroseconds(2);
    digitalWrite(STEP_PIN, LOW);
    delayMicroseconds(delayUs);      // constant => no acceleration at all
  }
}

The ramped, non-blocking version. This is the same trapezoid the lab plans, generated one step at a time so nothing else on the microcontroller stalls:

#include <AccelStepper.h>

const float STEPS_PER_MM = 80.0;          // 20T GT2 pulley at 1/16 stepping
AccelStepper axis(AccelStepper::DRIVER, STEP_PIN, DIR_PIN);

void setup() {
  pinMode(EN_PIN, OUTPUT);
  digitalWrite(EN_PIN, LOW);              // active low: energise

  axis.setMaxSpeed(200 * STEPS_PER_MM);   // 200 mm/s
  axis.setAcceleration(2000 * STEPS_PER_MM);
}

void loop() {
  if (axis.distanceToGo() == 0) {
    axis.moveTo(axis.currentPosition() == 0 ? lround(60 * STEPS_PER_MM) : 0);
  }
  axis.run();                             // returns immediately — call it constantly
  checkEndstops();                        // which is only possible because it does
}

setMaxSpeed and setAcceleration give you a trapezoidal profile and nothing else — there is no S-curve option in AccelStepper. For a jerk-limited profile you generate the setpoint yourself and feed it to moveTo on a timer.

If you want to know whether your own machine is near the edge, the cheap test is a repeatability one:

// Drive a long move out and back, N times, then check whether home moved.
// Anything other than a multiple of four full steps is not step loss.
for (int i = 0; i < 20; i++) { moveTo(LONG_MOVE); runToPosition(); moveTo(0); runToPosition(); }
// now re-home and compare the reported position against zero

Assumptions and hardware differences

The rotor dynamics are honest: torque proportional to sin(δ) is how a hybrid stepper works, and the slip behaviour is a consequence of integrating it rather than a rule written into the code. The constants describe a 17HS4401-class NEMA 17 — 1.8°, 1.7 A, 2.8 Ω, 3.2 mH, 0.44 N·m holding, with a reflected 300 g carriage on the shaft.

What the model simplifies: the winding is lumped into a steady-state impedance and back-EMF term rather than simulated phase by phase, so the far tail of the torque curve is pessimistic. Detent torque — the small cogging you feel turning an unpowered stepper by hand — is not modelled, nor is mid-band resonance, nor the driver’s decay-mode behaviour, nor any thermal effect. Timing is ideal, so the step jitter of a real microcontroller does not appear.

None of those change which knob to turn. All of them are reasons to verify a real machine rather than trust a number off this page.

Circuit diagram

The physical setup this models is four wires from the motor to a driver, two wires from the driver to a microcontroller, and one capacitor that people keep leaving out:

Arduino 5V  ──── VDD
Arduino GND ──── GND (logic) ──┬── GND (motor) ──── PSU −
PSU + (12–24 V) ──── VMOT ──┬──┴── 100 µF electrolytic, close to the board
Pin 3 ──── STEP             RESET ──┬── SLEEP
Pin 4 ──── DIR              MS1, MS2, MS3 ──── 5 V   (1/16)
Pin 5 ──── ENABLE (active low)
Coil A ──── 1A, 1B          Coil B ──── 2A, 2B

The A4988 component page has the full pinout, the Vref table for both sense-resistor variants, and the reason that capacitor is not optional.