CNC Simulation & Program Verification

CNC simulation and program verification are the ways a program is tested before it is trusted to cut metal, and they answer a question every new program raises: is this program right? The machine will obey whatever it is given, and a program’s errors — a mode left wrong, a depth that cuts through the part, a rapid that passes through the clamp, a toolpath that gouges a wall — become crashes and scrap the moment metal is cut, unless they are found first. Finding them is the work of verification, and it happens in stages: the program is read by eye, checked by software against the part and the machine, and finally proved on the machine itself, as this wiki’s entry on the dry run and prove-out describes. This entry sets out the software half of that work — the simulation and program verification that happen off the machine, before the first cut.

Verification: finding errors before the machine does

The errors that verification hunts are the whole range of ways a program can be wrong, and they fall into classes. There are the code errors — an unrecognised word, a missing value, a syntax the control will reject; these are usually caught the moment the program is loaded. There are the state errors — a mode left in the wrong state, a tool length or cutter compensation not as the program assumes — which the reading skill of this group catches in the blocks themselves. And there are the geometric errors, the deepest class: the toolpath that cuts where no metal should be cut, the move that collides with the workholding, the surface that is left rough or cut away. The eye and the mind catch the first classes; the geometric errors are the ones that software sees best, by drawing the toolpath and watching the tool against the model. Verification is the discipline of using every tool, from reading to simulation, to find the errors while they are still only in the program.

Backplotting the toolpath

The first and simplest software check is backplotting: the program’s moves are drawn as lines on the screen, and the programmer watches the path the code actually describes. The backplot shows what the G-code means in space — the rapid moves and the cutting moves, drawn in different colours — and it exposes at a glance the gross errors of geometry: a move that runs across the part where no cut is wanted, a feature that is cut in the wrong place, a path that does not match the shape on the drawing. Backplotting is quick, and it verifies the code rather than the CAM programmer’s intention, because it draws from the program itself; a postprocessor that wrote a move wrong, or a hand edit that changed the path, shows up in the backplot as the line that does not belong. It cannot show material being removed or collisions with solid things — for that the check must move from lines to solids — but it is the fast first look that catches the obvious before anything else begins.

Solid simulation of the cut

The fuller check is solid simulation, which models the cut itself. The software is given the stock — the size and shape of the block, bar or casting — and usually the workholding too, and it runs the program against that solid model, removing material where the tool passes and leaving it where it does not. The programmer watches the part take shape on the screen and checks it against the model: the material that should be removed is gone, the features are where they should be, and — the heart of the check — no tool cuts through the part into the fixture, no surface is gouged, no island of stock is left where a finish pass should have run. Because the simulation runs the actual program, not the ideal toolpath inside CAM, it also catches the errors of the postprocessor: the move written wrongly, the compensation applied wrongly, the depth the code really gives. Solid simulation is the verification that sees the part before the machine makes it, and it finds the errors that would otherwise be the first chip.

Simulating the machine

Where the work is complex enough, verification extends to the machine itself, and machine simulation models the whole moving system. The software holds a model of the machining centre — its table, its axes, its spindle and tool changer, sometimes its guards — and runs the program with the tool assembly modelled, so that it can see not only whether the tool cuts the part correctly but whether anything collides: the tool holder striking the fixture, the spindle head reaching its limit, the tool changing into a clamp, an axis running out of travel. Machine simulation matters most where the axes move together in ways the eye cannot follow — the simultaneous motion of a five-axis program, the rotation of a fourth axis — where a collision could happen deep in a move that looks fine on paper. Like solid simulation, it runs the real program against the real geometry, and it finds the crash before the machine does, which is the whole purpose of the exercise.

From simulation to the machine

Simulation and program verification reduce the risk of a program to a fraction, but they do not end the work of proving it, and the program’s final test is still on the machine. The software’s model is never quite the real part: the real stock differs from the model, the real tool runs out, the real fixture flexes, and the ways of the machine — the feed hold, the single block, the dry run without the part in the cut — are the final verification that the program does what the drawing asks, on the machine that will make it. The two halves of proving belong together: the software finds the errors of code, geometry and collision before the machine is risked, and the machine proves the program’s last uncertainties in a controlled run. Between the reading that checks the program’s sense, the simulation that watches it cut and the dry run that runs it safely, a program is verified as thoroughly as it can be — and the part that follows is made by a program that has already been proved, in simulation and on the machine, before a single chip was cut.