The one part of the program that changes everything after it — and the one part nobody simulates
Probing is quietly one of the highest-leverage things in a modern program and one of the least verified. A touch-probe cycle measures a surface, a bore, a datum — and then sets an offset at runtime that changes what every subsequent move does. Get the probing wrong and you don’t just lose the probe move; you shift the entire rest of the program by whatever the bad measurement fed into the offset. It’s the definition of a high-consequence operation, and it’s the part of the program a toolpath simulation skips entirely, because probing isn’t cutting.
So the cycle that governs the accuracy of everything after it typically reaches the machine having never been executed anywhere but in the programmer’s head.
How probing goes wrong
The failure modes split into two kinds — the probe that crashes, and the measurement that quietly corrupts the offset:
- Probe move into a fixture or the part. A rapid or approach that assumes clearance the setup doesn’t have drives the probe stylus into a clamp, the part, or a feature — an expensive break, and a stopped run.
- Probing the wrong surface, or missing it. A cycle aimed at the wrong location, or a protected move that never reaches the surface within its distance, either measures nothing or measures the wrong thing.
- A measurement that feeds a bad offset. The probe touches, but the resulting offset is wrong — wrong axis, wrong reference, wrong sign — and now every operation after it is shifted. Nothing crashes at the probe; the scrap shows up later, everywhere.
- Constructor probing cycles that don’t do what you assumed. Control-specific probing cycles have their own parameter conventions; a misread parameter changes the whole behavior of the measurement.
- A related check that’s just as invisible: the missing pre-hole for tapping. A tap commanded where no drill preceded it — because an operation was reordered, a subprogram skipped, or a hole omitted — breaks the tap. It’s the same family of “the program assumed a prior state that isn’t there” error.
Why a toolpath sim doesn't reach it
A toolpath render is about cutting edges. Probing is measurement, not material removal, so a simulation focused on the machined shape has no reason to execute the probe moves — and often doesn’t. The probe cycle, the runtime offset it sets, and the effect of that offset on later moves are all outside what a toolpath check models.
The runtime offset is the whole point, and it’s runtime. The reason probing matters — that it changes later positions based on a measured value — is exactly the reason a static toolpath can’t represent it. There’s no runtime to apply the offset, so the downstream shift never appears in the picture.
Checking probing reliably means executing the real program, probe cycles included, on a twin that runs those cycles the way the control does and carries their effect through the rest of the program.
Where Eureka G-Code fits
Eureka G-Code reads and executes the true ISO — probing and in-process measurement cycles included — on a digital twin of your machine, running the constructor cycles the way the control does (across Siemens, Fanuc, Heidenhain families and others, probing cycles among them). So the probe move runs on the twin, over your real fixtures and part, where a stylus heading into a clamp shows up as a collision or a near-miss before it breaks on the machine. And because Eureka G-Code specifically checks for the presence of pre-holes for tapping, the tap-without-a-drill error is caught in the same verification — a check aimed squarely at the “the program assumed a state that isn’t there” failure that probing and tapping both share.
Running the real program with the real fixtures in place is what turns probing from the least-verified part of the program into one you’ve actually seen execute — before it sets an offset that governs everything after it.
> Take a program with probing or in-process measurement — a datum-setting cycle, a bore check, a part that re-references mid-program — and run the real ISO on a twin of your machine in Eureka G-Code with your fixtures in place. Watching the probe move execute, before the stylus does it for real, is how the probe crash gets caught at a desk.
.
FAQ
Can you simulate a probing cycle before running it on the machine?
Yes. Eureka G-Code executes probing and in-process measurement cycles on a digital twin of your machine, with your real fixtures in place, so a probe move heading into a clamp or the part shows up as a collision or near-miss before the stylus breaks.
Why doesn't my CAM simulation run the probe cycles?
A CAM toolpath simulation focuses on cutting-edge motion and material removal. Probing is measurement, not cutting, and it sets an offset at runtime — neither of which a static toolpath render executes, so the probe moves and their downstream effect aren’t checked.
What happens if a probe measurement feeds a bad offset?
Nothing crashes at the probe, but the runtime offset it set shifts every operation after it — so the scrap appears later, across the whole rest of the part. That’s why verifying the probing before it runs matters as much as checking for collisions.
Does Eureka G-Code check for missing pre-holes before tapping?
Yes. It specifically checks for the presence of pre-holes for tapping, so a tap commanded where no drill preceded it — from a reordered operation or a skipped subprogram — is caught before the tap breaks.
Which controllers' probing cycles does it handle?
It executes control-specific constructor cycles, including probing cycles, across major families (Siemens, Fanuc, Heidenhain and others), reproducing your machine’s real controller behavior on the twin.
Next step
Request a demonstration on a digital twin of your own machine
Verify the real ISO — probing included, over your real fixtures — on a digital twin of your machine, before the first touch.