LinuxCNC: real-time CNC control on a Linux kernel

What LinuxCNC replaces on a machine tool

A commercial CNC control is usually a black box: a pendant, a proprietary drive bus and a vendor toolchain. LinuxCNC replaces that box with an ordinary PC running Linux, plus a hardware interface that turns step and direction pulses, encoder counts and spindle signals into something the kernel can read and write. The README lists the targets plainly: milling machines, lathes, 3D printers, laser cutters, plasma cutters, robot arms, hexapods. That breadth is the point. The same motion core drives a three-axis mill and a six-legged robot, because the axis count and kinematics are configuration, not firmware.

The audience is narrower than the target list suggests. LinuxCNC suits people retrofitting an existing machine, or building one from scratch, who are comfortable editing text configuration files and reading documentation for a specific version. It also suits anyone who needs to change how the machine behaves at the trajectory level and cannot do so with a vendor controller. It is a poor fit for someone who wants to unbox a router, plug in USB and cut. The README's own disclaimer is blunt about the stakes: it is "EXTREMELY unwise to rely on software alone for safety", and machinery must have provisions for removing power from all motors before anyone enters a danger area. That is not boilerplate. A PC-based controller can hang, and the machine must be safe when it does.

G-code in, step pulses out: the LinuxCNC data flow

The repository layout maps onto the runtime. Under src/ sits the motion controller and the interpreter; rtlib/ holds the real-time library; bin/ and scripts/ hold the launcher and helper programs; tcl/ holds the Tcl/Tk interface layer; configs/ holds sample machine configurations; nc_files/ holds G-code examples. A typical session starts with the launcher reading a configuration directory, which contains the INI file describing the machine and one or more HAL files.

The interpreter turns G-code into canonical machining commands. The trajectory planner converts those into a position stream with velocity and acceleration limits. The motion module runs in the real-time context and produces the actual hardware signals. HAL is the piece that distinguishes LinuxCNC from a monolithic controller: it is a signal-routing layer where named pins and parameters are connected with net statements, so a spindle-enable pin can drive a physical output, a GUI indicator, or both. You can watch and rewire those signals while the machine is idle.

Real-time behaviour comes from the kernel, not from the application. LinuxCNC historically required an RTAPI real-time layer backed by a patched kernel, and the project's build documentation covers building the kernel and the software together. That is why the supported platform is Linux and effectively Linux alone: the real-time guarantee is a kernel property, and the README offers no path to Windows or macOS.

Installing LinuxCNC and running a first configuration

The README links to an Install page and a Build page in the project documentation, and the repository ships a debian/ directory for packaging. The documented route for a new machine is the live install image from the project's site, not a distribution package, because the image carries a kernel already prepared for real-time use. The Install page is the authority for the current image and the supported distributions. The repository's debian/ directory is where the packaging lives:

cd debian

The build documentation describes building the software from a source checkout, and the repository's top level carries the files that flow implies. Machine configurations are directories, and the sample set under configs/ is the reference for what a working one contains. A minimal configuration needs an INI file and a HAL file; the INI names the kinematics, the axis limits and the interface, and the HAL file wires the signals. The simulator configurations under configs/ are the correct first run, and the sample G-code lives under nc_files/:

cd configs
cd nc_files

Those directories are the two places to look first: configs/ for a machine definition to copy, nc_files/ for G-code to feed the interpreter. Running a simulator configuration exercises the interpreter, the trajectory planner and the GUI without commanding real hardware, so you can confirm the installation before a motor is ever energised.

When you move to a physical machine, the first real check is latency: the documentation describes a latency test that measures how long the kernel takes to respond, and the result determines the maximum step rate your PC can sustain. A machine that loses steps at high feed rates is usually a latency problem, not a G-code problem.

Hardware interfaces: parallel port, Mesa cards and EtherCAT

LinuxCNC does not talk to motors directly. It talks to an interface, and the interface determines what the machine can do. The simplest case is the PC parallel port, which the documentation covers as a step and direction output. It is cheap and it is limited: few pins, no encoder feedback, and a step rate capped by the latency of the machine it runs on.

For serious machines the documentation covers Mesa interface cards, and the related searches around the Mesa 7i77 suggest that is a common pairing for analogue servo systems. Those cards move pulse generation off the CPU and onto dedicated hardware, which removes the step-rate ceiling that the parallel port imposes. EtherCAT appears in the same context: it is a fieldbus option for drives and I/O that speak it, and it changes the architecture from per-axis pulse trains to a cyclic network exchange.

