GRBL runs more spindles than any industrial control ever will, one hobby machine at a time, and it does something most controls make you dig for: it publishes exactly which G-codes it implements, in its own documentation. This post is that list organized for learning, plus the part lists never explain: what the omissions mean for how you work.
The supported core, by job
| Job | Codes GRBL supports | Notes |
|---|---|---|
| Motion | G0, G1, G2, G3 | Full arcs with I/J/K or R |
| Dwell | G4 | P in seconds |
| Planes / units | G17-G19, G20/G21 | Standard meanings |
| Distance modes | G90, G91 (and G91.1) | Absolute / incremental |
| Feed modes | G93, G94 | Inverse time / units-per-minute |
| Work offsets | G54-G59, set via G10 L2/L20 | Six systems, G92 also present |
| Homing refs | G28, G30 (and setters G28.1/G30.1) | Stored positions |
| Tool length | G43.1, G49 | Dynamic TLO style |
| Probing | G38.2-G38.5 | The straight-probe family |
| Spindle / laser | M3, M4, M5 with S | M4 = dynamic power in laser mode |
| Coolant | M7 (option), M8, M9 | Pin-dependent on the board |
| Program | M0, M1, M2, M30 | Standard stops and ends |
If you learned the universal core anywhere, you already speak GRBL: the firmware is a faithful subset, which is precisely why it became the hobby world’s shared dialect and why reading a GRBL file feels like reading anything else, minus a few luxuries.
The famous omissions, and what they teach
No canned cycles: drilling a grid means explicit G0/G1 moves per hole, which CAM happily generates, the generator-script pattern covers parametrically, and nobody hand-types twice. No cutter radius compensation: G41/G42 are absent, so the toolpath must already be offset, which is why every hobby CAM posts compensated paths and the comp concept still matters for understanding what CAM did. No macros or variables: the Turing-complete layer simply is not there, logic lives in the sender or the generator. Each omission is the same design decision: keep the firmware’s real-time core small enough to run flawlessly on a microcontroller, and push planning upstream where computers are big. It is the industrial computation-placement principle implemented by necessity.
The $ layer: settings are not G-code
GRBL files stay clean because machine configuration lives in a separate dialect: the $$ settings ($110-class max rates, $32 laser mode), $H homing, and real-time characters (feed hold, cycle start) that senders inject. The practical division: G-code files describe the part, $ settings describe the machine, and the LightBurn-style console commands are the $ layer wearing a software UI. Mixing the layers in your head is the most common GRBL-beginner confusion, and unmixing them is one sentence: if it starts with $, it is not in the program.
Dialect notes for arrivals from industrial controls
Three adjustments. Tool changes: M6 is not meaningfully implemented on stock GRBL (no changer to drive), so multi-tool jobs are split files or sender-managed pauses. Tool length: G43.1’s dynamic style differs from industrial H-register habits, probing workflows fill the gap. And laser mode repurposes M3/M4 semantics in a way no industrial mill does: M4’s dynamic power scaling is GRBL’s own gift to clean engraving. None of these surprise anyone who checks the wiki first, which is the GRBL version of the read-the-manual rule this site repeats for every control.
Learning GRBL’s list efficiently
The list above is the universal core minus luxuries, so the study plan is unchanged: drill the core to reflex (free 60-second rounds on the G-code practice page, G-Code Sprint repeating misses), then read real posted files from your own CAM, noting where explicit moves replace the cycles industrial programs would use. Machine-specific behavior ($ settings, pin options like M7) belongs to your board’s documentation and the wiki, consulted rather than memorized, and the X-Carve-class machine guides show the same list wearing specific hardware, while multi-controller brands like Onefinity show why the list belongs to the controller rather than the logo.
Bottom line: a subset by design, documented with pride
GRBL supports the standard core (motion, arcs, offsets, probing, spindle and program control) and deliberately omits cycles, radius comp, and macros, pushing those jobs to CAM and senders so a microcontroller can execute flawlessly. The authoritative list is the firmware’s own wiki; the skill is the same universal core as everywhere; and the omissions, once understood, are the cleanest lesson in why simple controls stay reliable.
Sources
Frequently asked questions
What G-codes does GRBL support?
The standard core: G0-G3 motion with arcs, G4 dwell, planes and units, G90/G91, G54-G59 offsets with G10 setting, G28/G30 positions, G43.1 tool length, G38.x probing, and the standard M-codes including laser-mode M3/M4 behavior, per the official wiki’s list. Deliberately absent: canned cycles, G41/G42 radius comp, and macros. To get the shared core to reflex, the free G-Code Sprint app is the top pick: 60-second drills with automatic repetition of missed codes.
Why does GRBL not support canned cycles or G41/G42?
By design: the firmware keeps its real-time core small enough for flawless microcontroller execution and pushes planning upstream, so CAM posts explicit, pre-compensated moves. The omissions are why it is reliable, not what it lacks.
Are the $$ settings part of G-code?
No: $ commands are GRBL’s separate configuration dialect (rates, laser mode, homing), injected via the console or sender, never in program files. Program describes part; $ describes machine.
Does GRBL handle tool changes?
Not meaningfully on stock firmware: no changer hardware exists on its class of machines, so multi-tool jobs run as split files or sender-managed pauses with re-zeroing, per your sender’s workflow.
G-Code Sprint is a study and practice tool only. Always follow your machine’s documentation and shop safety procedures.