The gap between a hobby motion controller and industrial firmware is not features. It is what happens when something goes wrong — and whether the timing behaviour has been measured rather than assumed.
The control loop, and what makes it industrial
Every servo controller does roughly the same thing each cycle: read feedback, compute error, apply a control law, write output. What separates industrial implementations is everything around that.
| Aspect | Hobby-grade | Industrial-grade |
|---|---|---|
| Timing | "Fast enough" | Measured worst-case jitter |
| Control law | PID | PID plus feedforward |
| Following error | Not monitored | Monitored; faults on excess |
| Fault response | Stop, or undefined | Defined safe state per fault class |
| Watchdog | Often absent | Drives disabled if loop stalls |
| Diagnostics | Minimal | Logged, trendable, exportable |
| Recovery | Power cycle | Defined resume paths |
Feedforward: the largest single improvement
Pure feedback control is inherently reactive — it can only respond after an error exists. During acceleration, that lag produces substantial following error.
Feedforward supplies what the trajectory already knows. The planner knows the commanded velocity and acceleration at every instant, so command them directly rather than waiting for error to develop.
Practically: velocity feedforward typically removes most of the following error during constant-velocity motion, and acceleration feedforward addresses the remainder during acceleration. On contouring work this shows directly as improved accuracy at corners and on curves, without touching the mechanics.
Following error as the primary safety mechanism
In motion control, following error is the most informative single quantity you can monitor. It tells you the axis is not doing what it was told.
- A collision shows as following error spiking immediately.
- A stalled or faulted drive shows as error growing steadily.
- Mechanical binding shows as error rising in one region of travel.
- Encoder failure shows as error behaving nonsensically.
This is why a following-error limit is not optional. It is frequently the only thing standing between an unnoticed problem and mechanical damage. Set it tight enough to catch faults early and loose enough not to nuisance-trip during normal acceleration — which requires measuring normal behaviour first, not guessing.
Fault handling is most of the engineering
The happy path is straightforward. Industrial firmware is defined by its fault paths:
- Classify faults by severity — recoverable warning, controlled stop, immediate power removal.
- Define the safe state for each class. Uncontrolled coasting is rarely the right answer on a machine with a spindle engaged.
- Coordinate multi-axis stops. Stopping one axis instantly while others continue can be worse than a coordinated deceleration.
- Preserve state for diagnosis — capture the conditions at fault time so the cause is findable.
- Define recovery explicitly — what must be re-homed, what can resume, what requires operator confirmation.
The quality of motion firmware is visible only when something breaks. Everything else is arithmetic.
Where the loop should live
| Platform | Typical jitter | Suits |
|---|---|---|
| PREEMPT_RT Linux | Low, bounded | PC-based control with rich HMI |
| Xenomai / dual-kernel | Very low | Tighter requirements on a PC |
| Dedicated MCU | Very low, deterministic | Embedded controllers, machine builders |
| FPGA | Effectively deterministic | Very high loop rates |
| Stock desktop OS | Unbounded | Not suitable for the control loop |
A common and sensible architecture puts the hard real-time loop on a dedicated MCU or real-time kernel, with a normal OS handling interface, files and networking — communicating through a buffer so the non-real-time side can never stall motion.
Fieldbus considerations
- EtherCAT — the common choice for coordinated multi-axis; cycle times align well with control loops.
- CANopen — widely supported, lower bandwidth, adequate for many machines.
- Step/direction — simple and open-loop unless you add feedback separately.
- Analogue velocity — legacy but still encountered in retrofits.
Whichever you use, the bus cycle must be synchronised with your control loop. Asynchronous sampling introduces jitter into the loop regardless of how deterministic your software is.
Prove the timing, do not assume it
- Instrument the loop and record execution time distribution.
- Report worst-case jitter under sustained load, not average under idle.
- Run for hours — rare latency spikes are exactly the ones that matter.
- Count overruns; the acceptable number is zero.
- Verify at full axis count with the bus running, not on a bench with one axis.
Building motion control firmware or specifying it for a machine? Tell us the drives, axes and timing requirement. See our CNC controller service, real-time fundamentals, and trajectory planning.