The Blind Absolute Z Rapid: The Most Dangerous Line in CNC

One rapid move, at full speed, to a depth the programmer assumed was safe

Ask a room of machinists for the single most dangerous line of G-code, and a lot of them will point at the same thing: a rapid to an absolute Z, written on the assumption that "Z will be up here" — when the machine actually reads it as "drive down there, now, at full speed." A rapid (G00) doesn't feed gently to position; it slams there as fast as the axis moves. Aim it at the wrong Z and there's no time to react — the crash is over before the operator's hand reaches the feed hold.

What makes it so dangerous isn't the line itself. It's that whether that same line is safe or catastrophic depends on several things sitting outside the line — the active offset, the tool length, where Z-zero was set — none of which you can see by reading it.

Why the same rapid is safe one day and a crash the next

A rapid to an absolute Z resolves to a real machine position only after the control combines several pieces of state. Get any of them wrong and the destination moves — often straight into the part or table:

• Wrong or missing work offset. The Z the programmer pictured was relative to the top of the part. If the active work offset is wrong, or a different G54–G59 is live than intended, "up here" becomes "down there."
• Missing tool-length offset. If the rapid happens before G43 H__ activates tool length, the control positions as if there were no tool — so a rapid that should clear the part instead drives the tool tip down into it. (This is the cousin of the "G43 called after the Z move" mistake.)
• Z-zero set on the table instead of the part. If part-zero is referenced to the machine table rather than the top of the stock, every Z in the program is off by the stock height — and a rapid clears nothing.
• Absolute mode assumption. The programmer thought incremental; the control is in G90. The number that was meant as "move up a bit" becomes "go to this absolute depth."

In every case the number in the program is exactly what the programmer typed. It's the state the control resolves it against that's wrong — and that state lives in offsets and modal flags, not on the rapid line.

Why reading the program — and a dry run — don't save you

The line looks correct. There's no syntax error. A rapid to an absolute Z is legal and routine; the danger is entirely in the surrounding state, which a read-through of that one line can't reveal.

A dry run above the part hides it. Running the program in the air, or with the Z shifted up, is the standard floor check — and it's exactly blind to this failure, because the whole problem is where Z-zero really is relative to the part. Lift everything up and the crash disappears from the test and reappears the moment you run for real.

CAM sim shows the intended offset. If the program came from CAM, its simulation uses the CAM's assumed offsets and tool lengths — so it looks fine. The crash only appears when the real program runs against the real offsets and tool-length state the control will actually use.

Where Eureka 3X Pro fits

Eureka 3X Pro simulates the posted or hand-written program against a controller-accurate twin, resolving every rapid the way the control will — against the active work offset, the tool-length state, the real Z-zero relative to your stock, and the actual G90/G91 mode. A blind absolute Z rapid that would drive into the part or fixture doesn't stay hidden the way it does in a dry run: on the twin, with your real stock and fixtures in place, the tool visibly plunges where it shouldn't, before it does it for real at rapid on the machine.

This is the archetypal crash where the dangerous thing isn't in the line you're looking at — it's in the offsets and modal state around it. Catching it needs exactly what controller emulation provides: the real offset and tool-length resolution, the real Z reference, and the real fixture to hit. For a Fusion or Mastercam user, those offsets, tools, stock, and fixtures come across automatically through the cascade post, so the rapid is verified against your real setup rather than an assumed one.

Take a program and watch its first Z rapid of every tool — the approach moves, the moves right after each tool change — on a twin with your stock and fixtures in place. Seeing whether "rapid to Z" actually clears the part, before it runs, 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 did my program crash on a rapid move that looked fine? Because a rapid to an absolute Z resolves against the active work offset, tool-length state, and Z reference — and if any of those is wrong, the tool drives to a depth the line didn't reveal. The number you typed was right; the state the control resolved it against was wrong.

Why does it run fine in air but crash on material? The classic cause is a missing tool-length offset on the first Z move, or a Z-zero referenced to the table instead of the part. In the air, or with Z lifted, the error is invisible; on material, the tool rapids straight into the part.

Why doesn't a dry run catch it? Because a dry run raises Z or runs above the part — and this failure is specifically about where Z-zero really sits relative to the part. Lifting everything up removes the very condition that causes the crash.

How does Eureka 3X Pro catch it when a dry run can't? It resolves the rapid against the real offsets, tool length, and Z reference on a controller-accurate twin, with your real stock and fixture in place — so the plunge shows up in simulation exactly as it would on the machine, without lifting anything.

Does it work on hand-written programs? Yes. It reads the actual .nc and resolves rapids against the real modal and offset state regardless of how the program was produced.

Note: safe rapid practice (activating tool length before the first Z move, verifying the active offset, retracting in incremental mode) varies by shop and control. The reliable check is to run the real program against the real control state and fixture before cutting.

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