---
title: "How to Estimate Cycle Time From a G-Code Program"
description: "Distance over feed, fixed costs, and a padding factor: hand-estimate any program's cycle time for quoting and scheduling, with a full worked example."
url: https://gcodepractice.com/journal/how-to-estimate-cycle-time-from-a-g-code-program/
canonical: https://gcodepractice.com/journal/how-to-estimate-cycle-time-from-a-g-code-program/
author: "Lawrence Arya"
authorUrl: https://www.linkedin.com/in/vibecoding/
published: 2026-08-15
updated: 2026-08-15
category: "Guides"
tags: ["cycle-time", "estimating", "quoting", "g-code", "feed-rate", "programming"]
lang: en
---

# How to Estimate Cycle Time From a G-Code Program

> **TL;DR** Estimate cycle time by dividing every feed move's length by its feed rate and rapids by the rapid rate, adding fixed costs (tool changes at 3-10 seconds, dwells at face value, per-hole cycle motion), then padding 10-20 percent for acceleration and corners, more for short-segment paths. Convert per-rev feeds through RPM, separate human time at M00 stops, sanity-check against material removal rates, and calibrate with a stopwatch on the first run.

You can estimate a program's cycle time from the code itself with nothing but arithmetic: every feed move takes distance divided by feed rate, every rapid takes distance divided by rapid rate, and the fixed events, tool changes, dwells, spindle reversals, each carry a known cost you add up. A hand estimate built that way, plus a 10 to 20 percent overhead allowance for acceleration and corners, lands close enough for quoting, scheduling, and sanity-checking a CAM simulation, and the skill pays in both directions: it prices work before the machine is free to test, and it flags the program whose simulated three minutes will really be six. The method takes longer to describe than to do, and after a few programs the major numbers, minutes per inch at common feeds, seconds per tool change, read straight off the page.

## The core arithmetic: time is distance over rate

A feed move's duration is its length divided by its feed rate. G01 X10.0 at F20.0 inches per minute takes half a minute; a 100 mm move at F500 mm/min takes 12 seconds. Arcs are the same once you know the arc length, and for estimating, chord-like approximations are fine: a quarter circle of radius R is about 1.57 R long. The only trap is the feed mode: an F word means nothing until you know whether [G94 per-minute or G95 per-rev](/journal/g94-vs-g95-feed-per-minute-vs-feed-per-rev/) is active, and per-rev feeds convert to time via RPM first. Feeds themselves trace back to chip load arithmetic, the territory of [calculating feed rate for G01](/journal/how-to-calculate-feed-rate-for-g01/) and the standard [speeds and feeds relationships](https://en.wikipedia.org/wiki/Speeds_and_feeds).

Rapids are the same division with the machine's rapid rate, which lives in the machine specification, commonly somewhere between 400 and 2,000 inches per minute on machining centers. Two corrections keep rapid estimates honest. Rapids on most controls move each axis at its own maximum, so a diagonal rapid finishes when the slowest axis arrives, not along the vector; for estimating, dividing the longest single-axis component by the rapid rate is closer than dividing the vector length. And short rapids never reach full speed, which is one of the places the overhead allowance earns its keep. The difference between the two motion types, and why [G00 is not just a fast G01](/journal/g00-vs-g01/), matters to the estimate's structure: programs heavy in short rapids are overhead-dominated, programs of long feed moves are arithmetic-dominated.

## The fixed costs: events that take time without moving far

| Event | Typical cost | Notes |
| --- | --- | --- |
| Tool change (M06) | 3-10 s chip-to-chip on modern VMCs | Older machines and big-taper spindles run longer |
| Dwell (G04) | Exactly as programmed | Check the seconds-vs-milliseconds format |
| Spindle speed change / reversal | 1-4 s | Large spindles and big speed jumps cost more |
| Canned cycle per hole | Feed down + retract + positioning | Multiply by hole count; retract mode matters |
| Pallet change | 10-30 s | Machine-specific, from the spec sheet |
| Program stop (M00/M01) | Human-dependent | Exclude from machine time, note separately |

