Same coordinates, different reference — and the tool ends up somewhere else entirely
G90 says coordinates are absolute — measured from the work origin. G91 says they’re incremental — measured from where the tool is now. The numbers in the program can be identical; what they mean depends entirely on which mode is active. Run a block of absolute moves in incremental mode, or the reverse, and every position is referenced from the wrong place. The tool doesn’t do something slightly off — it goes somewhere entirely different: a rapid across the machine, a move doubled back on itself, a drift that accumulates with every line until the tool is nowhere near where the program says.
It’s one of the purest “valid code, wrong result” errors there is. There’s no syntax problem — G90, G91, and the coordinates are all legal. The mistake is in the reference frame the control reads them in, which is invisible in the numbers and easy to leave in the wrong state.
How the mode mix-up happens
- A modal mode carried over. G90/G91 is modal — set once and it stays. An incremental block left active governs the absolute moves that follow, or vice versa.
- A subprogram that assumes a mode. A called routine written for one mode, entered while the other is active, runs all its moves against the wrong reference.
- Copied blocks between programs. A block written incremental, pasted into an absolute program (or the reverse), brings its assumed mode with it.
- Lathe U/W vs X/Z confusion. On lathes, X/Z are absolute and U/W are the incremental counterparts. Mixing them — or assuming incremental where absolute was meant — shifts the move.
- Incremental cumulative drift. In incremental mode, every position builds on the last, so a single wrong increment doesn’t just misplace one move — it offsets everything after it.
Each runs as valid G-code. The reference frame is simply wrong, and the tool goes where the wrong frame sends it.
Why the listing and CAM simulation miss it
The numbers look right. A coordinate is a coordinate; whether it’s referenced from the origin or from the current position isn’t visible in the value. Scanning the listing, the moves look plausible — until you realize the active mode reads them the wrong way.
CAM renders its intended mode. A CAM outputs and simulates the program in the mode it intended, so it looks correct. The mismatch appears only when the real program runs under the control’s active mode — after an edit, a copied block, or a subprogram that inherited the wrong state. A toolpath render of the CAM’s plan doesn’t reproduce that runtime reference frame.
Catching it needs the real ISO executed the way the control reads it, mode state and all, on a twin of the machine.
Where Eureka G-Code fits
Eureka G-Code executes the true ISO on a digital twin of your machine and controller, interpreting G90/G91 (and lathe X/Z vs U/W) the way the control will — so the tool moves against the reference frame the control actually uses. An absolute block run incremental, an incremental subprogram entered in absolute, a copied block that brought the wrong mode, a cumulative drift: each shows up as the tool going somewhere plainly wrong — a wild rapid, a doubled move — caught as a collision, near-miss, or overtravel, or as a machined result that doesn’t match the model. What hides in a listing because the numbers look fine becomes obvious in a controller-accurate run.
Because it reads the real ISO regardless of origin, a mode error introduced by a hand edit, a copied block, or an inherited subprogram state is caught exactly as the control will execute it — on any controller and kinematics.
> Take a program built from copied blocks or subprograms — the kind where a mode could easily be inherited wrong — and run the real ISO on a twin of your machine in Eureka G-Code. If a move is referenced from the wrong frame, you’ll see the tool jump instantly, on the twin, instead of at full rapid on the machine.
FAQ
What's the difference between G90 and G91?
G90 is absolute mode — coordinates are measured from the work origin. G91 is incremental mode — coordinates are measured from the tool’s current position. The same numbers mean different destinations depending on which mode is active.
What happens if I run an absolute program in incremental mode?
Every move is referenced from the current position instead of the origin, so the tool goes somewhere entirely different — a wild rapid, a doubled move, or a drift that accumulates with each line. The code is valid; the reference frame is wrong.
Why is incremental mode especially prone to cumulative errors?
Because every position builds on the previous one. A single wrong increment doesn’t just misplace one move — it offsets every move after it, so the error grows through the rest of the program.
How do U and W relate to this on a lathe?
On lathes, X/Z are absolute and U/W are their incremental counterparts. Mixing them, or assuming incremental where absolute was intended, shifts the move — the same class of reference-frame error.
How does Eureka G-Code catch it?
It executes the real ISO on a twin and interprets G90/G91 (and X/Z vs U/W) the way the control will, so a move against the wrong reference frame shows up as an obviously wrong motion — a collision, near-miss, overtravel, or a part that doesn’t match the model.
Next step
Eureka G-Code — request a demonstration on a digital twin of your own machine and controller.
Run the real ISO on a twin — and see the moves resolve against the reference frame the control will actually use.