Once you've rotated the frame, "up" isn't machine-up anymore — and the retract is where that bites
Rotating the coordinate system — a 2D origin rotation (G68), a tilted working plane for 5-axis work (G68.2, Siemens CYCLE800, Heidenhain PLANE) — is what lets you program a feature in its own natural frame instead of wrestling with compound angles. It’s enormously useful. It also quietly changes the meaning of every axis word that follows: Z+ is no longer “straight up out of the part,” it’s “up in the rotated frame,” which can point sideways into the material, or even down into it. Most of the program is fine with that — the cutting is supposed to happen in the rotated frame. The place it goes wrong is the retract: the move meant to disengage the tool and clear the part.
Get the retract’s axis order or frame wrong after a rotation and the head doesn’t lift away — it drives into the workpiece, the fixture, or the clamps during what was supposed to be the safe move. It’s one of the more common ways a 5-axis or rotated-plane program crashes, and it happens on the move everyone assumes is harmless.
How the retract goes wrong
- Retracting along the rotated Z instead of the tool/machine axis. Z+ in the active rotated frame may not point away from the part. A “lift off” that’s along the rotated Z can carry the tool across or into the surface instead of clear of it.
- Wrong axis order. Moving X/Y (in the rotated frame) before lifting sweeps the tool across the part; the safe sequence is usually to clear along the tool axis first, then reposition. Reverse it and the tool ploughs the surface.
- Not cancelling the rotation before a machine-referenced retract. A retract meant to go to a safe machine position (G53) behaves differently while a rotation or tilted plane is still active. Leaving the rotation on — or cancelling it at the wrong moment — sends the “safe” move somewhere unsafe.
- Assuming the CAM’s retract will survive the post. The strategy that was safe in the CAM’s frame can be posted into real rotation/kinematics where the same words move the head differently.
- A modal rotation carried into the next operation. A rotation left active governs a later move — including its retract — that assumed the unrotated frame.
Every one of these is valid code. The tool just goes the wrong way on the one move where “the wrong way” means into the part.
Why a listing and CAM simulation miss it
It isn’t a geometry error. The retract coordinates are perfectly legal; whether they clear depends on the active frame, the machine’s kinematics, and the order of the moves — none of which is visible by reading the line. Z+ looks like “up” on the page even when the active rotation has made it something else.
CAM shows its own plan in its own frame. A CAM simulates the retract it generated, in the frame and kinematics it assumed — not necessarily the real posted rotation the control executes on the real machine. If the post, the rotation handling, or the kinematics differ, the retract that looked safe in the CAM crashes on the floor. And a rotation left modal, or cancelled at the wrong point, is control-side state a toolpath render doesn’t reproduce.
Catching it needs the real program executed the way the control applies the rotation, on a twin of the actual machine and kinematics — retract order and all.
The close cousin: arcs in the wrong plane
The same “the active frame isn’t what the command assumes” trap shows up in circular interpolation: a G02/G03 arc executes in whatever working plane (G17/G18/G19) is active, so if the wrong plane is active — or a modal plane carried over — the arc swings in the wrong plane and the tool arcs into the part. It’s the same family of error as the rotated retract: valid code, wrong active frame. It has its own dedicated write-up: Plane Selection Errors (G17/G18/G19).
Where Eureka G-Code fits
Eureka G-Code executes the real ISO on a digital twin of your machine and kinematics, applying the coordinate rotation and tilted working plane the way the control does — so the retract runs on the twin in the real frame, in the real order. A Z+ that points into the part after a rotation, an X/Y that sweeps the surface before the tool has cleared, a machine-referenced retract run with the rotation still active: each shows up as a collision or near-miss on the twin, before the head finds the part on the machine. Because it reproduces the real kinematics, the retract is verified as your machine will actually move — not as an idealized frame assumes.
In the same run it catches the related active-frame errors — the arc in the wrong plane, the modal rotation carried into the next operation — plus overtravel and part-vs-model, whatever produced the program: posted from CAM, generated by Eureka NC Coder, or hand-edited. On rotated-plane and 5-axis work, that’s the difference between a retract that “looks safe” and one you’ve watched clear the part.
> Take a program with a tilted plane or a coordinate rotation — one that rotates the frame to machine a feature and then retracts — and run the real ISO on a twin of your machine in Eureka G-Code. Watching the retract clear the part in the real rotated frame, before the head does it for real, is how a rotation-retract crash gets caught at a desk.
FAQ
Why does my machine crash on the retract after a coordinate rotation?
Because the rotation changed what the axis words mean: Z+ is “up in the rotated frame,” which may point into the part rather than away from it. A retract programmed in that frame, or with the wrong axis order, drives the head into the workpiece instead of clearing it — valid code, wrong direction, on the move meant to be safe.
What's the safe way to retract after a rotation or tilted plane?
Generally, clear along the tool axis first, then reposition — and be deliberate about when the rotation is cancelled and when a machine-referenced retract (G53) is used, since those behave differently while a rotation is active. The reliable check is to run the real program on a twin and watch the retract actually clear.
Why doesn't CAM simulation catch it?
CAM simulates the retract it generated in its own frame and kinematics, not necessarily the real posted rotation the control executes on the real machine. If the post or kinematics differ, or a rotation is left modal, the retract that looked safe in the CAM crashes on the floor — which only appears when the real program runs on a twin.
Is this the same as an arc in the wrong plane?
It’s the same family of error — the active coordinate frame isn’t what the command assumes — but a different symptom. The rotated retract crashes on a disengage move; the wrong-plane arc swings a G02/G03 in the wrong plane. Both are caught by executing the real ISO on a twin.
Does Eureka G-Code handle tilted planes and 5-axis rotations?
Yes. It applies coordinate rotations and tilted working planes (G68/G68.2, CYCLE800, PLANE) the way the control does, on a twin of the real kinematics, so a wrong retract order or direction after a rotation shows up as a collision, near-miss, or overtravel before the machine runs.
Next step
Request a demonstration on a digital twin of your own machine
Run the real ISO in the real rotated frame — on a twin of your machine — and watch the retract clear the part before the head does it for real.