Cutting time isn’t the whole story
Machining time, or cycle time, is the stretch from cycle start to the end of the program. It splits into two parts: cutting time, while the tool is engaged and moving at feed, and non-cutting time, the rapids, dwells, retracts and tool changes. On a lot of jobs the non-cutting time is a real chunk of the total, sometimes most of it. Any estimate that only looks at cutting moves is already missing time.
Why “distance ÷ feed rate” is wrong
The quick estimate everyone reaches for is total path length divided by feed rate. It’s what most online viewers and back-of-the-envelope calculators do, and it’s almost always too low. Two reasons:
The tool never instantly hits the programmed feed. It accelerates from a stop, and it has to decelerate back to a stop at the end of a move or before a corner. On a short move it may never reach the commanded feed at all: it’s ramping up and back down the whole way. Distance ÷ feed assumes full speed for the entire move, which simply doesn’t happen.
Corners cost time. A real machine slows down to change direction. It can’t whip around a sharp corner at full feed without infinite acceleration. Every direction change sheds speed and then has to build it back up. The tighter the corner and the lower the machine’s acceleration, the bigger the hit. Path ÷ feed ignores cornering entirely.
Add rapids, dwells (G04), retracts and tool changes (M06) on top, and the naive number can be off by a wide margin. It nearly always understates the real run.
What actually governs cycle time
Acceleration and deceleration. Each move follows a trapezoidal velocity profile: ramp up, cruise at the programmed feed, ramp down. If a move is too short to reach the feed, the profile is triangular: pure accelerate then decelerate, peaking below the commanded speed.
Cornering. At each direction change the machine limits its speed to what it can physically round, given its acceleration and the sharpness of the corner. Gentle curves barely slow it. Tight corners drop it close to a stop.
Rapids. Positioning moves (G00) run at the machine’s rapid rate, not the program feed. That is a different speed entirely, and one the file never states.
Dead time. Dwells, tool changes and retract heights all add seconds that have nothing to do with feed rate.
How UltraNC estimates it
UltraNC runs a real trapezoidal motion planner over the toolpath, the same kind of planning a CNC controller does for every block:
It uses per-axis rapid rates and accelerations (XY and Z resolved separately), accelerates up to the programmed feed, cruises, and decelerates, computing the true time for every move. It slows for corners based on the actual path geometry (the local radius through each turn), so a tight corner costs more than a gentle one, and arcs are bounded by their true radius rather than by how finely the file happens to chop them into segments. A two-pass plan (sweeping backward through the program, then forward) guarantees the profile is physically feasible: it never accelerates or decelerates faster than your limits, and it starts and ends at rest.
The key part: you set your machine’s rapid and acceleration limits, so the estimate is computed for your machine. The minutes you’ll actually wait, not a best-case fantasy of instant speed.
Estimate accuracy
It models the physics that dominate cycle time (per-axis acceleration, deceleration and cornering), which is exactly what the distance ÷ feed estimate misses. It’s a kinematic model, so it doesn’t try to reproduce every controller’s lookahead depth or servo lag. If your controller is jerk-limited, set the Jerk value in Machine dynamics and the S-curve ramps and jerk bounded corners are modelled too. Treat it as a tight, realistic estimate: close to the real number, not a to-the-millisecond stopwatch. For planning, quoting, and comparing two versions of a program to see which runs faster, it’s the number you want.
Estimate your own file
Open the viewer, drop in your .nc / .gcode / .ngc / .tap file, set your machine’s rapid, acceleration and (if required) jerk limits, and read the estimated run time. Nothing is uploaded, the file stays on your device, and there’s no sign up. If you just want to see it work, the viewer loads with a built-in demo job you can run first.
Common questions
Is feed rate the same as cycle time?
No. Feed rate is the speed the tool is commanded to cut at. Cycle time is how long the whole program takes from cycle start to end. The tool spends time accelerating up to the feed and decelerating back down, slows for corners, and adds rapids, dwells and tool changes. None of that shows up in a feed rate figure.
Why is my CAM software's cycle time estimate off?
Many CAM estimates assume the tool reaches the programmed feed instantly and ignore the deceleration into corners. Real controllers ramp up and slow down, so the actual run is usually longer than the CAM number, sometimes considerably on programs with lots of short moves or tight detail.
Does the feed rate in my file guarantee the tool moves that fast?
Not necessarily. On a short move the tool may never reach the commanded feed. It accelerates partway, then has to decelerate to stop or to round the next corner. The shorter and busier the geometry, the further actual speed falls below the programmed feed.
Can the estimate match my specific machine?
Yes. Set your machine's rapid rates and acceleration limits (XY and Z) in the viewer and the estimate is computed for those limits, so the cycle time reflects your machine rather than a generic one.
Keep reading
Why your CAM software’s cycle time estimate is wrong: why CAM numbers read optimistic, and how to get one you can quote against.
Feed rate vs. cycle time: what acceleration and cornering really cost: the physics of why your machine rarely runs at the programmed feed, with the trapezoidal-motion and cornering math behind the estimate.
How to calculate G-code run time: the hand method worked through line by line, and the faster, accurate route.
Subprograms and cycle time: M98, M97 and o-words: where production programs hide their minutes.
G84 rigid tapping: feed locked to the pitch, the reversal at the bottom, and what each hole costs.
G94 vs G95: feed per minute vs feed per revolution, and the thousand-fold trap between them.
G04 dwell: P vs X: seconds on one control, milliseconds on another.
G61 vs G64: exact stop, corner blending, and the time between them.
Jerk and S-curve motion: the refinement for jerk-limited controllers.
How UltraNC compares to other G-code viewers: honest, sourced comparisons with NCViewer, CAMotics and CIMCO Edit.
Non-cutting time: rapids, dwells and tool changes: the cycle time that isn’t cutting, with a real time tool change simulation.
Peck drilling cycle time: G83 vs G73: why full retracts vs chip-break hops can swing run time more than feed rate.