The G28 Trap: How "Go Home" Drills Straight Into Your Part

The command that's supposed to move the tool to safety is one of the most common ways to crash

G28 looks like the safest line in the program. It means "return to the machine reference point" — go home, get clear, nothing to worry about. And that's exactly why it crashes so many machines: it reads as a safety move, so it gets written on autopilot, and the one detail that makes it dangerous gets skipped. On 3-axis mills, a mis-written G28 is one of the most common sources of crashes there is.

The reason is a piece of behavior most people forget: G28 does not go straight home. It routes through an intermediate point first — and where that point lands depends on a mode word sitting somewhere else in the program.

Why G28 crashes: the intermediate-point trap

G28 executes in two moves: first to an intermediate position you specify on the G28 line, then from there to machine zero. The trap is how that intermediate point gets interpreted — and that depends on whether the control is in absolute (G90) or incremental (G91) mode:

• G91 G28 Z0 — incremental. "Move Z zero distance from where you are, then go home." The tool lifts straight up to the reference point. Safe.
• G90 G28 Z0 — absolute. "Move to Z work-zero first, then go home." If the tool is above the part (it almost always is), the machine drives it down to the work-zero plane — into the part or the fixture — before heading home.

Same three characters after G28. One mode word difference. One version retracts to safety; the other plunges the tool into whatever is clamped on the table. And because G90/G91 is modal — set once and carried forward — the dangerous mode is often inherited from somewhere else entirely, not visible on the G28 line at all.

The ways it bites

This single mechanism shows up in several everyday forms:

• Wrong active mode. The program is in G90 when it hits a G28 Z0, and down it goes. The programmer never wrote anything obviously wrong on the G28 line — the danger was in the modal state around it.
• Homing X and Y with the tool still down. G28 X0 Y0 before retracting Z drags the tool across the part on the way out. The safe pattern retracts Z first, then homes X and Y — but a single combined G28 X0 Y0 Z0 can pull the tool through the work.
• Mode not restored afterward. A G91 G28 block that forgets the G90 after it leaves the whole program in incremental mode, so the next operation's first move rapids somewhere unintended.
• Post-processor and hand-edit variation. Different posts emit different G28 patterns, and hand-added home moves at the control are easy to write in the wrong mode. What runs isn't always what a clean post would have produced.

In every case the line looks like a routine home move. The crash is in how the control resolves it against the active mode and the real fixture — not in anything a quick read reveals.

Why reading the program doesn't protect you

G28 Z0 is valid G-code in both modes — there's no syntax error to flag, and the character string is identical whether it's safe or catastrophic. The difference is the modal state carried in from earlier lines, which you can't see by looking at the G28 line alone. And whether the resulting plunge actually hits something depends on the part and fixture on the table — geometry a text listing doesn't contain.

If you program through CAM, its simulation runs on its own toolpath and its own assumptions — it may not reproduce the exact G28 pattern in the posted program after edits, and it may not have the real fixture in place to collide with. The move that matters is the one the control executes, in its actual mode, over the real fixture.

Where Eureka 3X Pro fits

Eureka 3X Pro simulates the posted or hand-written program against a controller-accurate twin, executing G28 exactly as the control will — resolving the intermediate point against the active G90/G91 mode, tracking the modal state carried in from earlier in the program, with your real stock and fixtures in the scene. The G90 G28 Z0 that would plunge into the vise, the combined home move that drags across the part, the missing G90 that corrupts the next operation: all of them show up on the twin, before the tool moves for real.

This is the archetypal "looks like a safety line, is actually a crash" error — and catching it needs exactly what controller-accurate emulation provides: the real modal state and the real fixture, not a toolpath drawn in isolation. For a Fusion or Mastercam user, the fixtures and setup come across automatically through the cascade post, so the home move is verified over your real clamps rather than an empty table.

Take a program and watch its G28 moves execute — the header return, the tool-change retracts, the footer home — on a twin with your fixture in place. Seeing whether "go home" actually goes up, before it runs for real, is how this crash gets caught at a desk instead of on the spindle.

Eureka 3X Pro — 30-day free trial, no credit card required.

FAQ

Why does G28 crash into the part? Because G28 goes home via an intermediate point, and in absolute mode (G90) that point is interpreted at work coordinates. G90 G28 Z0 tells the machine to move to work-zero Z first — downward, into the part or fixture — before going home. The tool crashes on the way to a command that was supposed to move it to safety.

What's the safe way to write G28? Use incremental mode: G91 G28 Z0 moves zero distance from the current position, then homes, so the tool lifts straight up. Retract Z first, then home X and Y if needed, and restore G90 afterward. The exact safe pattern can vary by control — check your machine's manual.

Why is Z0 sometimes safe and sometimes a crash with the same G28 Z0 line? Because the behavior depends on the active G90/G91 mode, which is modal and often set earlier in the program. The identical G28 Z0 line lifts to safety in incremental mode and plunges to work-zero in absolute mode.

Will collision detection catch a bad G28? Yes — if the simulation runs the real program in its actual modal state with the real fixture in place. That's the catch: it depends on emulating the control's mode and having the fixture modeled, which is what Eureka 3X Pro does and a toolpath-only simulation may not.

Does it catch G28 problems in hand-edited programs? Yes. It reads the actual .nc and resolves G28 against the real modal state, so a home move written or edited in the wrong mode is caught regardless of origin.

Note: G28 behavior and the safest return pattern vary by control. The point that holds everywhere: whether G28 goes up or down depends on modal state you can't see on the G28 line, so verifying it against the real control and fixture is the reliable check.

Run every G-code program risk-free — before it touches your machine.