Step-by-Step: Extract Accurate Cycle and Standard Times from G-code to Drive Throughput KPIs

Accurately extracting cycle and standard times from G-code gives production planners and shop managers the numbers they need to set realistic throughput targets and balance machine capacity without adding headcount. This guide on G-code cycle time extraction shows how to turn raw CNC programs into validated machine cycle times, convert those into shop-level standard times, and feed reliable figures into planning and ERP dashboards. Read on to learn which inputs matter, how to parse and model motion, where acceleration and auxiliary times bite, and how to validate computed times against measured runs.

TL;DR:

• Extract G-code blocks and compute the basic move time; expect non-cutting actions to add 30–50% on many small-part programs.

• Validate computed motion time with a dry-run or short sample of live runs and iterate until computed vs measured is within ±5–10%.

• Convert machine-only cycle time into a shop standard time by adding setup/inspection/handling allowances, then publish to ERP/MES for throughput and takt calculations.

Step 1: Gather prerequisites — files, machine profiles, and objectives

What you need: G-code files, machine kinematics, and tooling list

Start by collecting the raw inputs. At minimum, gather:

• The complete G-code program(s) (vendor file and post-processed NC file) in text form.

• Controller dialect: Fanuc, Heidenhain, Siemens (different canned-cycle semantics).

• Machine profile: travel limits, axis gearing or ball-screw pitch, maximum feed rates, axis acceleration and jerk limits if available.

• Spindle specs: rated RPM range and recommended ramp times.

• Tooling list and holder lengths, plus tool-change method (turret, arm-style ATC, manual).

• Pallet/fixture actions and any automated clamping or probing steps.

• Operator tasks for the operation: loading/unloading, inspection, deburring, and part handling.

Sample checklist (copy into your planning doc):

• G-code file(s) — confirmed program version and revision

• Controller family and NC parameters file

• Axis max feed and acceleration (X/Y/Z)

• Spindle ramp and M-code mapping

• Tool change time estimate (example: 20–120s depending on ATC style)

• Material handling per part (typical: 5–30s)

• Batch size and expected takt/shift targets

Industry guidance on measurement and time study methods can help here—research such as the NIST manufacturing publications gives context on measurement uncertainty and repeatability. For drilling-optimization research that extracts and reworks drilling G-code programmatically, see this study on G-code extraction and optimization Develop Software to Extract and Optimize Drilling G-Code Using a ….

Define the KPI targets to drive (throughput, OEE, takt time)

Decide up front what you will use the computed times for: hourly throughput targets, shift capacity planning, OEE performance baselines, or takt-time alignment for assembly. That affects how conservative your allowances must be. For example, if the goal is to set a takt time for mixed-model assembly, include operator material handling explicitly. If the aim is machine-level capacity planning, a machine-only cycle time with minimal allowances is appropriate.

Trade-offs matter: pushing for higher utilization can reduce buffer allowances and risk late deliveries. Record your KPI objective in the same folder as the G-code analysis so assumptions remain auditable.

Step 2: Parse the G-code — identify motion blocks, canned cycles, and program flow

Detect motion types: rapid, linear, and arcs

Tokenize the NC file into blocks and identify the core motion types:

• G0 = rapid traverse (axis-limited interpolation)

• G1 = linear interpolation at programmed feed

• G2 / G3 = clockwise/counterclockwise circular arcs Also capture feedrate (F) tokens and units (G20/G21 for inch/mm). A parser should emit a sequential move list with start/end coordinates and feed values.

LinuxCNC and other open-source resources describe G-code semantics in depth; see the LinuxCNC G-code reference for controller-level behavior and examples: LinuxCNC G-code reference.

Locate canned cycles, subprograms, M- and T-codes

Canned cycles (G81–G89), dwell (G04), tool changes (M6), spindle on/off (M3/M4/M5), program end (M30), and conditional calls affect timing outside pure axis motion. Parsing must expand canned cycles into the equivalent move and dwell sequences, or annotate them so a higher-level routine can compute their implied times.

Controller dialects matter: Fanuc canned cycles sometimes behave differently from Heidenhain cycles when it comes to dwell insertion or dwell suppression in certain modal states. Industry papers on supply chain and process modeling recommend modeling conditional logic explicitly when converting process steps into KPIs; see the predictive performance management model for an approach to model-based measurement Proactive supply chain performance management with predictive

Map program flow and conditional logic

Identify subprogram calls (M98/M99, O-calls), loops, and conditional feed overrides. Many modern programs use parametric subprograms that repeat a hole pattern; parsing should expand these to full move sequences or record a repeated template with a repeat count.

Example parsing output (trimmed):

• Block 001: G0 X0 Y0 Z5 (rapid) — travel 50 mm

• Block 002: G1 Z-5 F300 (linear) — cutting entry length 5 mm at 300 mm/min

• Block 003: G2 I10 J0 F400 (arc) — arc radius 10 mm clockwise

For a deeper walkthrough of parsing patterns and extracting cycle segments, see our seven-step guide.

