---
title: "How to monitor CNC machines of any brand or age"
description: "Put a sensor on every CNC for run state, cycles and stops on any brand or age, then read the control over MTConnect where it pays. Includes a worked shift."
category: "Machines and connectivity"
author: "Mahmoud Parto"
published: "2024-04-15"
updated: "2026-10-20"
source_url: "https://www.iotflows.com/blog/how-to-monitor-cnc-machines/"
---
> Question: How do I see run state, cycles and stops on a mix of old and new CNC machines?

## Key takeaways

- A sensor on the outside of each CNC reports running, stopped, cycles and part counts the same way on every brand and age.
- The control adds what only it knows, such as alarm codes, program names and feed hold, on machines that can share it.
- MTConnect is read-only by design, and a machine built without it needs a custom adapter before it reports anything.
- CNC uptime depends on how much of the cycle an operator carries, so compare each machine with its own type and baseline.
- Ask for a stop reason only above a short-stop cutoff, so setup and waiting time stand out from chip clearing.

You see run state, cycles and stops on a mixed CNC fleet by putting a sensor on the outside of every machine, so a 1998 vertical mill and a 2023 five-axis report the same running, stopped, cycle and part-count data. Then read the control directly only on the machines where you need what the control alone knows, such as alarm codes and program names.

This guide is for plant managers and owners running mills, lathes and machining centers from several builders and decades. It works one hypothetical three-machine shift through, from the signal on the machine to the reason behind each stop.

## What to monitor on a CNC

> **Definition.** **CNC machine monitoring** means recording, for every mill, lathe and machining center, when it runs and when it stops, how many cycles it completes, how long each cycle takes and why each stop happened, so machines of any brand or age are compared on the same numbers.

Four numbers answer most of what a production meeting asks about a CNC.