Tool changes deserve the most respect because they multiply. A 20-tool program at eight seconds per change spends nearly three minutes changing tools before cutting anything; a program that changes to the same tool family repeatedly instead of grouping operations wastes minutes a reader can see in the code as alternating T words. Canned cycle time scales with hole count times per-hole motion: feed down at the cycle's feed, retract at rapid, plus the between-holes positioning, where the [G98/G99 return-plane choice](/journal/g98-vs-g99-canned-cycle-return-plane/) quietly adds or removes a quarter second per hole, real minutes on plates with hundreds of holes. Dwells are the easiest line items, exactly their programmed value, once the [P-word format quirk](/journal/g04-dwell-time-format-fanuc-vs-haas/) is checked.

Program stops are a bookkeeping decision: M00 waits for a human, so it belongs to part handling time, not machine cycle time, and quoting work should list it separately, because a job with two minutes of cutting and three minutes of operator flipping has very different economics than five minutes of cutting.

## A worked example, start to finish

A small aluminum plate job: face, profile, drill twelve holes, on a VMC with 800 in/min rapids and 6-second tool changes.

Facing: three passes of 8.0 inches at F40.0 is 24 inches at 40 in/min, 36 seconds, plus stepover rapids, call it 42. Profile: perimeter 22 inches at F25.0 is 53 seconds, plus lead-in/out, call it 58. Drilling: twelve holes, 0.55 inch feed depth at F8.0 is 4.1 seconds each feeding, retract and reposition roughly 1.5 seconds each under G99, 67 seconds total. Three tool changes at 6 seconds, 18. Rapids between operations, roughly 30 inches of long moves at 800 in/min with settle time, call it 8. Spindle changes, three at 2 seconds, 6.

Sum: 42 + 58 + 67 + 18 + 8 + 6 = 199 seconds, 3 minutes 19. Add 15 percent overhead for acceleration, corner slowdowns, and the short-move tax: about 3 minutes 50. A CAM simulation of the same part might report 3:10 because simulators often assume instant acceleration; the machine will likely clock between the two, nearer the padded figure. Quoting at four minutes of spindle time per part would be defensible; quoting at the simulator's three would quietly donate 20 percent of machine capacity.

That is the whole method. It reads long, but with the program in one hand it is ten minutes of arithmetic on a notepad, and the second estimate goes twice as fast because the machine's constants, rapid rate, tool change time, spindle ramp, are already written down. Shops that estimate regularly keep those constants on a card taped to the programming workstation, one card per machine, and the card is worth maintaining: a chip-to-chip tool change time measured once with a stopwatch replaces a brochure number that was measured under ideal conditions on a demonstration floor.

## Why estimates and reality diverge

Understanding the error sources makes the padding principled instead of superstitious. Acceleration is the big one: every move spends time ramping to speed and back, so programs made of many short moves run far below their commanded feeds; a 3D-surfacing program of thousand tiny segments can spend most of its life accelerating, and its hand estimate needs 30 percent padding or more, while a program of long straight cuts needs 5. Corner behavior compounds it, since [blending and exact-stop settings](/journal/g09-g61-g64-exact-stop-and-path-smoothing/) decide whether the machine slows at every direction change. Feed override is a human error source: estimates assume 100 percent, and a cautious operator at 80 stretches everything proportionally.

Simulators and estimators automate the same arithmetic with the same blind spots in cheaper tools, and good accounting in better ones: backplotters count distance over feed; machine-aware simulators model acceleration and are correspondingly closer. Whatever the tool, its output deserves the same scrutiny as a hand estimate, checked against a stopwatch on the first real run. The stopwatch closes the loop: after a few jobs where estimate and actual are both recorded, your personal overhead factor for that machine and that kind of work stops being a guess, and reading unfamiliar programs for time becomes part of [reading programs like an operator](/journal/understanding-a-cnc-program-as-an-operator/) generally.

One estimating shortcut deserves promotion because it catches gross errors instantly: the material-removal sanity check. A roughing operation removing 8 cubic inches of aluminum at a realistic 5 cubic inches per minute cannot take less than about 96 seconds no matter what the toolpath looks like, so any estimate or simulation below that is wrong somewhere. Removal-rate floors do not produce the estimate, but they veto impossible ones, which is often the more valuable service in quoting.

