G92 is the old way to set a part zero: park the tool somewhere known and
declare it. G92 X0 Y0 Z25 means "from now on, call this position
X0 Y0 Z25" — the control back-computes an offset and applies it
globally. No axes move.
It predates stored work offsets, and on hand-cranked or unhomed machines it was the only option. On a modern homed machine it survives mostly as a source of mystery shifts — because of two properties:
- It stacks. The G92 shift adds on top of the active
G54–G59offset — and stays applied when you switch to another work system. Every fixture on the table moves together. - It lingers. The shift persists across program end and reset on many controls — FANUC stores it in parameters that survive power-down. The next program inherits it invisibly.
G54 G0 X0 Y0 ; tool over G54 zero: readout says X0 Y0
G92 X10 ; declare "this is X10" — a −10 shift now exists
G55 G0 X0 Y0 ; even in G55, everything is shifted by −10
G92.1 ; clear it; sanity restored
#Where G92 still earns its place
- Axes that can't home. A 3D printer's extruder (
G92 E0before every retract block) or a rotary axis treated as endless. - Unhomed hobby setups where "zero is where I jogged it" is the entire
workflow — GRBL's
G92exists for exactly this. - Temporary shifts inside a program on controls without
G52local offsets — though ifG52exists, it's the better-behaved tool.
If the machine homes and the control has work offsets, the modern rule is blunt: set G54, don't set G92.
| Operation | LinuxCNC | GRBL | Centroid | FANUC | Mach3 | Mach4 | Notes |
|---|---|---|---|---|---|---|---|
| Set position / coordinate offset | G92 |
G92 |
G92 |
G92 |
G92 |
G92 |
FANUC has G92.1 / G92.2 to clear or restore; Mach has G92.1. |
— means the control has no equivalent code. Full cross-control tables: the complete G-code & M-code reference.
#Debugging a mystery shift
Parts cutting consistently off-location by the same amount, with correct work offsets, is the G92 signature. The checklist:
- Look at the control's offset/parameter screen for nonzero G92 values.
- Clear with
G92.1(or zero the parameters). - Find the program that set it — usually a hand-written probe or setup
routine — and replace the
G92withG10 L20writing to a real work offset.
A simulator that tracks the full offset stack shows a G92 shift the moment it happens, instead of after the third scrapped part.
#Common mistakes
- Using G92 to "touch off" on a homed machine. It works until anything
— a different program, a reset behavior difference — reveals the shift
was global and persistent.
G10 L20 P1 X0(write to G54) is the intended tool. - Assuming reset clears it. Control-dependent; FANUC's survives
power-down. Only
G92.1(or zeroing the parameters) is definitive. - Mixing G92 into a multi-fixture job. The shift drags every G54–G59 system with it — the second vise is now wrong too, which makes the symptom look like a machine problem instead of a program one.