*Run state* is whether the machine is cutting right now. *Uptime* is the share of the shift it spent running, as the glossary entry for [uptime](/docs/get-started/glossary/#uptime) defines it. Cycle count and cycle time say how much it made and how fast.

The fifth number, the reason for each stop, comes from people. A machine can tell you it stood for 14 minutes. Only the operator knows it was waiting for a fixture.

| Signal | Question it answers | Outside sensor | Control |
|---|---|---|---|
| Run state | Is it cutting now? | Yes | Yes |
| Cycle count | How many cycles ran? | Yes | Yes |
| Cycle time | How long did each take? | Yes | Yes |
| Stop length | How long did it stand? | Yes | Yes |
| Stop reason | Why did it stop? | From the operator | From the operator or an alarm |
| Alarm code | Which fault fired? | No | Yes |
| Program name | Which job ran? | No | Yes |
| Feed hold | Did someone pause the axes? | No | Yes |

The first four rows are the same in both columns. That is the point a mixed fleet turns on: run state, cycles and stops do not need the control at all.

## Why a mixed fleet is hard to read

A shop that bought machines over 25 years runs three kinds of control at once.

[Some have no network port](/blog/monitor-old-machines-without-a-plc/). Some have a builder's own interface. The newest ship with an MTConnect agent, software that serves the control's data in a shared vocabulary.

Each older control needs its own translation layer first. AMT's MTConnect use case for legacy equipment says devices designed without MTConnect in mind “will always require a custom adapter”, and that where no data can be extracted from a machine, implementing the standard would be impractical.[4]

The result is a fleet where the newest machines report and the oldest stay dark. For example, a shop with eight machines might get live data from the three bought since 2020 and nothing from the five that carry the most hours. Any comparison across the fleet then rests on the machines that happen to talk, not the ones that matter.

A connection to a control is also a security concern for many plants, and IT usually reviews it first. Plan that review into any project that reaches the controls.

## Read every machine from the outside

An outside sensor reads what the machine does, not what the control says. A vibration sensor on the spindle housing feels cutting as a burst of vibration well above the idle level. When the trace crosses a *running threshold*, the vibration level calibrated to separate cutting from idling, the machine reads as running.

Each fall back below the threshold ends one cycle. Count the falls and you have a cycle count. Time them and you have cycle times, which vary with the part on a CNC.

Figure: A vibration trace over 30 minutes on a vertical mill rises above a dashed running threshold for three cycles of about 4 min 20 s, separated by 1 min part loads, then stays at idle for an 11 min stop before a fourth cycle starts.

*Three counted cycles, three part loads and one 11-minute stop, all read from outside the machine. Sample data.*

The figure shows what that looks like on a mill. Three cycles of about 4 minutes 20 seconds are counted, each ended by a 1-minute part load. The 11-minute flat stretch is a stop, and it is the one worth a reason.

### Mount where the cutting is

Mount the sensor as close as you can to the spindle, the tool changer or the main motor housing. Pick flat ferrous metal tied to the parts that move, and keep it out of the coolant spray. The [mounting guide](/docs/hardware/install-senseai/#mounting) covers the spots that fail.

> **The guard door is the wrong spot**
>
> A magnet holds on a sheet-metal guard door, but the door rings on its own and passes little of the driveline's vibration. Mount on the casting instead, then run the machine cutting and idle and confirm the two read differently.

Calibrate against 5 to 10 complete machining cycles, not a spindle warm-up, so the threshold sits between real cutting and real idle.

### Count cycles that change with the part

A CNC runs a different cycle for every part, from 30 seconds to 30 minutes. Dividing run time by one fixed cycle time breaks the moment the job changes. Count the cycles the sensor detects instead, which is how [Discrete Analysis](/docs/production/choose-an-algorithm/#discrete) works, so the count stays right across a changeover.

You still record an ideal cycle time for each part. The count doesn't need it, but the shift goal and the performance figure do. The guide to [counting parts and cycle times on CNC mills and lathes](/blog/cnc-cycle-time-and-part-counts/) covers the setup in full.

## Read the control where it has more to say

The control knows things no sensor can feel: which program is loaded, which alarm fired, whether the operator pressed feed hold. On a machine with an MTConnect agent, those arrive as named data items.

MTConnect is read-only by design. The standard says its REST API “is read-only and does not produce any side effects on the agent or the equipment”.[1] A client reads the machine; it cannot load a program or clear an alarm.

> **Definition.** **Execution state (MTConnect)** is the operating state a CNC control reports through MTConnect, such as ACTIVE while it executes an instruction, READY while it is idle and ready to run, or FEED_HOLD when axis motion is commanded to stop.

MTConnect defines these execution values, among others:[2]

| Execution value | What the control is doing |
|---|---|
| ACTIVE | Executing an instruction |
| READY | Idle, ready to execute |
| FEED_HOLD | Axes commanded to stop in place |
| INTERRUPTED | Suspended by an external signal |
| OPTIONAL_STOP | Paused by a command in the program |
| PROGRAM_STOPPED | Stopped by the program; needs action |
| PROGRAM_COMPLETED | Program finished |
| STOPPED | Program not ready to execute |

Values from the MTConnect ExecutionEnum, model version 2.5. WAIT, added in version 1.5, pauses execution for a secondary operation.

The values explain why a sensor's “stopped” sometimes needs a second look. A sensor sees the spindle quiet. The control can say whether it is quiet because the program finished, because the operator held the feed, or because the program is waiting at an optional stop for a measurement.

*Controller mode* adds the other half, with values such as AUTOMATIC, MANUAL, MANUAL_DATA_INPUT, SEMI_AUTOMATIC and EDIT.[3] A machine reading READY in MANUAL for the first hour of a shift points to setup. The [protocol comparison](/blog/machine-communication-protocols/) covers MTConnect, OPC UA and Modbus side by side.

> **Sensor, control or both?**
>
> Default to a sensor on every machine for run state, cycles and stops, because it reads every control the same way. Add control data on a machine when a recurring question depends on what only the control holds: which alarm stops it, which program runs slow, or how often feed hold interrupts a cycle. You don't need control data to find out where the shift's hours went.

The [sensor-based versus PLC comparison](/compare/sensor-based-vs-plc-machine-monitoring/) lays out what each approach sees, with its sources.

## One shift on a mixed fleet

The numbers below follow three hypothetical machines through one shift, so you can see what a common data source makes comparable.

#### Worked example: Three CNCs, one 8-hour shift

- Shift: 480 minutes with a 30-minute lunch, so planned production time is 450 minutes per machine.
- 1998 vertical mill, manual loads: running 243 minutes. Its job has an ideal cycle time of 4 minutes 20 seconds, and it made 50 parts.
- 2012 lathe with a bar feeder, running automatic: running 351 minutes.
- 2023 five-axis machining center, operator-loaded: running 270 minutes.

Uptime is 243 ÷ 450 = 54.0% on the mill, 351 ÷ 450 = 78.0% on the lathe and 270 ÷ 450 = 60.0% on the five-axis. The mill's ideal output time is 50 × 4 min 20 s = 216.7 minutes, so its performance is 216.7 ÷ 243 = 89.2%.

**Result:** Fleet uptime = 864 ÷ 1,350 running minutes = 64.0%

Figure: Three shift timelines of 450 planned minutes: a 1998 mill runs 54.0% with a 96 min setup stop and 50 min of short stops, a 2012 bar-fed lathe runs 78.0% and a 2023 five-axis runs 60.0%. Fleet uptime is 64.0%.

*Each machine sits inside the range its loading method allows, and the mill's longest stop is setup. Sample data.*

Read each machine against its own type, not against the others.

A manual machine runs 40 to 60% of a shift, an operator-loaded one 50 to 70% and an automatic one 75 to 85%, per the [CNC setup guide's ranges](/docs/production/cnc-machines/#expectations). All three machines sit inside their range. Ranking the mill last because 54% is below 78% would send effort to the wrong place.

The useful question is where the mill's 207 stopped minutes went. In this shift, setup took 96 of them, short stops 50, waiting on material 25, first-article inspection 20 and tool changes 16. Setup is the largest single loss, and it was invisible until each stop carried a reason.

Performance at 89.2% is a separate question, which [how to calculate OEE](/blog/how-to-calculate-oee/) works through factor by factor.

Don't chase a fleet-wide spindle target either. Modern Machine Shop's Mike Lynch notes that some large-lot shops can justify almost anything to pass 95% spindle run time, while others accept under 20%.[5] Unless a CNC is the constraint for its cell, and the cell is the constraint for the company, there is no need to improve its productivity.[5]

## Give every stop a reason

Stop lengths say how much time you lost. Reasons say what to fix. Start with a short list built for machining, and add codes only when a reason keeps appearing as “other”.

| Reason | What it covers | Who acts on it |
|---|---|---|
| Setup and changeover | Fixtures, offsets, first program run | Setup lead |
| First-article inspection | Measuring the first good part | Quality |
| Tool change or breakage | Unplanned tool swaps, broken tools | Tooling |
| Waiting on material | No stock or blanks at the machine | Materials |
| Waiting on program | No released program or revision | Programming |
| Waiting on operator | Operator at another machine | Supervisor |
| Maintenance | Repairs and alarms needing a technician | Maintenance |

A starting list for machining. Add a code only when the same reason keeps landing in other.

Set a short-stop cutoff before you ask anyone to classify anything.

Below the cutoff, stops such as part loads, chip clearing and gauging are still recorded but never reach the operator's list. For example, the mill's 50 minutes of short stops were 50 stops under 2 minutes, nearly all of them part loads. A 2-minute cutoff keeps all 50 off the list, so the operator classifies four stops instead of 54.

You don't need operators to classify every stop. You need them to classify the ones long enough to fix.

The [short-stop settings](/docs/hardware/calibrate-senseai/#short-stops) show where the cutoff lives. Build the reason list by [creating a category](/docs/monitoring/downtime-categories/#create) for each code.

## Monitor CNC machines with IoTFlows

IoTFlows puts a [SenseAi](/products/senseai/) on each CNC. It attaches magnetically in seconds near the spindle, calibrates in under five minutes and reads vibration and sound from outside the machine, with no PLC or controller access.

Discrete Analysis counts every cycle, so each part a machine runs reports its own count and cycle time. Where coolant is unavoidable, the IP67 SenseAi Embedded mounts at the spindle motor.

On Enterprise, the IoTFlows edge device adds controller data over MTConnect and other protocols as a [custom integration](/platform/custom-integrations/). It reads only the controls you choose to connect.

Jesel, a valvetrain manufacturer in Lakewood, New Jersey, reviews OEE daily and validates actual cycle times against its bills of material. It [responds to an issue in seconds or minutes](/customers/jesel/), down from hours or days.

## Roll it out across the shop

1. **List every machine and how it runs.** Write down each CNC with its control, its age and whether it runs manual, operator-loaded or automatic. The loading method sets the uptime range you compare it with.
2. **Set shifts before reading a number.** Enter the plant's timezone and shifts first, because they decide which minutes count as planned. The [shifts and timezone guide](/docs/admin/shifts-and-timezone/) explains why they come first.
3. **Mount and calibrate one machine of each type.** Start with one mill, one lathe and one machining center. Calibrate each against 5 to 10 real cutting cycles.
4. **Validate the count by hand.** Run two to four hours, then compare the recorded count with a hand count over the same window. A count that reads exactly double or half is a quantity-per-cycle setting, as [troubleshooting part counts](/docs/production/troubleshoot-part-counts/) explains.
5. **Set each goal from its own baseline.** After a week, set each machine's uptime goal at its own baseline plus 5 to 10%. A goal a machine has never met teaches operators to ignore the number.
6. **Rank the stops after two to four weeks.** Read the classified stops off a [Pareto of downtime reasons](/docs/monitoring/downtimes/#pareto), and work the largest reason down first.
7. **Add control data where a question needs it.** Pick the machines whose recurring stops need an alarm code or a program name to explain, have IT review the connection, and connect only those.

Once the first three machines read correctly, copy their setup to the rest of the fleet. More machine-by-machine guides are under [machines and connectivity](/blog/topics/machines-and-connectivity/).

## Questions

### Can MTConnect change a program or setting on a CNC?

No. The MTConnect standard defines its REST API as read-only, with no side effects on the agent or the equipment. A client can read execution state, controller mode, part counts and alarms, but it cannot load a program, edit an offset or clear an alarm through MTConnect.

### What uptime should a CNC machining center reach?

It depends on how much of each cycle an operator carries. A manual, operator-intensive machine often runs 40 to 60% of the shift, an operator-loaded one 50 to 70% and a fully automatic one 75 to 85%. Set each goal from that machine's own baseline plus 5 to 10% rather than from a fleet average.

### Do I need a network port on an old CNC to monitor it?

No. A vibration sensor mounted on the spindle housing or the main motor casting reads running, stopped, cycle counts and cycle times from outside the machine. It needs power and a wireless connection of its own, and it never connects to the control, so the age of the control does not matter.

### How do I check that a CNC part count is right?

Let the machine run normally for two to four hours, then compare the recorded count with a hand count over the same window. Twenty parts made should read 20, give or take one or two. A count that reads exactly double or half points to the quantity per cycle setting, not to the sensor.

## Sources

1. [MTConnect Standard Part 1.0: Fundamentals, Version 2.5.0](https://docs.mtconnect.org/MBSD_MTConnect_Part_1_2-5-0.pdf), MTConnect Institute, accessed Oct 16, 2026
2. [ExecutionEnum, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/Profile/DataTypes/ExecutionEnum/), MTConnect Institute, accessed Oct 16, 2026
3. [ControllerModeEnum, MTConnect SysML Model V2.5](https://model.mtconnect.org/Version2.5/Profile/DataTypes/ControllerModeEnum/), MTConnect Institute, accessed Oct 16, 2026
4. [Digital Manufacturing for Legacy Equipment Using a Standards-Based Approach: An MTConnect Use Case](https://www.amtonline.org/article/digital-manufacturing-for-legacy-equipment-using-a-standards-based-approach), AMT, The Association For Manufacturing Technology, accessed Oct 16, 2026
5. [Judging Acceptable Spindle Run Time](https://www.mmsonline.com/columns/judging-acceptable-spindle-run-time), Modern Machine Shop, accessed Oct 16, 2026