The offset is applied by the control, not the CAM — so the CAM's picture can't show the mistake
G43 applies tool-length compensation: it tells the control to shift the tool along Z by the length offset stored under an H number, so the program’s Z coordinates land at the tool tip. It’s one of the most routine lines in any milling program — and one of the most invisible when it’s wrong. A wrong H number, a missing G43, an offset value that doesn’t match the tool in the pocket, a G43 never cancelled: any of these drives the tool to a Z the program never intended, and the CAM’s verification never flagged it. Not because the CAM is weak, but because a G43 error isn’t a geometry problem — and geometry is all a CAM simulation checks.
The CAM assumes every tool is the length it was told, mounted where it should be, with the right offset selected. Its simulation renders the toolpath on that assumption. The one thing that can break the assumption — the offset the control actually applies at runtime — is the one thing the CAM’s picture doesn’t contain.
How G43 goes wrong
Each of these is valid code that runs — and puts the tool somewhere the toolpath never showed:
- Wrong H number. G43 H05 when the tool is offset 6 applies the wrong length, shifting every Z in that operation up or down by the difference. Too short and you crash into the part or fixture; too long and you cut air.
- Missing G43 entirely. Program the moves but forget to invoke compensation, and the control runs the raw coordinates with no length applied — the tool plunges by the whole tool length.
- Offset value doesn’t match the tool. The H number is right but the value stored under it is wrong (mis-measured, mistyped, left from another tool). The picture is perfect; the real Z is off by the error.
- G43 not cancelled (missing G49). Compensation left active into a move or tool that shouldn’t have it carries the offset where it doesn’t belong.
- G43 vs G44 confusion. The wrong sign of compensation shifts the tool the wrong way.
Every one of them looks correct on paper and in the CAM, because the numbers are all plausible — the error is in which offset the control applies, and to what.
Why CAM verification structurally can't catch it
It’s not geometry. A CAM simulation checks whether the toolpath collides or gouges given the tools and setup it knows about. A wrong H number doesn’t change the toolpath the CAM generated — it changes what the control does with it. There’s nothing geometrically wrong for the CAM to detect.
The offset lives on the control. The H table, the active offset, the G43/G49 modal state — these are control-side runtime facts. A CAM simulating its own toolpath has no reason to model them, and a stand-alone verifier that isn’t executing the real program with the real offset table can’t either.
So the mistake sits precisely in the gap between the program the CAM drew and the program the control runs. Closing that gap needs the real ISO executed the way the control executes it, with the offset it will actually apply.
Where Eureka G-Code fits
Eureka G-Code reads and executes the true ISO on a digital twin of your machine, and it applies tool-length (G43 H) and work offsets (G54–G59) the way the control will — with the offset table in play, the active H, the G43/G49 modal state. So the tool moves on the twin to the Z the control will actually drive it to, not the Z the toolpath assumed. A wrong H number, a missing G43, an offset that doesn’t match the tool, a compensation left active — each shows up as the tool going somewhere it shouldn’t: a collision or near-miss on the twin, or a machined result that doesn’t match the model.
Because it executes the real program regardless of origin — posted, hand-written, or edited at the control — it catches the offset errors that creep in exactly where a CAM never looks: in the hand edit, the wrong H, the setup change. On complex machines with many tools and offsets, that’s the difference between “the toolpath is correct” and “the control will actually put the tool where the program means.”
> Take a multi-tool program with a lot of length offsets — the kind where a wrong H would be easy to miss — and run the real ISO on a twin of your machine in Eureka G-Code. Watching the tool move to the Z the control will actually apply, before it does it for real, is how a G43 mistake gets caught at a desk.
FAQ
Why doesn't my CAM catch a wrong H number?
Because a wrong H doesn’t change the toolpath the CAM generated — it changes the offset the control applies to it at runtime. There’s nothing geometrically wrong for the CAM to detect; the tool goes to the wrong Z only when the control applies the wrong length.
What does a G43 error actually do?
It drives the tool to a Z the program never intended. A too-short offset (or missing G43) crashes the tool into the part or fixture; a too-long offset makes it cut air. Either way the toolpath looks correct — the real position is wrong by the offset error.
How does Eureka G-Code catch it?
It executes the real ISO on a twin of your machine and applies the tool-length and work offsets the way the control will, so the tool moves to the actual Z. A wrong H, a missing G43, a mismatched offset, or compensation left active shows up as a collision, near-miss, or a part that doesn’t match the model.
Does it also check work offsets (G54–G59)?
Yes. The wrong active work offset is the same class of error — not geometry, but what the control applies — and it’s caught the same way, because the twin runs the program under the real offsets.
Does it work for hand-edited programs?
Yes. It reads the actual ISO the control receives, so an offset error introduced by a hand edit at the machine is caught exactly as one in a posted program.
Next step
Eureka G-Code — request a demonstration on a digital twin of your own machine and controller.
Apply the real offsets the way the control will — on a digital twin — so the tool goes where the program means, not where the picture assumed.