Simulation & Program Verification Before the Cut
Between the finished program and the finished part sits one of the most expensive moments in machining: the first time the program runs. Every machinist knows the tension of that moment, because the first run is where the errors that no one caught announce themselves — and they announce themselves not as text on a screen but as a sound no shop wants to hear. The discipline that exists to prevent that moment is program verification: rehearsing the job in a world where mistakes cost nothing, before running it in a world where they cost spindles, tools, fixtures and parts. Done well, verification turns the first run from a gamble into a formality. Done badly, or skipped, it makes the machine the test environment — and the machine is the most expensive test environment a shop owns.
This guide is the reference for that discipline. It explains why verification before the cut matters, the three levels of simulation and what each can and cannot catch, the single most important rule — that you must verify the posted G-code, not just the CAM toolpath — and the on-machine prove-out that even perfect simulation cannot replace. It is the capstone of this library’s programming topic, and it builds directly on the three guides that came before it: the G-code guide taught you to read the program being verified, the CAM workflow guide placed simulation in the workflow, and the postprocessor guide explained why the code the machine runs is not the code CAM imagined — which is exactly why the posted output is what verification must test. Terms like axis, spindle and tool magazine are in the glossary.
Why verify before the cut
The case for verification rests on one asymmetry. A programming error discovered in simulation costs a few minutes of fixing. The same error discovered on the machine costs whatever it touches: a broken tool, a damaged fixture, a gouged part, a crashed spindle — and the hours of downtime while the damage is assessed and repaired. Errors in a CNC program are also famously silent until the wrong moment. They do not announce themselves as errors; they appear as a rapid move through the workpiece, a tool that cuts where it should not, an axis driven past its travel — each one perfectly normal in the code until the instant it is not. Verification exists because the cost of finding these errors is orders of magnitude lower in software than on the floor, and because the errors themselves are common enough that trusting a program because it looked right is not a strategy.
It helps to name the two families of failure that verification addresses, because the division decides what simulation can and cannot do for you. The first family is what the code does wrong: a bad toolpath, a wrong move, a postprocessor error, a collision the programming never considered. This family lives entirely in the program, and it is exactly what simulation exists to catch. The second family is what the setup does wrong: a tool whose length was never measured, a work offset that does not match the CAM origin, a clamp sitting where the toolpath goes. This family lives in the physical job, not the program, and simulation — which models the job as it was told it is — cannot see it. The discipline of this guide covers the first family thoroughly and points to the tools that handle the second: the simulation catches what the code got wrong, and probing, tool setting and offset verification catch what the setup got wrong.
The three levels of verification
Simulation is not one thing. It is a ladder of three increasingly faithful representations of the job, and each rung catches a different class of error. Shops that treat “simulation” as a single checkbox are using the weakest rung and calling it the strongest:
Backplot. The most basic level shows the toolpath as a moving line relative to the part — a quick animated view of where the tool tip goes. It shows nothing of material removal, nothing of the machine, nothing of collisions: it is, in the phrase of one CAM documentation, a geometric vacuum, the tooltip moving through empty space. Backplot is fast and useful for what it is — checking approach and retract moves, entry points, depths and clearances at a glance, catching a visibly wrong move before anything more elaborate runs. Its danger is being mistaken for verification. A backplot that looks clean proves only that the toolpath is drawn as intended; it says nothing about whether the machine can run it safely. Backplot is a sanity check, not a simulation.
Solid simulation (material removal). The second level adds the stock: the tool is animated cutting into a model of the raw material, so the program’s effect on the part becomes visible. Solid simulation detects what backplot cannot — gouges and overcuts, where the tool removes material beyond the intended surface; tool and holder interference with the part and fixtures; and whether the toolpaths actually remove the material they should. Because it works against the stock model, its accuracy depends on how faithfully that model and the tooling were defined: a solid simulation is only as truthful as the CAM setup it runs against. Most CAM packages build this level in, and it is the natural place for early, everyday validation.
Machine simulation. The top level adds the machine itself — a complete model of the real machine’s structure and motion: the head, the spindle, the table, the axis travels and kinematics, the enclosures. The program is run inside this virtual machine, and now the checks that matter most become possible: collisions between any combination of tool, holder, spindle, part, stock, fixture and machine components; over-travel, where an axis would be driven past its limit; the behaviour of rapids, tool changes and multi-axis transitions; and with a faithful model, accurate cycle-time estimates. Machine simulation is the level that catches the crash that the toolpath simulation cannot: the tool holder clipping a vise jaw, the spindle housing meeting the part in a deep cut, the rotary table sweeping into a fixture — failures that involve the machine and tooling, not just the tool tip and the stock.
| Backplot | Solid simulation | Machine simulation | |
|---|---|---|---|
| Shows the toolpath | Yes | Yes | Yes |
| Removes virtual material | No | Yes | Yes |
| Catches gouges and overcuts | No | Yes | Yes |
| Models the machine’s axes and structure | No | No | Yes |
| Catches collisions between machine, holder and fixtures | No | No | Yes |
The ladder is progressive by design: backplot for a fast visual check, solid simulation for stock interaction and gouging, machine simulation for the real-world collisions and travel problems that only a full model can reveal. The sophistication a shop needs tracks the risk of its work — a simple three-axis job in soft material may be well served by solid simulation, while complex multi-axis work on expensive material and valuable machines is exactly where the top rung earns its cost. The principle underneath is the one this guide repeats: verify to the depth that the risk demands, and know which rung you are standing on.
The critical rule: verify the posted code, not the CAM toolpath
The most important discipline in verification is also the most commonly violated, and it follows directly from the postprocessor guide: the program the machine runs is not the toolpath CAM imagined. What CAM simulates — in its integrated, toolpath-level simulation — is the idealised motion of the tool, often before postprocessing and always without the machine. But the machine executes the posted G-code: the output of the postprocessor, complete with the startup blocks, modal states, reference returns, tool-change logic and machine-specific behaviour the post added. And as the postprocessor guide showed, that added behaviour is precisely where the surprises live — the phantom move the CAM simulation never displayed, the modal state left behind that misreads the next program, the retract that the toolpath view had no way to show.
The practical consequence is blunt: simulating the CAM toolpath is not verifying the program. A toolpath simulation that looks perfect tells you nothing about whether the posted code — the file actually loaded into the machine — contains a postprocessor error, a wrong home return, a rotary move the machine interprets differently, or a tool-change position that collides. This is why the highest-trust verification is done after postprocessing, on the actual G-code that will run, and why the most capable verification systems model the posted code against the machine rather than modelling the toolpath against the stock. The distinction is the difference between confirming that the toolpath is clean and confirming that the machine will not crash running it — and the second is the one that protects the spindle.
What simulation catches — and what it cannot
When simulation is done on the posted code against a faithful model, the list of what it catches is genuinely impressive. Collisions, between the tool, its holder, the spindle and everything else in the work zone — and when one is found, the simulation stops and shows where, usually colouring the offending surfaces so the programmer can see the mistake rather than hunt for it. Gouging and overcuts, including the rear-gouging that bedevils complex five-axis finishing, where the back of the tool cuts a surface the front is supposed to be finishing. Over-travel, the axis driven past its limits, flagged before it alarms on the machine. Clearance and fixture problems, the toolpath that runs through the workholding, the tool-and-holder combination that cannot reach the feature without striking the part. Each is an error that, on the machine, would be expensive; in simulation, each is a fix.
The honesty that makes this guide useful is naming what simulation cannot do. Simulation is only as truthful as its models: if the stock in the simulation does not match the material on the machine, if the tool model does not match the tool in the magazine, if the fixture is not represented, then the simulation verifies a job that does not exist. This is the virtual-twin contract again, applied to verification: garbage in the models means false confidence in the output. And beyond fidelity there is the deeper limit already named — simulation cannot see the setup errors that live in the physical job rather than the program. A perfect simulation of a program whose work offset is wrong, or whose tool lengths were never measured, verifies a program that will still crash, because the crash will come from the setup, not the code. Simulation moves the code’s risk offline; the setup’s risk still lives on the machine, and it has its own tools.
The on-machine prove-out: what even perfect simulation cannot replace
The verification story does not end in software, and the shops that understand this are the ones that never treat a simulated program as a licence to press Cycle Start at full speed on expensive material. Even a perfect simulation of a perfect program meets a real machine that is not the model: the machine that grows as it warms, the thermal drift that a long run introduces, the fixture that relaxes under load, the coolant that changes the cut — realities no offline model fully captures, and realities the programme cannot anticipate because they are not in the programme. The on-machine prove-out exists to bridge the gap between “the program runs” and “the program runs right,” and it is a ladder of its own:
Dry-run above the part. With the job set up exactly as it will cut — tools touched off, offsets entered — run the program above the workpiece with the Z zero shifted safely up, at a reduced rapid override, in single block if the control needs watching. This confirms on the real machine what simulation confirmed in software: the approach directions are right, the retracts clear, the tool changes behave, the axes move as the code intends — before any tool touches any material. Dropping Z down for a final air cut just above the stock catches the last surprises with nothing at risk.
Verify the setup, not just the code. Before the first chip, confirm what the simulation had to take on faith: the tools are the tools the program expects, with lengths and offsets measured — the work of the tool setter and the probe — and the work offset matches the CAM origin. The crashes that still happen after perfect simulation are overwhelmingly here: a tool length never measured, a coordinate system entered wrong, a clamp where the toolpath goes. These are setup errors, and they are caught by verification of the setup, not of the code.
Prove the first article at reduced parameters. The first real part is cut at a fraction of the programmed feeds and speeds, measured hot off the machine, and judged against the drawing before anything else runs. If it passes, the parameters are raised toward the programmed values, and the job is released only after good parts confirm the process — the common discipline being a run of consecutive good pieces before the job is trusted to run unattended. This final rung is where verification meets inspection and quality: simulation proved the code, the dry run proved the machine, the first article proves the process.
The comparison that frames the whole ladder is worth stating plainly. The traditional prove-out — standing at the machine, single-blocking new code with a hand on the override, cutting air or scrap while watching every move — turns the machine into the test environment and spends productive spindle time on risk. Simulation exists to move that risk off the machine and into software, where it is free. The shop that simulates the posted code to the depth its risk demands, then uses the machine only to confirm what software cannot — the reality of the setup and the behaviour of the real machine — gets the fastest, safest path from new program to released job.
Frequently asked questions
What is the difference between backplot, simulation and machine simulation? They are three levels of the same ladder. Backplot shows the toolpath as a moving line with no material removal — a fast visual sanity check. Solid simulation adds the stock and shows material being removed, catching gouges and tool interference with the part and fixtures. Machine simulation adds a full model of the real machine — its axes, spindle, table and kinematics — and runs the program inside it, catching collisions between machine, holder and fixture, over-travel and the other real-world failures the lower levels cannot see. Backplot is not simulation, and toolpath simulation is not machine simulation.
Why must I simulate the posted G-code rather than the CAM toolpath? Because the machine runs the posted code, not the CAM toolpath. CAM’s integrated simulation models the idealised tool motion, usually before postprocessing; the postprocessor then adds startup blocks, modal states, reference returns and tool-change logic — exactly the behaviour where surprises live. A phantom move, a wrong home return or a rotary behaviour the machine interprets differently appears only in the posted output. Simulating the toolpath confirms it is clean; simulating the posted code confirms the machine will not crash running it.
Does simulation replace the need for careful prove-out on the machine? No — it changes what the prove-out is for. Simulation catches what the code got wrong: collisions, gouges, over-travel, postprocessor errors. It cannot see what the setup got wrong — a tool length never measured, a wrong work offset, a clamp in the toolpath — because those live in the physical job, not the program. The on-machine steps remain essential: dry-run above the part at reduced override, verify the offsets and tooling (often by probing), and prove the first article at reduced parameters. Simulation moves the code’s risk offline; the setup’s risk is still confirmed on the machine.
When is full machine simulation worth it? When the risk justifies it. Machine simulation’s value tracks the cost of a crash — the value of the part, the machine, the tooling and the downtime. Complex multi-axis work on expensive material and valuable machines, long-cycle jobs where a late failure wastes hours, and unattended running where no one is watching are exactly where the top rung earns its keep. For simple three-axis work in forgiving material, solid simulation against a faithful setup may be all the risk demands. Verify to the depth the risk requires, and know which rung you are on.
My program simulated clean but still crashed on the machine. What went wrong? Almost always one of two things. Either the simulation was not of the posted code — the CAM toolpath view looked clean but the postprocessor added behaviour the toolpath simulation never showed — or the simulation’s models did not match the physical job: stock, tool or fixture defined differently from reality, the virtual-twin contract broken. And if the crash came from the setup rather than the program — an unmeasured tool, a wrong offset, a clamp in the way — no simulation could have seen it. Simulate the actual G-code against faithful models, then confirm the setup on the machine before trusting the code.
Bottom line
Program verification is the discipline of rehearsing a job where mistakes are free, before running it where they are not — and it is the difference between a first run that is a formality and a first run that is a gamble. It works on a ladder of three levels, each catching more than the last: backplot shows the toolpath, solid simulation shows the material removal and catches gouges, and machine simulation models the real machine and catches the collisions, over-travel and kinematic failures that the lower levels cannot see. Its central rule is to verify the posted G-code, not the CAM toolpath, because the machine runs what the postprocessor produced — and the postprocessor is where the surprises live. And its honest limit is that simulation sees the code, not the setup: the crashes that still happen after perfect simulation are the ones that live in unmeasured tools, wrong offsets and clamps in the way, which simulation can only take on faith and the probe and tool setter must confirm. Verify the posted code to the depth the risk demands, dry-run above the part, confirm the setup, and prove the first article at reduced parameters — and the first run stops being the most expensive moment in machining and becomes the confirmation that the work was already done right.
This guide is part of the CNC Media guides library — the program-verification reference of the programming topic, deliberately free of prices and of any single simulation vendor’s catalogue to promote.