It’s almost always optimistic
Notice the error only goes one way. CAM estimates don’t miss high and low at random, they come in short. The machine takes longer than the software said. That’s not bad luck. Everything CAM skips adds time, nothing it skips saves any.
What CAM leaves out
Acceleration and deceleration. Most CAM figures are basically path length ÷ feed rate. That assumes the tool is at programmed feed for the whole move, but it isn’t. It ramps up from a stop and back down again, and short moves never reach the feed at all. So the real number is always slower, never faster. (The physics is in feed rate vs. cycle time.)
Cornering. A real machine has to slow down to change direction and speed back up on the way out. CAM doesn’t model that. A part with a lot of direction changes, like a detailed 2D profile or a 3D finishing pass, pays that tax at every corner, and none of it is in the estimate.
Your specific machine. A CAM number is essentially machine agnostic, or uses generic defaults. It doesn’t know your rapid rates and, crucially, it doesn’t know your acceleration. Two machines running the identical program post very different cycle times. CAM can’t tell which one is sitting on your shop floor.
Controller reality. Lookahead depth, feed limiting, dwell handling, tool change time, spindle spin-up. All controller-specific, and CAM doesn’t model your controller. These mostly add time too.
Why the error grows with detail
The estimate is least reliable exactly where you most need it. On a part that’s mostly long, straight cuts, CAM is close, because there are few corners and the moves are long enough to reach feed. But on a part packed with short segments and fine detail, the acceleration and cornering overhead dominates, and CAM can be off by a wide margin. The intricate jobs you most want to quote accurately are the ones CAM estimates worst.
The size of the gap tracks two things: how much detail the part has, and how much acceleration your machine has. A rigid machine with high acceleration closes the gap. A hobby-class machine with gentle acceleration blows it wide open on the same file.
A quick sanity check
Before you trust a CAM cycle time, check two things: whether the part is full of corners and fine detail, and whether the machine is modest on acceleration. If both are yes, expect the real run to be meaningfully longer than the number on screen, and don’t quote tight against it. If the part is mostly long straight moves on a snappy machine, CAM will be close.
How to get the real number
Run the actual G-code (the post-processed output, not CAM’s internal estimate) through a simulator that models real motion, one that uses your machine’s rapid and acceleration limits. That models the acceleration, deceleration and cornering CAM skips, so the figure reflects your machine instead of a generic best case. Working from the posted file has a bonus: it catches anything the post-processor changed, which the CAM estimate never sees.
UltraNC does exactly this. Drop the file in, set your rapid and acceleration limits, and read the estimated run time with accel, decel and true radius cornering included. Nothing is uploaded, and there’s no sign up.
When CAM reads high instead
It’s not always low. CAM occasionally overstates, if it assumes a slower rapid rate than your machine has or pads in conservative overhead. But the common, money losing case is the optimistic one, and either way the remedy is the same: simulate the real toolpath with your machine’s actual dynamics rather than trusting a geometry-and-feed estimate.
Common questions
Why is my CAM cycle time estimate always too low?
Because most CAM estimates come from path length and feed rate, assuming the tool reaches the programmed feed instantly and rounds corners without slowing. Real machines accelerate, decelerate and slow into every corner, and all of that adds time the estimate never counted, so the actual run is longer.
Why is Fusion 360's machining time different from the real run?
Fusion's estimate is computed from the toolpath and the programmed feeds. It doesn't fully model your specific machine's acceleration or your controller's real-world behaviour, so it commonly reads optimistic, especially on detailed parts with lots of corners, where the acceleration and cornering it skips add up.
How do I get an accurate cycle time estimate?
Run the post-processed G-code through a simulator that models real motion, set to your machine's rapid and acceleration limits. That accounts for the acceleration, deceleration and cornering CAM leaves out, so the number reflects your machine rather than a generic best case.
Part of the guide: How to estimate CNC machining time from G-code
The physics: Feed rate vs. cycle time: why the tool rarely runs at the programmed feed.