This comparison matters more than most dialect pairs because of who makes it: learners running LinuxCNC’s free simulator while preparing for shops full of Fanuc iron, and retrofit owners moving programs between worlds. The honest map has three regions: a shared core bigger than either side’s marketing suggests, a structural layer where the families organize cleverness differently, and the usual scattering of per-dialect edges.
The shared core, which is the majority
Motion, planes, units, distance modes, the G54 offset family, G41-G43 compensation, the common drilling cycles, the everyday M spine: identical in reading and writing across both. This is the region the whole controller world converged on, LinuxCNC implementing the standard deliberately from the NIST RS-274/NGC lineage, and it is why the free dialect works as a classroom for the industrial one: the core drilled on a simulator at home reads straight onto the VMC at work.
The structural layer, where they genuinely differ
| Job | LinuxCNC | Fanuc family |
|---|---|---|
| Subprograms and logic | O-words: subroutines, loops, conditionals | Macro B (# variables, IF/GOTO) plus M98/M99 calls |
| Variables | Named and numbered parameters | # variables in numbered ranges |
| Rigid tapping | G33.1 | M29 with G84 |
| Reference position setting | G28.1 stores it | Parameter-side, per machine |
| Arc-center interpretation | G90.1/G91.1 select absolute/incremental IJK | Convention per control, incremental typical |
| Writing offset tables from code | G10 L-codes, documented | G10 exists with its own forms and limits |
| Path-control fine print | G61/G61.1/G64 with tolerance | Per-control lookahead and modes |
The top rows carry the real relearning: a program’s intelligence lives in O-word structure on one side and Macro B on the other, and the two do not translate mechanically, logic gets rebuilt per family, the same boundary every Siemens comparison draws at R-parameters. The middle rows are spelling differences for identical jobs: rigid tapping’s two spellings are the cleanest example, same synchronization, different arming code.
A worked taste of the structural difference: a five-times-repeated pocket runs as O100 repeat [5] ... O100 endrepeat with readable structure on LinuxCNC, and as a counted M98 P-call to a subprogram, or a Macro B WHILE loop over a # counter, on Fanuc. Both express the same plan; neither file means anything to the other control; and a programmer fluent in either learns the other’s structure in days precisely because the underlying plan-shapes, repeat, branch, parameterize, are identical.
The edges, briefly
Canned-cycle parameter fine print differs per the usual rules; M-codes above the spine belong to the machine builder on Fanuc and to your own configuration on LinuxCNC, which is the deepest cultural difference in practice: the Fanuc world’s edges are documented by whoever built the machine, the LinuxCNC world’s by whoever built the config, possibly you. Strictness culture rides along: Fanuc’s decimal conventions and alarm philosophy versus LinuxCNC’s documented-but-different parsing, the usual porting checkpoints applying in both directions.
Using the asymmetry
The pair’s friendliest property is pedagogical: one side is free, simulable on any PC, and documented in public, and it teaches the majority region perfectly. The working plan for a Fanuc-bound learner: build the core on LinuxCNC’s simulator, drill it to recall with the free 60-second rounds on the G-code practice page, read the structural layer as two dialects of one idea, and arrive at the Fanuc shop with weeks of edges to learn instead of a language. Programs port with the same map: core travels, structure rebuilds, edges get the manual, and the comparison that looked like a versus turns out to be a curriculum.
Sources
Frequently asked questions
What are the main G-code differences between LinuxCNC and Fanuc?
The core is shared completely; the differences concentrate in structure and extensions: O-word subroutines versus Macro B with M98/M99, LinuxCNC’s documented dot-one extensions, G10 table-writing forms, plus the usual cycle fine print and M-code ownership rules.
Can LinuxCNC run Fanuc programs?
Core-only programs largely yes, with standard porting care. Macro B logic, Fanuc-specific cycle parameters, and builder M-codes get rebuilt rather than trusted, and the reverse porting follows the same map.
Is learning on LinuxCNC good preparation for Fanuc shops?
Genuinely good: the core reads straight onto Fanuc iron, and LinuxCNC’s free simulator and public docs make it the best no-cost classroom for it. Budget the structural layer and strictness culture as new.
Why does LinuxCNC have codes Fanuc lacks, like G33.1 or G28.1?
Different lineages solving the same problems: LinuxCNC extended the NIST RS-274/NGC specification with documented dot-one variants; Fanuc evolved its own spellings, often parameter-side. Same jobs, diverged spellings.