---
title: "Counting parts and cycle times on CNC mills and lathes"
description: "Count CNC parts and time each cycle from outside the control: what one cycle is, one operation per job, parts per cycle, and a hand count that proves it."
category: "Machines and connectivity"
author: "Applications Engineering Team"
published: "2024-09-12"
updated: "2026-10-20"
source_url: "https://www.iotflows.com/blog/cnc-cycle-time-and-part-counts/"
---
> Question: How do I get accurate part counts and cycle times from a CNC without the control?

## Key takeaways

- A vibration sensor on the spindle housing counts one cycle each time the trace falls back to idle, and times it.
- Count detected cycles on a CNC instead of dividing run time by an average cycle, because the job mix changes the error.
- Cycle time is stated per cycle, and quantity per cycle turns a cycle count into a part count.
- Set the ideal cycle time from cycles you timed on the machine, not from a CAM estimate or a padded quote.
- Validate every new setup against a hand count; an exact 2x or 0.5x error is a setting, not the sensor.

You get accurate part counts and cycle times from a CNC without the control by reading each cycle from outside the machine. A vibration sensor on the spindle housing sees cutting as a burst, counts one cycle each time the trace falls back to idle, and times it. Then you set one operation per thing the machine does, enter how many parts each cycle makes, and prove the count against ten hand-counted parts.

This guide is for manufacturing engineers and leads who already see when their mills and lathes run and now need counts they can put in front of a production meeting. For run state and stops across a whole fleet, start with [how to monitor CNC machines](/blog/how-to-monitor-cnc-machines/).

## What counts as one cycle on a CNC?

> **Definition.** **Cycle time (CNC)** is the time one machining cycle takes, from the start of the cut to the machine's return to idle, measured on the machine rather than estimated. One cycle can make one part or several, so cycle time is stated per cycle, never per part.

