Most software degrades gracefully under load. A web request takes an extra 200ms and nobody notices. Machine control does not work that way: a control loop that misses its deadline produces a position error, and a position error is a visible mark on a finished part.
What "real-time" actually means
Real-time does not mean fast. It means predictable. A system that always responds within 1ms is real-time; one that usually responds in 50µs but occasionally takes 5ms is not — and for machine control the occasional case is the one that matters.
| Class | Deadline miss means | Example |
|---|---|---|
| Hard real-time | System failure | Servo control loop, safety interlocks |
| Firm real-time | Result becomes useless | Trajectory segment delivery |
| Soft real-time | Quality degrades | Screen refresh, position display |
The architectural consequence: separate your hard real-time work from everything else. The control loop should do position calculation and IO — nothing more. File parsing, screen updates, network activity and logging belong on the non-real-time side, communicating through a lock-free buffer.
Where the loop actually lives
- Read feedback Encoder counts from each axis.
- Compute the commanded position The next point on the planned trajectory for this instant.
- Calculate the error Commanded minus actual, per axis.
- Run the control law Typically PID with feedforward, producing a velocity or torque command.
- Write the output Over EtherCAT, analogue, or step/direction.
- Check safety conditions Following error, limits, watchdog.
All of that, every cycle, at 1–10kHz, without ever running late. That is the entire engineering problem in one list.
Where jitter comes from
- The operating system scheduler preempting your loop for something else.
- Interrupts from network, USB or storage devices.
- Memory paging — a page fault in the control path is catastrophic, which is why real-time code locks its memory.
- Cache misses and CPU frequency scaling, which make execution time variable.
- System management interrupts at the firmware level, invisible to the OS.
- Non-deterministic calls — allocation, file IO, locks, or logging inside the loop.
The discipline that makes it work: inside the control loop, no memory allocation, no file access, no locks that can block, no logging. Everything the loop needs is pre-allocated before it starts. This single rule eliminates most latency spikes.
Measuring, not assuming
Determinism is a measured property. A serious control implementation instruments the loop and reports:
| Metric | Why it matters |
|---|---|
| Worst-case jitter under sustained load | The number that actually characterises the system |
| Loop execution time distribution | Shows headroom before overrun |
| Overrun count | Must be zero over long runs |
| Following error, per axis | The physical consequence of timing behaviour |
"It felt smooth in testing" is not a specification. Worst-case jitter measured over hours of loaded operation is.
Why smooth motion is a planning problem
Even a perfect control loop produces poor surface finish if the trajectory it is following is badly planned.
- Unlimited jerk — instantaneous acceleration changes excite machine resonance and show as chatter. S-curve profiles limit the rate of acceleration change.
- Shallow look-ahead — if the planner cannot see far enough ahead, it decelerates unnecessarily into every corner, producing stuttering motion and dwell marks.
- No corner blending — stopping at every segment junction on a finely tessellated surface is slow and leaves marks.
- Feedrate ignoring geometry — commanded feed that the machine cannot achieve through curvature.
Safety belongs in the architecture
Software watchdogs, following-error limits and safe-state behaviour on fault are essential and must be designed in rather than added. It is also important to be precise about scope: for machines requiring certified functional safety, the control software should be architected to work alongside certified safety relays or a safety PLC. Software you write is not a substitute for certified safety hardware, and any partner claiming otherwise is one to avoid.
Build, extend, or buy
| Approach | Good when | Trade-off |
|---|---|---|
| Commercial controller | Standard machine, standard kinematics | Per-unit cost; limited extensibility |
| LinuxCNC + custom components | Unusual kinematics, cost-sensitive | You own integration and support |
| Custom control stack | Product you ship; specific timing needs | Largest engineering investment |
Building a machine or modernising a control? Tell us the kinematics and drives involved — we will be straight about whether custom control is warranted. See our CNC controller software service.