Most scrap isn't a crash — it's a program that ran perfectly and made the wrong part
When people think about verification, they think about crashes: the tool into the fixture, the turret into the turret. Those are expensive and dramatic. But the steady, quieter cost in most shops is scrap — parts that come off a machine that never crashed, running a program that never faulted, and gauge out of tolerance anyway. A wrong offset that shifted a diameter. A depth that didn’t break through. A canned cycle copied with the wrong parameter. The program was valid, the machine was fine, the part is in the bin.
Crash detection never sees these, because nothing collided. The operator doesn’t catch them until first-article inspection — or worse, until a batch is already cut. And the fix is almost always cheap if you catch it before the chip: it’s a number in the program. The whole game is moving that catch from after the machine ran to before — which is what offline verification does.
Where the scrap actually comes from
The scrap-producing errors share a signature: valid code, no collision, wrong result.
- Offset errors that shift a feature. A wrong tool-length or work offset, or a multi-operation tool correction that moved one feature while fixing another — the part is machined precisely to the wrong place.
- Wrong depth or a hole that didn’t break through. A Z that’s too shallow leaves a part that looks finished and isn’t.
- Copied cycles with the wrong parameter. A canned cycle brought from another job carries its depth, peck, or R plane into a part where they don’t fit.
- A wrong-form operation. A threading pass at the wrong pitch, a synchronized operation with the wrong ratio, a profile that’s subtly off — geometry that’s wrong but not colliding.
- Units or format slips. A coordinate off by a factor, or an inch/metric mismatch, that scales a feature.
None of these announce themselves. They pass every check that looks for collisions, because the failure is in the result, not the motion.
Why offline — and why against the model
Offline means before the chip. Catching a scrap error on the machine costs a part (or a batch), machine time, and a re-run. Catching it offline costs a program edit. The earlier the catch, the cheaper — and the only catch earlier than the first part is a check that runs before the program does.
Against the model is what finds the safe-but-wrong. Collision detection compares the tool to the fixture. To catch the scrap, you have to compare the machined result to what the part was supposed to be — the CAD model. That comparison is what surfaces the shifted diameter, the shallow hole, the wrong depth: the errors that don’t collide with anything but don’t match the design either.
Together, that’s the point of offline verification: run the real program the way the control will, and check the part it produces against the part it was meant to produce — before any of it happens on the machine.
Where Eureka G-Code fits
Eureka G-Code runs the true ISO on a digital twin of your machine and controller, and compares the finished part against the CAD model — so the safe-but-wrong errors that produce scrap are visible before you cut. The offset that shifted a diameter, the hole that didn’t break through, the copied cycle with the wrong depth, the threading pass at the wrong pitch: each shows up as a part that doesn’t match the model, even though nothing collided. In the same run it catches the crashes — collision, near-miss, holder-vs-blank, overtravel — and confirms the pre-holes for tapping are there.
Because it reads the real ISO regardless of origin, it catches the scrap error wherever it entered: the posted program, the hand edit at the control, the copied block. And an accurate cycle time from the same run means the fix doesn’t cost you a quoting mistake either. On volume work especially, where one bad program can scrap a whole run before anyone inspects a part, moving the catch offline is money kept rather than money lost.
> Take a job you recently scrapped a part on — the one that ran fine and gauged wrong — and run the real ISO on a twin of your machine in Eureka G-Code, compared to the model. Seeing the out-of-spec feature before the machine cuts it is the difference between a program edit and a bin full of parts.
FAQ
How does offline verification reduce scrap?
By catching the safe-but-wrong errors — a shifted offset, a shallow hole, a copied cycle with the wrong parameter — before the program runs, when the fix is a program edit rather than a scrapped part or batch. Offline means the catch happens before the first chip.
Why doesn't crash detection catch scrap?
Because most scrap doesn’t involve a collision. The program runs fine and the machine is unharmed; the part is simply out of spec. Crash detection compares the tool to the fixture, so it can’t see an error that’s in the result, not the motion.
How does comparing to the CAD model help?
It surfaces the errors that don’t collide but don’t match the design — the shifted diameter, the wrong depth, the wrong thread form. Eureka G-Code compares the machined result on the twin against the model, so those show up before you cut.
What kinds of errors produce scrap without crashing?
Wrong tool-length or work offsets, multi-operation offset corrections, wrong depths, copied canned cycles with wrong parameters, wrong-form operations (threading pitch, synchronized ratios), and units or decimal-format slips.
Does it work on hand-written and edited programs?
Yes. It reads the actual ISO the control receives, so a scrap error introduced by a hand edit is caught the same as one in a posted program.
Next step
Eureka G-Code — request a demonstration on a digital twin of your own machine and controller.
Catch the wrong part before you cut it — run the real ISO on a twin and compare to the model.