The consequence for planning is that the controller board choice comes before the software choice. If your drives take an analogue command and your encoders need to close the loop, you need a card that supports that, and the HAL driver for that card has to exist in the version you install. A configuration that works on one interface will not simply port to another; the HAL file is where that difference lives.

Where LinuxCNC is the wrong tool

The first limitation is the platform. LinuxCNC is Linux software with real-time requirements, and there is no supported Windows or macOS control station. Running it in a virtual machine defeats the purpose, because the real-time guarantee depends on direct access to the hardware and the timer. If your shop standard is Windows, this is not a candidate.

The second is the install and maintenance shape. The recommended path is a whole operating system image rather than a package you add to an existing desktop. That means the machine PC is dedicated, and upgrading the distribution underneath LinuxCNC is not a routine operation. The release history shows point releases on the 2.9 line, with v2.9.8 in January 2026, v2.9.9 in June 2026 and v2.9.10 in July 2026, and the repository's last push was on 2026-09-28. Those are patch releases; a major version change is a project to schedule, not an update to apply.

The third is the safety boundary the README draws for itself. The authors state they accept no liability for harm or loss, and that machinery must be designed to comply with local and national safety codes. LinuxCNC does not certify your machine. If you need a control that arrives with a compliance file and a support contract, an open source project that disclaims exactly that is the wrong foundation.

Finally, the configuration surface is large. INI files, HAL files, kinematics modules and interface drivers all have to agree. A machine that behaves oddly is usually a configuration problem, and diagnosing it requires reading the documentation for your version rather than searching for a generic answer.

LinuxCNC against GRBL and vendor controllers

The closest comparison for a hobby machine is a microcontroller firmware such as GRBL running on an Arduino-class board. The difference is architectural. GRBL fits the entire motion problem into a small fixed-function program: you send G-code over a serial link, it emits step pulses, and there is no operating system, no HAL and no trajectory planner you can modify. That makes GRBL dramatically easier to deploy and far more predictable on cheap hardware. It also caps what you can do. There is no general mechanism for closing a servo loop, no fieldbus, and no way to add a custom kinematics model for a hexapod.

LinuxCNC takes the opposite position. It puts the motion problem on a general-purpose computer with a real-time kernel, and exposes the wiring between software modules as configuration. That buys flexibility and costs predictability. A GRBL board boots in milliseconds and never has a scheduler problem; a LinuxCNC PC can fail a latency test on the wrong motherboard.

Against vendor controllers, the trade is support for control. A commercial control comes with a commissioning engineer, a warranty and a phone number. LinuxCNC comes with documentation, a forum and source code. If your machine is a production asset where downtime has a cost per hour, the vendor's support line is part of the product. If your machine is a retrofit, a prototype or a teaching tool, the ability to read and change the controller is worth more.

Licence, packaging and the cost of staying current

The README badges are specific: most of the software is under LGPL 3, and some parts are under GPL 2. The repository carries COPYING and COPYING.more, so the split is real rather than a single blanket licence, and the per-file headers are what determine which terms apply to a given component. For someone building a machine for their own shop, this is mostly irrelevant. For someone shipping a product that embeds LinuxCNC, the distinction matters: LGPL components can be linked into a proprietary application under the usual conditions, while GPL components carry stronger obligations. That is a question for a lawyer, not for this article.

The upgrade cost is the practical licence-adjacent issue. Because the recommended installation is an operating system image, moving from one LinuxCNC release to the next can mean moving the whole system, and the kernel that provides real-time behaviour is tied to that system. The build documentation exists for people who need to compile against a specific kernel, and that is the escape hatch when the packaged image does not match your hardware. The cost is that you now maintain a kernel build. The repository's debian/ directory and the release tags suggest the project does produce packaged releases, so the question is which path your machine can tolerate: a periodic reimage, or a build pipeline you own.

Editorial conclusion

Adopt LinuxCNC if you are retrofitting a machine tool and want the trajectory planner, HAL and G-code interpreter to be inspectable and modifiable, and if you can dedicate a PC and a parallel or Mesa-class interface card to it. Do not adopt it if you need a Windows or macOS control station, or if your machine's vendor already supplies a working controller you cannot replace. Before committing, verify three things on your own hardware: that the live install image boots and the latency test holds a steady figure on your motherboard, that your breakout board is covered by the HAL drivers in the version you picked, and whether you are willing to build from source when you need a kernel that matches your real-time patch.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. LinuxCNC/linuxcnc on GitHub
3. Project website
4. README
5. Releases