Step 3: Compute theoretical motion time for each move — G-code cycle time extraction

Linear moves: distance / feedrate with feed-unit handling

Compute the basic time for a linear move with the straightforward formula:

• time (min) = distance (mm) / feedrate (mm/min) Example: 200 mm linear cut at 1,000 mm/min → 200/1000 = 0.2 min = 12 s.

Be careful with feed units: convert in/min to mm/min when G20 (inches) is active. Capture modal F values—feed can be modal and only appear once.

Arc moves: arc length calculation and feed application

For arcs, compute arc length from start/end and center or radius:

• arc length = radius × angle (in radians) If the G-code gives I/J center offsets, compute the angle using atan2 and normalize.

Apply the programmed feedrate to the arc length for basic time. Example: 90° arc of radius 10 mm → length = 10 × π/2 ≈ 15.71 mm. At 600 mm/min → 1.571 s.

Rapid moves and tool approach behavior

Rapids (G0) use the machine's rapid traverse limits per axis; time is not simply distance/rapidfeed because axes move concurrently and limits differ. Use the machine kinematics to compute the largest-axis-limited duration or run a simple conservative approximation based on path projection and axis speeds.

Caveat — acceleration and decel: the simple distance/feed formulas assume steady-state speed. For short moves, acceleration and deceleration dominate. Flag moves below a threshold (for many machines, under 30–50 mm) because their actual time can be 2–5× the steady-state estimate. As a practical approach, tag moves under 50 mm and apply a correction factor or compute using an acceleration profile if axis acceleration data is available.

For a practical workflow to convert parsed move lists into time-stamped estimates, consult this extraction workflow for step-by-step scripting tips: extraction workflow.

Step 4: Adjust for machine behavior — acceleration, jerk, spindle ramp, and auxiliary times

Model acceleration and deceleration losses

There are two reliable methods:

• Physics model: integrate a trapezoidal or S-curve motion profile from axis acceleration/jerk specs to compute exact time for each move.

• Rule-based corrections: apply short-move penalties and a per-move overhead for direction changes.

If acceleration data is available, compute time as the sum of acceleration, cruise, and deceleration phases. If not, use rule-based adjustments:

• Moves <50 mm: multiply steady-state time by 2–5× depending on estimated acceleration.

• Direction reversals and successive short moves: add 5–15% per direction-change cluster.

Sensitivity testing helps: change acceleration by ±10% in your model and observe total cycle change. Many small-part programs see big swings from acceleration assumptions.

Factor in spindle ramp, tool change, and pallet/fixture operations

Auxiliary times often exceed cutting time on small parts. Typical ranges:

• Spindle ramp: 2–8 s to reach programmed RPM (depends on spindle drive and RPM delta).

• Tool change: 20–120 s (turret-style tools at the low end; automatic tool changers with tool prefetch 20–40 s; robot or manual changes longer).

• Probing: 5–30 s, depending on probe cycles and data processing.

Add these as distinct events in the timeline. For example, a 120 s computed cutting-only cycle may actually be 180–240 s once tool change and spindle ramp are included for batch-first-part operations.

Include dwell, probing, and part-handling times

Dwell (G04) and M0/M1 program stops introduce non-deterministic waits if an operator must respond. Where possible, instrument and measure actual pause durations rather than assuming dwell times.

Document a per-operation machine profile with these parameters and version it in your repository. Different servo tuning and firmware versions (Fanuc vs Heidenhain vs Siemens) change acceleration, jerk, and look-ahead behavior; keep a profile per model.

For industry standards and test codes related to machine tool behavior, consult the ISO machine tool test standards such as ISO 230-1 for context on acceptable test procedures: ISO 230-1 test code for machine tools.

Step 5: Validate with simulation and shop-floor measurement (embed video)

Run a software simulation or dry-run to produce a timestamped trace, then compare computed times to measured durations.

First, run a simulator or controller dry-cycle:

• Use your CAM/NC verification (Mastercam, GibbsCAM, Fusion 360, or controller backplot) to confirm motion sequences.

• Export or record a timestamped log from the simulator if available.

Second, capture a live trace:

• Record program start/stop, spindle on/off, and a part-present sensor during a short sample of runs.

• Minimal instrumentation can be as simple as a time-synced video or I/O logging of M-codes.

Third, compare and iterate:

• Compute the percent difference for the full cycle and for segments. Acceptance criteria: aim for computed cycle time within ±5–10% of measured for repeat jobs. If computed vs measured differs by >15%, dig into the segments with the largest discrepancy.

What to measure and why:

• Compare computed tool-change time vs actual — tool changes are often the largest single source of mismatch.

• Check short-move clusters where acceleration effects are underestimated.

• Use median of 5–10 runs to reduce outlier influence; variability often comes from human tasks.

The linked video demonstrates running a G-code simulation, extracting move timings, and comparing simulation output to measured runs so planners can reproduce the validation workflow. For low-hardware cycle-time capture options, see our practical guide to minimal hardware monitoring and trace collection on the shop floor: cycle time monitoring.

