The compatibility between GRBL and LinuxCNC is a size story with a direction, and naming both up front answers most of the question: GRBL is a deliberate subset small enough to run on a microcontroller, LinuxCNC is a full standard implementation with extensions running on a PC, and programs flow down the size gap cleanly while flowing up it only with care. The asymmetry is the whole topic.
What each one is
GRBL was built to fit on an Arduino-class chip, and its design philosophy was to do the core perfectly rather than everything partially: motion (G0-G3), planes and units, distance modes, feed and spindle control, a compact M-code set, and explicitly not canned cycles, subroutines, or the industrial tool-length-offset table. LinuxCNC is the opposite end: a full RS-274/NGC implementation with O-word subroutines, dot-one extensions, and the whole canned-cycle and offset apparatus, the differences-versus-Fanuc map covers its upper reaches. Between them sits the standard core both implement identically, which is where the compatibility lives.
The scale of the gap is worth a number: GRBL fits in tens of kilobytes on a chip that costs a few dollars, while LinuxCNC runs on a full PC with gigabytes of memory and real-time extensions. That is roughly six orders of magnitude of resource difference, and it explains everything about the compatibility story, GRBL could not carry the cycle expander, the subroutine machinery, and the offset-table workflow even if its authors wanted to, so it pushed that work upstream to CAM and kept the part that has to run in hard real time on the chip: turning G-code into motion, accurately, now.
The direction that matters
| Direction | How it goes | Why |
|---|---|---|
| GRBL program to LinuxCNC | Almost untouched | LinuxCNC is effectively a superset |
| LinuxCNC program to GRBL | Only if it stayed in GRBL’s subset | GRBL lacks cycles, subroutines, offset tables, extensions |
| Either, core-only | Cleanly both ways | The shared majority is identical |
The rule that falls out is a planning rule: if a file must run on GRBL, write it to GRBL’s subset from the start, the same discipline as targeting any smaller dialect in a mixed fleet. A LinuxCNC program leaning on a G81 cycle or an O-word loop is not portable down until those are expanded into plain moves, which is exactly the job CAM does.
How GRBL machines still do everything
The subset sounds limiting until you see the workflow: CAM software expands canned cycles into explicit motion at post time, so a GRBL router still drills a bolt pattern, the G81 cycle just arrives as a sequence of plain rapids and feeds the controller runs without knowing it was ever a cycle. Subroutines get unrolled the same way. The controller stays simple; the complexity moves upstream to the PC running CAM, which is the entire architectural bet GRBL made, and it works because hobby and light-duty machines, the GRBL world, are overwhelmingly CAM-driven anyway, the pick-the-post-by-controller rule handling the expansion transparently.
Reading a GRBL file reflects this: it is all explicit moves, no cycle shorthand, the GRBL-file fingerprints being exactly that flatness, and its supported set is published in the wiki’s command list as the dialect authority.
The learning angle
For anyone starting on GRBL, the reassurance is structural: the core you learn is standard and complete, and the features GRBL omits are additions waiting on bigger controls, not habits to unlearn. Canned cycles, subroutines, offset tables, they extend what you know rather than contradict it, so the GRBL hobbyist who drills the full core, the free 60-second rounds on the G-code practice page include the cycles GRBL expands away, arrives at an industrial LinuxCNC or Fanuc machine fluent in the shared majority and ready to add the rest. The size gap that defines the compatibility also defines the growth path: start in the subset, expand into the superset, and the core never changes underneath you.
Sources
Frequently asked questions
Are GRBL and LinuxCNC G-code compatible?
Mostly one direction: GRBL is a subset and LinuxCNC a full implementation plus extensions, so GRBL programs run on LinuxCNC almost untouched while LinuxCNC programs run on GRBL only if they avoided canned cycles, subroutines, offset tables, and the extensions. Write to GRBL’s subset if a file must travel down.
What does GRBL not support that LinuxCNC does?
Canned cycles, subroutines and loops, the full tool-length-offset workflow, and LinuxCNC’s extensions like G33.1 and the dot-one modes. GRBL keeps the core that does most cutting and expects CAM to expand cycles into plain moves.
Why is GRBL a subset instead of a full implementation?
Because it runs on a small microcontroller with tight memory, and chose to do the core perfectly rather than everything partially. CAM expands canned cycles into explicit moves at post time, so GRBL machines still drill patterns.
If I learn G-code on a GRBL machine, does it transfer?
The core transfers completely, and GRBL’s omissions are additions waiting on bigger controls, not things to unlearn. The free G-Code Sprint app drills the full core including the cycles GRBL expands away.