## Where the minutes hide: using estimates to improve programs

The estimating habit turns into an optimization habit almost by itself, because the arithmetic exposes where time actually lives. If tool changes dominate, group operations by tool. If canned-cycle air moves dominate, revisit the return planes and the hole ordering; if positioning dominates, reorder features to shorten the travel salesman's path. If a finishing pass at conservative feed dominates, that one F word is the entire cycle time conversation. Programs inherited from CAM defaults are full of such findable minutes, and the estimate is the map to them.

The commercial version of this skill is quoting confidence: cycle time times rate is the machining line of every quote, and shops that estimate well quote work that profits at prices that win. That connection between reading code and pricing work is one of the quiet reasons programmers out-earn operators, a gap explored in [how much more a CNC programmer makes](/journal/how-much-more-does-a-cnc-programmer-make-than-an-operator/): the arithmetic in this skill is literally the arithmetic of the shop's revenue.

## Bottom line: divide, sum, pad, verify

Cycle time estimating is distance over rate for every move, plus a table of fixed costs, plus a padding percentage matched to the program's character: 5 to 10 for long-move work, 15 to 20 for general milling, 30 and up for short-segment surfacing. Convert per-rev feeds through RPM, respect the seconds-versus-milliseconds dwell trap, count tool changes honestly, and separate machine time from human time at every M00. Then verify against a stopwatch and keep the correction factor. Four numbers on a notepad, and the program's economics stop being a mystery.

## Frequently asked questions

### How do I estimate cycle time from a G-code program?

Divide every feed move's length by its feed rate and every rapid's longest axis component by the machine's rapid rate, then add fixed costs: tool changes (3-10 seconds each), dwells at face value, spindle changes, and per-hole cycle motion times hole count. Sum everything and add overhead, 10 to 20 percent for typical milling, more for short-segment paths, to cover acceleration and corner slowdowns. Verify the first real run with a stopwatch and keep your correction factor.

### How accurate is a hand cycle time estimate?

Within 10 to 15 percent for programs of ordinary moves once you apply a sensible overhead factor, which is enough for quoting and scheduling. The dominant error source is acceleration: many short moves never reach commanded feed, so segment-heavy programs need bigger padding. Basic CAM estimates share exactly this blind spot and often read optimistic; machine-aware simulators model acceleration and come closer. A stopwatch on the first article calibrates any method within one job.

### What takes the most time in a typical CNC program?

Usually not what the eye expects. Tool changes multiply: twenty changes at eight seconds is nearly three minutes before any cutting. Canned-cycle air moves scale with hole count, where return-plane choices add or remove a quarter second per hole. Conservative finishing feeds often dominate single-handedly. The estimate exposes the actual distribution, which is why estimating and optimizing are the same skill: the biggest line item in the sum is the place to work.

### What is the best way to get faster at reading programs for time?

Fluency with the everyday codes is the prerequisite: you cannot time what you have to look up. Drilling the core vocabulary, motion codes, cycles, the feed modes, dwell formats, until it is instant recall is what a free app like G-Code Sprint does with short timed quizzes that repeat what you miss. After that, estimate one real program per week and check it with a stopwatch; the personal correction factor that emerges is worth more than any generic table.

### Should I trust the CAM simulator's cycle time?

Trust it as a lower bound and pad it. Simple backplot timers assume instant acceleration and perfect cornering, so they read fast, sometimes very fast on segment-heavy paths. Machine-aware simulators with acceleration models come much closer when configured with your machine's real parameters. Either way, compare against a material-removal-rate sanity floor and a stopwatch on the first run; a simulator that proves accurate for your machine and work style earns trust for the next similar job.

## Sources

- [Wikipedia: Speeds and feeds](https://en.wikipedia.org/wiki/Speeds_and_feeds)
- [LinuxCNC G-code reference](https://linuxcnc.org/docs/html/gcode/g-code.html)
- [CNC Cookbook: G-code program format and structure](https://www.cnccookbook.com/g-code-basics-program-format-structure-blocks/)

---

Source: https://gcodepractice.com/journal/how-to-estimate-cycle-time-from-a-g-code-program/
Author: Lawrence Arya — https://www.linkedin.com/in/vibecoding/