The arc was right — it just swung in the wrong plane
G17, G18, and G19 select the working plane: G17 is XY, G18 is ZX, G19 is YZ. It’s a setting most programmers set once and never think about — which is exactly why it bites. The plane decides how a circular move (G02/G03) is interpreted and which axis a canned cycle drills along. Get it wrong and the code is still valid, the arc still runs, the cycle still executes — just in the wrong plane, swinging the tool through the part or plunging along an axis you never meant. The radius is right, the endpoints are right, the plane is wrong, and nothing in the numbers looks off.
It’s an easy mistake because the default differs by machine and the setting is modal. Mills default to G17; lathes to G18. Code moved between them, a subprogram that assumes a plane it doesn’t command, a hand edit that drops the plane word — and the arcs and cycles quietly execute in the wrong orientation.
How plane errors happen — and what they do
- Wrong plane for a circular move. An arc meant for XY, executed under G18, swings through ZX instead — the tool arcs into the part or off into space. Same radius, same feed, wrong plane.
- Canned cycle drilling the wrong axis. Drilling cycles are referenced to the active plane. The wrong plane can point the cycle’s depth axis the wrong way.
- A modal plane carried over. Plane selection is modal; a G18 left active from an earlier operation governs a later one that assumed G17.
- Code moved between a mill and a lathe. With different default planes, a program that was correct on one runs its arcs and cycles in the wrong plane on the other.
- A subprogram that assumes a plane. A called routine that doesn’t set its own plane inherits whatever was active — which may not be what it was written for.
The through-line: the geometry the programmer pictured is a plane away from the geometry the control executes.
Why the listing and CAM simulation miss it
It reads as valid. G17, G18, G19 are all legal; an arc under any of them is legal. There’s no syntax error — the plane is simply the wrong choice for the move, and a scan of the code shows plausible coordinates.
CAM renders its own intended plane. If the program came from CAM, the CAM simulates the arc in the plane it intended, so it looks correct. The mismatch only appears when the real program runs under the control’s active plane — after edits, after a subprogram inherited the wrong modal state, after the code moved to a different machine. A toolpath render of the CAM’s plan doesn’t reproduce that.
Catching it needs the real ISO executed the way the control interprets it, plane 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 the active plane the way the control will — so an arc or a cycle in the wrong plane isn’t hidden, it’s the most obvious thing on screen. The circular move that swings through the part instead of across it, the drilling cycle pointed the wrong way, the modal G18 carried into an operation that assumed G17 — each shows up as a tool going somewhere plainly wrong: a collision or near-miss, or a machined result that doesn’t match the model. What’s nearly impossible to spot in a listing becomes impossible to miss in a controller-accurate run.
Because it reads the real ISO regardless of origin, a plane error introduced by a hand edit, a subprogram’s inherited state, or code moved between a mill and a lathe is caught exactly as the control will execute it — on any controller and kinematics.
> Take a program with a lot of arcs or drilling cycles — especially one moved between machines or built from subprograms — and run the real ISO on a twin of your machine in Eureka G-Code. If a plane is wrong, you’ll see the arc swing wrong instantly, on the twin, instead of into the part on the machine.
FAQ
What do G17, G18, and G19 do?
They select the working plane: G17 is XY, G18 is ZX, G19 is YZ. The active plane decides how circular moves (G02/G03) are interpreted and which axis canned cycles reference — so the wrong plane executes arcs and cycles in the wrong orientation.
Why did my arc cut in the wrong plane?
Almost always a wrong or carried-over plane selection. The arc’s radius and endpoints can be correct while the active plane is wrong, so the move swings through the wrong plane — valid code, wrong geometry.
Why is this common when moving code between machines?
Because the default plane differs — mills default to G17, lathes to G18 — and the setting is modal. A program correct on one machine can run its arcs and cycles in the wrong plane on the other if the plane isn’t explicitly commanded.
Why doesn't CAM simulation catch it?
CAM renders the arc in the plane it intended, so it looks right. The mismatch only appears when the real program runs under the control’s active plane — after edits or an inherited subprogram state — which a toolpath render of the CAM’s plan doesn’t reproduce.
How does Eureka G-Code reveal it?
It executes the real ISO on a twin and interprets the active plane the way the control will, so an arc or cycle in the wrong plane shows up as an obviously wrong motion — a collision, near-miss, 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 arc swing in the plane the control will actually use.