The [glossary entry for cycle time](/docs/get-started/glossary/#cycle-time) uses the same per-cycle rule. The Lean Enterprise Institute adds the part that matters most: cycle time is the time required to produce a part or complete a process “as timed by actual measurement”.[1] A number from a quote or a CAM printout is a target, not a cycle time.

Three different figures go by the name on a shop floor. Know which one a report shows before you compare it with anything.

| Figure | What it includes | Use it for |
|---|---|---|
| Machine cycle time | One complete cycle, cut to idle | Counting, performance |
| Effective machine cycle time | Cycle, load and unload, setup share | Quoting, capacity |
| Ideal cycle time | The best sustainable cycle you enter | Shift goals, the parts gauge |

Machine cycle time and effective machine cycle time follow the Lean Enterprise Institute's definitions.

*Effective machine cycle time* is the machine cycle plus load and unload time, plus the changeover time divided by the pieces made between changeovers.[1] LEI's own example is a 20-second cycle with 30 seconds of loading and a 30-second changeover over 30 pieces, which comes to 51 seconds a piece.[1]

**Effective machine cycle time** = Machine cycle + load and unload + (setup time ÷ batch size)

#### Worked example: A bracket on a vertical mill

- Machine cycle: 4 min 20 s (260 s), timed at the machine.
- Load and unload: 1 min (60 s).
- Setup: 45 min (2,700 s) for a batch of 30, so 90 s a part.

Effective cycle time is 260 + 60 + 90 = 410 s. At a batch of 120, the setup share falls to 22.5 s and the effective cycle to 342.5 s.

**Result:** Effective machine cycle time = 410 s, or 6 min 50 s, at a batch of 30

The machine cycle is what a sensor measures. The other two are calculated from it, which is why it has to be right first.

## How a sensor reads a cycle from outside

A CNC that is cutting vibrates well above its idle level. A sensor mounted on the spindle housing or the main motor casting reads that vibration, and a *running threshold* splits it in two: above the line the machine is running, below it the machine is idle.

Each time the trace crosses back below the threshold and stays there, one cycle ends. The time from crossing up to crossing down is the cycle time.

Figure: A vibration trace on a vertical mill rises above a dashed threshold for one 4 min 20 s cycle, dips briefly for a tool change that is merged into the cycle, then falls to idle for a 1 min load before the next cycle.

*One cycle read from outside: the tool-change dip stays inside the cycle, and the part load ends it. Sample data.*

Two things in a cut drop the trace for a moment without ending the part: a tool change and a probe move. A counting rule that merges short dips back into the cycle they interrupted keeps those as one part. A rule that counts every burst on its own splits the part in two, which is right on a press and wrong on a mill.

The [counting algorithm guide](/docs/production/choose-an-algorithm/#discrete) draws both rules on the same trace.

Where you mount decides how clean the trace is. A sheet-metal guard door rings on its own and hides the cut. Mount on flat ferrous metal tied to the spindle or the driveline, then run the machine cutting and idle and confirm the two read differently.

## Count cycles instead of dividing run time

There are two ways to turn running time into a part count. You can divide running time by a cycle time you entered. Or you can count the cycles the sensor detects.

Division works on a machine that runs one steady cycle all day. A CNC changes its cycle with every part, so division is right only on the days the job mix happens to match the average you typed.

#### Worked example: One machining center, two days, one entered average

- The machine runs two parts: a bracket at 3 min and a housing at 6 min. The operation is set to an average of 4 min.
- Monday: 60 brackets (180 min) and 20 housings (120 min), 300 running minutes, 80 parts.
- Tuesday: 20 brackets (60 min) and 40 housings (240 min), 300 running minutes, 60 parts.

Division gives 300 ÷ 4 = 75 parts on both days. Monday reads 75 ÷ 80 = 93.75% of the truth, Tuesday 75 ÷ 60 = 125%.

**Result:** Division error: 6.3% low on Monday, 25% high on Tuesday

Figure: Two days of 300 running minutes on one machine. Monday made 80 parts and division by a 4 min average reports 75, 6.3% low. Tuesday made 60 parts and division reports 75, 25% high.

*Same running time, same entered average, a different error each day. Counting cycles gets both days right. Sample data.*

Counting detected cycles gives 80 and 60, because it never assumes the cycles are equal. On a CNC, default to counting cycles.

> **Count cycles or divide run time?**
>
> Count detected cycles when cycle times vary with the part and the machine falls back to idle between parts, which describes most mills, lathes and machining centers. Divide running time by a measured cycle only when the trace never returns to idle between parts, such as a bar-fed lathe running one job unattended.

## Set up one operation per thing the machine does

An *operation* is one thing a machine does to a part, with its own cycle time. Every count, goal and cycle-time figure belongs to an operation, so how you split them decides what your reports can tell apart.

Create one operation per thing the machine does differently, not one per line on the router. Split two steps only when the cycle time, the counting rule or the machine differs. The [parts and operations model](/docs/production/parts-and-operations/#model) sets out the same rule.

| Situation on the machine | Operations to create |
|---|---|
| A lathe turns side one, then side two | Two: OP10 and OP20 |
| Two router steps, same rate, same machine | One |
| One part, run on two different mills | One, assigned to both |
| A high-mix shop, every job new | One general operation per machine |

With cycle counting, a general operation counts correctly. Its goal runs against an average cycle, so treat goals on it as approximate.

For example, a lathe that faces and turns side one in 2 min 40 s, then side two in 1 min 50 s after a flip, needs two operations. One operation at an average of 2 min 15 s would put every gauge on the wrong target.

You don't need a separate operation for every program revision. A new revision that runs at the same cycle on the same machine is the same operation.

## Set parts per cycle for fixtures and pallets

A cycle count and a part count are different numbers. The MTConnect standard keeps them as separate data items: a cycle count is the “accumulation of the number of times a cyclic function has attempted to, or is planned to attempt to execute”, and a part count is an “aggregate count of parts”.[3][2]

> **Definition.** **Quantity per cycle** is the number of finished parts one machine cycle produces, such as four for a four-station vise fixture or one for a lathe parting off a single part. A part count is the detected cycle count multiplied by the quantity per cycle.

Keep the cycle time per cycle and put the multiple in [quantity per cycle](/docs/get-started/glossary/#quantity-per-cycle). Dividing the cycle time by the number of stations gets nothing right when the system counts cycles: the count still reads one part per cycle, and the parts gauge falls to a quarter.

#### Worked example: A four-station vise fixture on a vertical mill

- One cycle machines four parts in 12 min.
- The machine runs 360 minutes in the shift, so it completes 360 ÷ 12 = 30 cycles.

Set up correctly, with a 12 min cycle and a quantity of 4, the count is 30 × 4 = 120 parts. Left at a quantity of 1, it reads 30 parts, exactly 25% of the truth.

**Result:** Part count = 30 cycles × 4 parts per cycle = 120 parts

Leave quantity per cycle at 1 unless one cycle yields more than one part, from a multi-station fixture, a pallet or a bar. It is the only setting that scales every count, so it is the first one to check when a count comes out at a clean multiple of the truth. The [quantity per cycle settings](/docs/production/cycle-times-and-filters/#qty) show where it lives.

## Measure the ideal cycle time

The ideal cycle time does not change the count when the system counts cycles. It sets the target everything else is measured against: the shift goal, the hourly goal and *performance*, the share of the running time the parts made would have needed at the ideal cycle. [Setting the ideal cycle time](/blog/ideal-cycle-time/) covers who owns the number and what a wrong one does to OEE.

**Performance** = (Parts made × ideal cycle time) ÷ (Running time)

1. **Pick a part you run often.** Choose a part with a settled program, not a first article.
2. **Time 10 to 20 consecutive cycles.** Time each cycle on a good day, from part load to part unload. For example, ten cycles of 4:15, 4:30, 4:10, 4:25, 4:20, 4:20, 4:15, 4:25, 4:20 and 4:20.
3. **Average them and note the range.** The ten cycles above average 4 min 20 s, with a 20-second range. Enter the average as the ideal.
4. **Watch the measured cycle for a week.** Compare the measured cycle time with the ideal before you change either one.

The source of the ideal moves performance more than the machine does. Take one shift where a mill made 60 brackets in 270 running minutes, an actual average of 4 min 30 s.

| Source of the ideal | Ideal cycle | Performance |
|---|---|---|
| CAM estimate | 3 min 30 s | 210 ÷ 270 = 77.8% |
| Timed at the machine | 4 min 20 s | 260 ÷ 270 = 96.3% |
| Padded quote | 5 min | 300 ÷ 270 = 111.1% |

Hypothetical shift. Performance is parts made × ideal cycle ÷ running time.

A CAM estimate comes from the toolpath. The machine adds acceleration, tool changes and probing on top, so the CAM ideal makes a good shift look slow.

A padded quote does the reverse, and a performance figure above 100% means the ideal is set too slow, not that the machine outran itself. [How to calculate OEE](/blog/how-to-calculate-oee/) works performance through with availability and quality.

A measured cycle that creeps up over days is often the machine telling the truth. Tool wear lengthens a cycle. Watch it for a week before you move the ideal to meet it, and use the corrected figure in your quotes and in [a schedule built on real run rates](/blog/production-scheduling-on-real-run-rates/).

## Validate against a hand count

A count that looks about right is not validated. Compare it with parts counted by hand over the same window, and read the ratio, not the difference.

**Count accuracy** = (System count) ÷ (Hand count)

5. **Run the machine normally for two to four hours.** Use a part the operation is set up for, with no special handling.
6. **Hand count the same window.** Count at least ten finished parts. Twenty parts made should read 20, give or take one or two.
7. **Divide and read the band.** At 95 to 105%, leave it alone. Between 90 and 95%, or 105 and 110%, tune the running threshold or the sensor mount. Outside 90 to 110%, something is set wrong.
8. **Change parts and check again.** Run a part with a different cycle time and repeat the count. A setup that only works on one part is not finished.

Figure: A scale of system count over hand count from 40% to 210%. The 95 to 105% band is working and 90 to 110% needs tuning. Exactly 50% or 200% points to parts per cycle; uneven low readings mean missed cycles, uneven high mean tool changes read as cycles.

*Read the ratio, not the difference: a clean multiple is a setting, an uneven miss is detection.*

The shape of the error tells you where to look:

- **Exactly 2.00 or 0.50.** Quantity per cycle is wrong. No threshold change fixes a multiplier.
- **High by an uneven amount.** Tool changes or probe touches are reading as cycles. Raise the running threshold, or recalibrate against full cycles.
- **Low by an uneven amount.** Short, light cycles are not separating from idle, or two fast cycles merge. Move the sensor closer to the spindle, or lower the threshold.

The [part count troubleshooting guide](/docs/production/troubleshoot-part-counts/) works through each symptom. You don't need to chase a count already inside 95 to 105%. Moving a setting to win back one part replaces a right number with a wrong one.

## Count CNC parts with IoTFlows

IoTFlows puts a SenseAi on each mill or lathe. It attaches magnetically near the spindle and reads vibration and sound from outside the machine, with no PLC or controller access. Discrete Analysis counts each detected cycle and merges short pauses back into the cycle they interrupted, so every part the machine runs reports its own count and cycle time.

The [CNC setup guide](/docs/production/cnc-machines/) covers mounting, one operation per thing the machine does and the hand-count check. Shift Production then shows each count against a goal calculated from the ideal cycle time. See [CNC machine monitoring](/solutions/cnc-machine-monitoring/) for the full picture.

> I use the dashboard every day to compare and validate actual cycle times against the times listed in our bills of material. This has helped improve accuracy, highlight deviations early, and support more informed decision-making across our manufacturing processes.
>
> Pete Gonella, Director of Manufacturing, Jesel ([story](https://www.iotflows.com/customers/jesel/))

## When the control's counter is the better source

The control knows things a sensor cannot feel: which program ran, which part number it was cutting and how many times the program reached its end. On a high-mix machine, the program name splits counts by job with nobody touching a screen.

A connection to the control is also a security concern for many plants, and IT usually reviews it first. [Some older controls have no network port at all](/blog/monitor-old-machines-without-a-plc/). The [sensor versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) lays out what each approach sees, with its sources.

| | Sensor on the machine | Control counter | Operator tally |
|---|---|---|---|
| Works on any brand or age | Yes | No | Yes |
| Times every cycle | Yes | Yes | No |
| Names the program per count | No | Yes | No |
| Needs an IT review | No | Yes | No |

Neither the sensor nor the control knows which parts were scrap. The good count is the total less the scrap your team logs with a reason.

Default to a sensor on every machine for counts and cycle times, because it reads every control the same way. Add the control's counter on the machines where a recurring question needs the program name, such as a high-mix cell where operators forget to switch jobs. Keep the operator tally for the hand-count check, not as the record.

## Questions

### Can a vibration sensor count parts on a lathe with a bar feeder?

It depends on whether the vibration trace falls back to idle between parts. If it does, count the detected cycles. A bar-fed lathe running one job unattended may never return to idle, and then dividing running time by a carefully measured cycle time fits better. Watch the trace over a few cycles before you choose.

### Should the ideal cycle time come from the CAM estimate?

No. A CAM estimate is calculated from the toolpath and leaves out time the machine adds, such as acceleration, tool changes and probing. Time 10 to 20 consecutive cycles on the machine on a good day, from part load to part unload, and enter that figure instead.

### Does a tool change split one part into two counts?

Not with a counting rule that merges short dips back into the cycle they interrupted. A rule that counts every burst on its own can split one part into two. If the count runs high by an uneven amount, check whether tool changes or probe moves are dropping the trace below the running threshold.

### How many parts should I hand count to validate a CNC count?

Count at least ten parts against the same window the system reports, and repeat the check after changing to a part with a different cycle time. A count that matches part for part over ten parts is right; a shift total that lands near the truth can hide two errors that cancel.

## Sources

1. [Cycle Time, Lean Lexicon](https://www.lean.org/lexicon-terms/cycle-time/), Lean Enterprise Institute, accessed Oct 16, 2026
2. [PartCount, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/EventTypes/PartCount/), MTConnect Institute, accessed Oct 16, 2026
3. [CycleCount, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/ObservationInformationModel/ObservationTypes/EventTypes/CycleCount/), MTConnect Institute, accessed Oct 16, 2026