G-code Time Auditor
Paste a program and see where the seconds actually go — cutting, rapids, air cuts, tool changes, dwells — and how much of it you could take back. Runs entirely in your browser.
Program
Runs entirely in your browser — your program never leaves this page.
Machine assumptions
Feed moves entirely above “top of stock” are counted as air cutting; a pass at the top itself (facing) counts as cutting.
Estimated cycle time
2:29
This program spends 49s not cutting (33%).
Rapiding through the air moves alone would reclaim ~18s.
Where the seconds go
| Category | Time | Share | Moves |
|---|---|---|---|
| Cutting | 1:40 | 67.4% | 26 |
| Rapids | 5s | 3.0% | 22 |
| Air cutting | 18s | 12.1% | 2 |
| Tool changes | 18s | 12.1% | 3 |
| Dwells | 8s | 5.4% | 4 |
Toolpath (XY view)
Solid = feed moves (blue cutting, amber air) · dashed = rapids.
Top time sinks
Longest stretches where the tool isn't cutting.
- 1. Lines 20–259s air cutting + 6s tool changes + 1s rapids16s
- 2. Lines 34–369s air cutting + 0s rapids9s
- 3. Lines 45–496s tool changes + 1s rapids7s
- 4. Lines 5–96s tool changes + 0s rapids6s
- 5. Lines 63–652s dwells + 1s rapids3s
Why audit instead of pushing feeds?
When a job runs long, the reflex is to push feeds and speeds — and fight physics at the cutting edge for single-digit gains. But in most programs, a large share of the cycle is moves that never touch the part: conservative retracts, feeding through empty air, tool changes that could be grouped. That time is free to take back, with zero new risk at the edge. I wrote up the full method in where CNC cycle time actually hides — this tool is that post, running on your program.
The method: measure first, then attack the single biggest non-cutting bucket — delete the air, tighten the retract, reorder the tools — re-run the audit, and repeat. For real numbers off a running machine instead of estimates, you can timestamp run states straight off the control with FOCAS.
Frequently asked questions
How does the auditor estimate cycle time?+
It parses the program block by block, tracks position and modal state, and times every move at its commanded velocity: feed moves at the active F word, rapids at the rapid rate you set, tool changes at a fixed seconds-per-change, and G4 dwells at their commanded duration. Arcs (G2/G3) are timed along their true arc length.
Why is the estimate different from what my machine shows?+
The auditor uses ideal velocities — it doesn't model acceleration, corner slowdowns, exact tool-change kinematics, or look-ahead. Programs full of short moves will run slower in reality than the estimate. That's fine for the tool's job: finding where time hides and comparing before/after versions of a program, not quoting.
What counts as air cutting?+
Any feed-rate move (G1/G2/G3) that starts and ends strictly above the 'top of stock' Z you set — a pass at the stock top itself (facing) still counts as cutting. Feeding through empty air at cutting feedrate is pure waste: the same move at rapid costs almost nothing, which is exactly the recoverable time the receipt reports.
Does my program get uploaded anywhere?+
No. The parser runs entirely in your browser — nothing is sent to a server, and the page works offline once loaded. Your G-code never leaves your machine.
Which G-codes are supported?+
G0/G1/G2/G3 motion in the XY plane (with helical Z), G4 dwells (P in milliseconds, X/U in seconds), G20/G21 units, G90/G91 absolute/incremental, F feed words, and M6 tool changes. Canned cycles, feed-per-rev (G95), subprograms, and rotary axes aren't modeled — the tool warns when it sees something it can't time.
Got a program that runs too long?
Cycle-time reduction is exactly the kind of work I do — a 45 → 20 minute cut is on my résumé.