OS
SmartMachine.
← Back to Home

Kernel Architecture.

How we guarantee sub-millisecond deterministic cycle times on standard x86 hardware using Linux PREEMPT_RT and CPU isolation.

The Myth of the DSP

For decades, legacy machine tool builders claimed that standard PC hardware was incapable of hard real-time motion control. They justified $10,000 proprietary control boards by stating that Digital Signal Processors (DSPs) or FPGAs were strictly required to interpolate motion.

This was true in 1995. It is unequivocally false today. A modern multi-core x86 or ARM processor (even a low-end Intel Celeron) has orders of magnitude more computational power than the DSPs currently shipping in $200,000 legacy machine tools.

PREEMPT_RT & CPU Shielding

The challenge isn't CPU speed; it's the operating system scheduler. Standard Linux or Windows will happily interrupt a critical motion calculation to service a network ping or update a UI element. If that interruption delays the servo update packet by even 1 millisecond, the physical tool chatters, ruining the surface finish.

# Standard GRUB configuration for CPU isolation

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash isolcpus=0,1 nohz_full=0,1 rcu_nocbs=0,1 irqaffinity=2,3"

SmartMachine OS solves this using a two-pronged approach:

  • PREEMPT_RT Patchset: We compile the Linux kernel with the PREEMPT_RT patch, transforming the standard kernel into a hard real-time operating system by making in-kernel locking mechanisms preemptible.
  • isolcpus (CPU Shielding): We explicitly instruct the Linux scheduler to ignore CPU cores 0 and 1. We move all IRQs (network, disk, USB) to cores 2 and 3. Cores 0 and 1 are now completely "shielded" from the OS. We manually pin the CNC Interpolator thread and the EtherCAT Master thread to these shielded cores.

Shared Memory (SHM) Bridge

If the real-time core is isolated from the network stack, how does the HMI (running on Core 2) tell the Interpolator (running on Core 0) to start a program? Through lock-free Shared Memory (SHM) ring buffers. This provides nanosecond-latency data exchange between the IT layer and the OT layer without risking priority inversion or deadlocks in the motion engine.