Dry Run vs CNC Simulation: Why Dry Run Is Not Enough
Every experienced machinist has run a dry run before cutting metal. It feels like the safe thing to do. But dry runs still cause machine crashes � because they miss exactly the errors that matter most. This article explains why, and what to do instead.
What Is a Dry Run?
A dry run is a method of testing a CNC program on the actual machine before engaging the spindle or cutting material. In a standard dry run, the operator loads the G-code program, activates the machine's dry run mode (typically via a dedicated switch on the control panel), and presses cycle start. The machine executes all axis movements at a reduced or overridden feed rate, with the spindle either off or running without contact with the workpiece.
The goal is to visually confirm that the machine moves as expected � that the tool doesn't collide with the fixture, that the program follows the intended path, and that the tool changes complete correctly. If something looks wrong, the operator stops the machine and investigates.
Dry runs have been standard practice in CNC machining for decades. They are better than nothing. But they have fundamental limitations that become more dangerous as part complexity, cycle time, and machine investment increase.
Why Dry Run Is Not Enough
The dry run has four structural weaknesses that no amount of operator skill or attention can compensate for.
1. The Spindle Is Off � But Crashes Happen at Rapid Speed
Most CNC machine crashes do not happen during cutting moves. They happen during rapid positioning moves � when the machine moves at full speed between operations, during tool changes, on the approach to the first cut, or on the final retract. These moves happen at G00 speed, not at the programmed feed rate.
In dry run mode with feed rate override active, the operator slows down all moves. The machine appears to move safely. But a collision that would happen at G00 rapid speed (typically 15�30 m/min on a machining center) does not always reveal itself at the reduced dry run speed � because the operator is watching the overall path, not computing clearances in real time against every fixture component and clamp.
THE CRITICAL GAP
A rapid move that clears a fixture by 2mm at 5% feed rate override still collides at 100% G00. Dry run does not show you whether your clearances are safe � it only shows you the path.
2. There Is No Workpiece
Standard dry run is performed without the actual workpiece, or with the workpiece positioned but with the tool elevated well above it. This means the operator cannot verify whether the programmed toolpaths actually cut the correct geometry, whether the stock is being removed as intended, or whether the tool is gouging into the part at any point in the program.
The operator is validating axis movement � not machining result. These are different things. A program can pass a dry run perfectly and still produce a scrapped part because the depth of cut, the work offset, or the tool length compensation was set incorrectly.
3. It Ties Up the Machine
A dry run requires the machine to be available, set up, and occupied for the entire duration of the test. For a program with a 90-minute cycle time, that means 90 minutes of machine time consumed before the first chip is cut � time during which the machine could be running production. In a shop running multiple shifts on a single Robodrill or machining center, dry run time is a direct capacity cost.
| Scenario | Dry Run | G-Code Simulation |
|---|---|---|
| 60-min cycle time program | 60 min machine downtime | ~3 min on workstation |
| Program modified and re-tested | Another 60 min downtime | Another ~3 min |
| Test after post processor change | Full cycle on machine | Immediate, off-machine |
| Machine availability required | Yes � machine must be set up | No � runs on any PC |
| Crash risk during test | Real � machine, tool, fixture at risk | Zero � virtual only |
4. It Requires Operator Attention for the Entire Duration
A dry run is only as good as the operator watching it. Attention degrades over time � a 90-minute dry run at the end of a shift is not the same as a 90-minute dry run at the start of the day. Rapid moves happen in fractions of a second. A collision that lasts 200 milliseconds can be missed entirely if the operator is looking at a different part of the machine at that moment.
Simulation does not get tired. It checks every single move, every clearance, every tool change, at every point in the program � and it flags exactly where the problem is, with a visual indicator and a line number in the G-code.
The Scenarios Where Dry Run Fails
Tool Change Position Error
The post processor outputs a tool change without retracting to Z home first. At reduced dry run speed, the operator sees the tool move toward the part and stops the machine. At full production speed on the next setup, the rapid move happens too fast to react � spindle into fixture.
Wrong Work Offset
The program references G54 but the operator set up the part under G55. Dry run shows correct-looking tool movement � because the operator is watching relative motion, not absolute coordinates. The first cut on a live workpiece runs at the wrong origin and into the vise jaw.
Holder Clearance at Depth
A deep pocket operation requires a long tool assembly. The tool itself clears the walls, but the holder body contacts the part at full depth. This is invisible in dry run without a workpiece. Simulation with the actual holder geometry catches it immediately.
Clamp in the Toolpath
A fixture clamp sits at the edge of the travel envelope. The programmer did not model it in CAM. Dry run at slow speed appears clear because the operator's eye tracks the tool, not the clamp. At production speed, the tool hits the clamp on a G00 move.
How to Avoid Crashing a Robodrill
The FANUC Robodrill is a compact, high-speed machining center. Its compact working envelope � typically 300�400mm in X, 300mm in Y, 280mm in Z � means fixtures, clamps, and tooling are physically close together. The clearances between machine components are small. The spindle speed is high. The cost of a crash is significant.
Dry run on a Robodrill is particularly risky for these reasons:
- The compact envelope means fixture and clamp collisions are more likely on rapid moves
- High spindle acceleration means a collision at full speed causes more damage than on a slower machine
- The tool changer geometry requires specific retract sequences � a post processor error in this sequence is not reliably caught by visual dry run
- Robodrill setups often use complex, multi-operation fixtures where the operator cannot visually track every potential interference point simultaneously
The operators who never crash a Robodrill are not the ones who do the most careful dry runs. They are the ones who simulate the G-code before the program ever reaches the machine.
THE CORRECT APPROACH
Simulate the complete G-code program in a virtual Robodrill � with the actual machine geometry, the actual tool assembly, the actual fixture model, and collision detection active � before the first dry run. If a crash is going to happen, let it happen in software. Simulation finds the problem in minutes. A crash on the actual machine costs hours of downtime and potentially thousands in repairs.
Dry Run vs Digital Twin
The term "digital twin" refers to a virtual model that accurately replicates the physical machine � its geometry, kinematics, axis travel limits, controller behavior, and component relationships. When you simulate G-code in a digital twin of your Robodrill, you are not approximating machine behavior � you are replicating it.
What a Digital Twin Catches That Dry Run Cannot
- Collisions between the tool holder body and the workpiece at full depth
- Axis over-travel before the machine's hardware limit switch triggers
- Tool change sequence errors before they reach the machine
- Gouge detection � tool cutting into finished surfaces
- Residual material after the last operation � parts that will fail inspection
- Rapid move collisions that happen too fast for an operator to catch
| Dry Run | G-Code Simulation / Digital Twin | |
|---|---|---|
| Detects rapid move collisions | Partial � operator dependent | Yes � automatic, every move |
| Detects holder body collisions | No � no workpiece present | Yes � full geometry check |
| Detects wrong work offset | No � visual only | Yes � absolute coordinate check |
| Detects post processor errors | Partial � obvious ones only | Yes � G-code interpreted exactly |
| Validates part geometry / no gouge | No | Yes � material removal engine |
| Detects axis over-travel | Partial � machine alarm after the fact | Yes � before the program runs |
| Machine time required | Yes � full cycle time | No � runs on any PC |
| Risk of damaging machine/tooling | Yes � real machine at risk | Zero � fully virtual |
| Available before machine setup | No | Yes � at the programmer's desk |
| Repeatable after any change | Only if machine is available | Yes � immediate re-run |
Should You Still Do Dry Runs?
Yes � but in the right order, and with realistic expectations about what they verify.
The correct workflow is simulation first, dry run second � not as a replacement for each other, but as two layers of verification with different purposes:
- G-code simulation (before the machine): catches post processor errors, collision risks, over-travel, holder clearance issues, and gouge detection. This is where you find the dangerous problems � before they can damage anything.
- Dry run (on the machine, after simulation): confirms the physical setup � that the workpiece is correctly fixtured, that the tool length offsets are correct, that the work coordinate system matches the actual part position. This is what only the real machine can verify.
A dry run after a clean simulation is a short, low-risk confirmation step. A dry run without prior simulation is the primary safety net � and as the examples above show, it has significant gaps.
THE WORKFLOW THAT PREVENTS CRASHES
Simulate in Eureka3X → confirm clean → set up machine → dry run at reduced feed (short, focused on setup verification) → cut with confidence. Simulation is not a replacement for the operator � it is what makes the operator's job safer and faster.
Simulate Your G-Code with Eureka3X
Eureka3X includes a production-ready FANUC Robodrill digital twin � with machine geometry, axis travel limits, and FANUC controller dialect built in. Load your G-code from any CAM system and run a complete simulation: collision detection, material removal, gouge check, axis over-travel, and tool change verification. Everything a dry run cannot catch, before the program reaches the machine.
The Robodrill machine is included in both Eureka3X Basic and Pro plans, ready to use immediately after installation � no additional configuration required.
Stop Finding Crashes on the Machine
Simulate your G-code in a virtual Robodrill before the first dry run. Catch every collision, gouge, and post processor error � at your desk, in minutes, at zero risk.
Start Your Free 30-Day TrialNo credit card required · Windows 10/11 · Dedicated GPU required
Frequently Asked Questions
Is dry run mode the same on all CNC machines?
No. Dry run behavior varies by controller and machine model. On FANUC controllers, dry run mode overrides all feed rates with a single rate set by the operator. On some machines, rapid moves are also overridden; on others, they run at full G00 speed. Always check your specific machine's documentation to understand exactly what dry run does and does not affect.
Does Eureka3X simulate the FANUC Robodrill specifically?
Yes. Eureka3X includes a production-ready FANUC Robodrill machine configuration with accurate machine geometry and FANUC controller dialect. It is available in both Basic and Pro plans with no additional setup required.
Can simulation replace a dry run entirely?
Simulation replaces dry run as the primary safety verification step � because it catches more problems, faster, with zero risk to the machine. A brief dry run after simulation is still valuable for confirming the physical setup: correct work offset entry, correct tool length offsets, correct part positioning. Simulation handles everything it can verify from the G-code itself; dry run handles what only the physical machine can confirm.
What G-code errors does Eureka3X detect that dry run misses?
Tool change position errors, holder body collisions at depth, rapid move collisions with fixtures and clamps, incorrect work offsets, canned cycle errors, axis over-travel, gouge into finished surfaces, and residual material after machining. All of these are detected automatically, with the exact location flagged in the G-code.