Step 6: Convert cycle time to a standard time and map to throughput KPIs

Define allowances: setup, inspection, delays, and fatigue buffers

Cycle time from G-code is a machine-centric number. Standard time for planning must include allowances relevant to the operation:

• Setup allowance (per batch): machine setup, program load, fixturing (example: add a fixed 600 s for first part of a batch).

• Inspection allowance: periodic gage or CMM checks (e.g., 5% of cycle per batch or 30 s per 50 parts).

• Material handling and load/unload per part (example: 10–25 s).

• Personal, fatigue, and contingency allowances (commonly 3–10% depending on labor intensity and risk).

From sample cycle to standard time (apply allowances and multipliers)

Example conversion:

• Computed machine cycle = 120 s

• Add spindle/tool auxiliary (measured) = 18 s

• Add material handling per part = 12 s Subtotal = 150 s

• Apply inspection allowance 5% = +7.5 s → 157.5 s

• Apply personal allowance 8% = +12.6 s → standard time = 170.1 s

Document the allowance rationale; trace it back to measurement or company policy.

Translate standard times into KPIs: throughput, takt time, and expected capacity

Compute throughput:

• parts per shift = (shift seconds) / (standard time) Example: 8-hour shift = 28,800 s. Standard time 170.1 s → ~169 parts/shift per machine.

Compute takt time when you have customer demand and available production time:

• takt = available production time / customer demand

Accurate standard times improve schedule reliability and OEE calculation:

• OEE = Availability × Performance × Quality Accurate cycle and standard times make the Performance factor meaningful and prevent planners from overcommitting machine workloads.

For advice on using operation times to improve scheduling and capacity planning, see our post on how to plan operations.

Step 7: Automate extraction and integrate with dashboards/ERP

Build repeatable parsing pipelines (scripted or tool-based)

Automate parsing with scripts (Python is common) that:

• Tokenize blocks, expand subprograms and canned cycles, and compute preliminary times.

• Store results in a standardized JSON or CSV schema with per-move timestamps, segment flags (cutting, rapid, tool change), and computed durations. Open-source solutions and CAM post-processors (Mastercam, Fusion 360 post-processors) can both simplify and complicate this step—decide on a single canonical NC variant for analysis.

Export standardized time records to ERP/MES or shop-floor dashboards

Push standardized time records into ERP/MES as routings or operation standards, or feed to a shop dashboard for live capacity planning. Integrations vary by shop: use the machine-connectivity approach that fits your environment. For practical options and a how-to on connecting machines for monitoring, see our article on how to connect CNC machines and get free machine monitoring. For automating manual interventions and data flows between CNC and ERP/MES, see our guide on CNC–ERP integration.

Governance matters: version your machine profiles and G-code analyses so changes in feeds, tooling, or controller parameters are auditable. Store measured runs alongside computed runs for continuous improvements.

Continuous improvement: loop measurement into updates

Set a cadence to reconcile computed vs measured times:

• For stable jobs, revalidate quarterly or after tooling changes.

• For newly programmed jobs, validate within the first batch or first 5–10 pieces.

Automating this loop reduces planner time. Shops that automate G-code parsing and validation report fewer manual time studies and faster quoting turnaround—time savings depend on shop size and job mix but can cut planner hours by 30–60% on repetitive quoting tasks.

Common mistakes and troubleshooting when extracting times from G-code

Ignoring controller-specific canned-cycle behavior

Symptom: computed hole cycles are consistently faster than measured. Test: expand canned cycles and compare to controller simulator. Fix: implement controller-specific canned-cycle expansion or run controller dry-run for validation.

Underestimating acceleration and short-move penalties

Symptom: short-move clusters show large percent error. Test: isolate short moves (<50 mm) and run them on the machine with I/O timestamps or camera. Fix: apply acceleration model or short-move correction factors.

Using single-run measurements instead of aggregated samples

Symptom: standard time bounces between runs. Test: compute median over 5–10 runs and check variability. Fix: use median or mode and capture contextual metadata (operator, batch size).

Forgetting operator or material-handling allowances

Symptom: throughput targets unmet despite machine availability. Test: time the load/unload and inspection processes separately. Fix: incorporate per-part handling times and batch-level setup allowances.

Troubleshooting checklist when computed vs measured mismatch >15%:

• Re-run parsing and ensure G-code version matches the file loaded to the controller.

• Capture live I/O signals (spindle, part present) and align timestamps.

• Check tool-change and probe durations in live logs.

• Run focused time studies on problematic segments and update machine profile parameters.

If mismatch persists after model updates, run a longitudinal study across shifts and operators to identify human or process variability.

The Bottom Line

Accurate G-code cycle time extraction converts NC programs into repeatable machine cycle times that, when validated and adjusted for machine and human factors, become reliable shop standard times. Use systematic parsing, acceleration-aware motion modeling, and short-run validation to get computed times within ±5–10% of measured values, then publish standards into ERP/MES for realistic throughput planning.

Frequently Asked Questions