Machine Monitoring System Signals Explained (Cycle, Spindle, Alarm)

Machine Monitoring System Signals Explained: Cycle, Spindle, Alarm, Power, Part-Count

One of the most expensive myths in a CNC shop is that “the system says the machine is running,” so the number must be true. In reality, machine monitoring signals are instruments—each measuring a different slice of behavior. If you treat power, cycle, spindle, alarm, and part-count as interchangeable definitions of running, you’ll get fast dashboards and slow decisions: inflated utilization, “clean” downtime reports that miss waiting, and shift comparisons that don’t match what supervisors see.

This article focuses on the practical problem mid-market CNC job shops run into first: signals disagree. The goal isn’t more metrics—it’s choosing the right primary signal for the decision you’re making so you can recover hidden time before you consider adding people, overtime, or another machine. (For broader context, see machine monitoring systems.)

TL;DR — Machine Monitoring System Signals Explained

• “Running” depends on the signal: power, cycle, spindle, alarm, and part-count measure different behaviors.

• Power-on is closest to availability, not production; it routinely overstates capacity.

• Cycle is usually the best “are we producing?” signal, but it can miss certain automation sync states.

• Spindle helps expose micro-stops inside a cycle window (feed holds, optional stops), but it isn’t throughput.

• Alarm-free does not mean productive; most big losses are non-alarm waiting and process holds.

• Part-count must be validated against cycle/spindle patterns; bad logic can “create parts” on paper.

• When signals conflict, pick a primary signal per question and use others as corroboration—not as substitutes.

Key takeaway If your ERP says you’re busy but the floor feels starved, it’s often a signal-choice problem: power and “no alarm” can hide waiting, while cycle and spindle reveal different kinds of loss. Treat signals as instrumentation, then standardize which one is “primary” for utilization, micro-stops, and throughput so shift-to-shift comparisons are real—and recoverable time shows up before you spend on more capacity.

Why machine monitoring signals disagree (and why it matters)

A single CNC can be “on,” “not cycling,” “not alarming,” and “spindle stopped” at the same moment—and none of those statements are wrong. They’re simply answering different questions. Power answers “is it energized?” Alarm answers “is it faulted?” Cycle answers “is the control executing?” Spindle answers “is the spindle commanded on?” Part-count answers “did the configured event happen?”

Where shops get burned is choosing the wrong signal as the source of truth. That’s utilization leakage: the monitoring system reports healthy “run time,” but the schedule still slips because the time being counted isn’t the time that produces parts. The result is false confidence (“we’re loaded”), mis-labeled downtime (“no alarms, so it must be fine”), and slow decision-making because everyone argues about the metric instead of the constraint.

Multi-shift shops feel this first. Shift comparisons get distorted when night shift leaves machines powered and warmed up, day shift runs more interruptions (first-article approvals, inspection checks, meetings), and you’re trying to reconcile what the ERP says versus what pacer machines actually did. The goal of this article is straightforward: pick the right primary signal for the decision you’re making, then use other signals as corroboration—never as replacements.

Cycle signal: what it proves, what it misses

Cycle is usually the closest proxy for “the control is executing a program.” On many machines, it’s the cleanest way to separate “making a part” from “waiting/setup,” especially when you’re trying to understand why promised dates don’t match the feel of the floor. But cycle definitions vary by control and by how the signal is integrated, so treat it as measurement—not truth.

When cycle is mapped well, it’s typically best for answering: “Are we producing right now?” and “How much time did we spend actually executing programs this shift?” It’s also a practical backbone for machine utilization tracking software because it lines up with how most shops think about in-process work.

What cycle can miss (or misrepresent) are the edge cases that matter in real CNC work:

• Probing and measurement routines that run as macros or subroutines—sometimes counted as cycle, sometimes not, depending on how the state is derived.

• Optional stop behaviors (M00/M01): cycle might drop, or it might remain “in cycle” while the operator is deciding, measuring, or waiting for approval.

• Robot/barfeeder synchronization states: depending on the wiring/logic, the machine may be “not cycling” while the cell is still progressing through an automated handoff.

Operational risk goes both ways. Cycle-only can undercount productive automation time if the cell pauses the CNC while external equipment loads/unloads. And cycle-only can overcount if feed holds or optional stops don’t drop the cycle state—making a machine look “busy” while it’s paused in place.

Spindle signal: closer to cutting time—without being throughput

Spindle-on is often a better proxy for “metal is being worked” than cycle. It’s the signal that can expose inefficiencies hidden inside a long cycle: pauses, feed holds, optional stops, inspection prompts, and other micro-stoppages that don’t always show up as clear cycle-off gaps. In other words, spindle helps you see why a program that should be steady looks choppy across shifts.

But spindle isn’t throughput. A spindle can be on during warm-up cycles, dwell, and even air cutting. And it can be off during necessary work that still consumes capacity (tool changes, part loading, gauging, deburr prompts, pallet changes). Optimizing only to spindle time can push the wrong behaviors—especially in high-mix work where setup quality and first-pass yield matter.

Required scenario: frequent micro-stops. A common disagreement pattern looks like this: cycle remains “on,” but spindle toggles off repeatedly because the operator hits feed hold, an optional stop is used as a checkpoint, or the process requires door open/inspection confirmations. If you rely on cycle alone, you may conclude the machine ran continuously and the problem is “somewhere else.” What’s actually happening is stop-and-go inside the program window. For the question “Where are micro-stops killing us?” spindle transitions should be primary, with cycle as the boundary that tells you those stops occurred during an active job—not during setup or waiting.

A practical way to use spindle is as a diagnostic lens: “Within cycle windows, how often does spindle drop, and is it clustered by operator, shift, or part family?” That’s faster than debating a single utilization number and helps focus improvement on repeatable patterns.

Alarm signal: what ‘no alarm’ does NOT mean

Alarm is a fault-state signal. It’s valuable because it’s unambiguous: the machine is in a condition that typically requires intervention. That makes alarm data useful for maintenance response prioritization and rapid triage—without needing any predictive framing.

The trap is assuming “no alarm” means productive. Many of the biggest capacity losses in job shops aren’t alarms at all: waiting for an operator, material shortage, queue starvation, waiting on inspection, first-article approval holds, staging issues, or a cell blocked by a downstream process. Cycle can be off. Spindle can be off. Alarm stays clean. If you use alarms as your downtime truth, you’ll generate reports that look reassuring while the schedule keeps missing.

Alarm also won’t capture stoppages caused by M00, feed hold, door open, or intentional pauses. Those matter operationally because they affect staffing, handoffs, and how quickly work flows through WIP. This is where pairing alarm with a real downtime workflow (reason codes and context notes) becomes important—but the alarm signal alone is never the full story. If you want the “visibility layer” for stops and gaps rather than fault codes, start with machine downtime tracking concepts: you’re trying to capture non-alarm losses that the control will never label for you.

Power signal: the most misunderstood ‘utilization’ input

Power monitoring is attractive because it can be simple to deploy, and it works even on older equipment where richer control data may be limited. The problem is conceptual: power-on usually means “machine available,” not “machine producing.” If you use power as utilization, you’ll almost always overstate capacity and delay corrective action because the number looks better than reality.

Required scenario: power on for hours while actually idle. Imagine a machine that appears “running” for hours because it’s powered and ready, but it’s actually idle while an operator waits on first-article approval. In this window: alarm stays clear, spindle is off, cycle is off. A manager looking at power-based “runtime” might incorrectly conclude the job is progressing and the bottleneck is downstream. What’s actually happening is a quality/approval hold starving the machine. For the question “Is this machine producing?” power should be ignored; cycle should be primary, with spindle as corroboration.

Required scenario: night shift looks better than day shift. In some shops, night shift “utilization” looks higher simply because machines are left powered with spindles on for warm-up, probing routines, and long tool changes. Power and spindle can stay on and make the shift look great on paper. Cycle often reveals a truer picture of production time—but cycle can also miss some automated barfeed/robot behavior unless it’s configured to recognize those sync states correctly. The operational takeaway is to compare shifts using the same primary signal (typically cycle), then use spindle patterns to explain why cycle time is being lost inside the shift.

When is power acceptable? As a coarse availability/uptime indicator (are machines being shut down off-shift?), or as a fallback idle detector when nothing else exists. But it should not be your main capacity model if you’re making scheduling promises, deciding overtime, or thinking about buying another machine.

Part-count signals: what counts as a ‘part’ depends on wiring and logic

Part-count feels like the most business-friendly signal—until it’s wired or programmed to count the wrong event. Part-count can come from CNC macro variables, M-code triggers, PLC outputs, barfeeder events, or pallet/chuck cycle events. Each can be valid, but only if it maps to “good part complete” (or at least “part complete”) rather than “something happened during the cycle.”

Required scenario: part-count spikes without corresponding cycle time. A classic failure mode is tying the counter to a subprogram loop (or a pallet count) rather than completed parts. The chart shows part-count increments rapidly while cycle time doesn’t distribute the way it should. A manager might incorrectly conclude throughput is strong and WIP should be flowing, then wonder why downstream inspection or shipping is empty. What’s actually happening is the counter is registering loop iterations, pallet moves, roughing passes, or “attempts,” not finished pieces. For the question “How many parts did we complete?” part-count must be primary only after it’s validated; cycle/spindle timelines are the cross-check that tells you whether count logic matches physical output.

A practical validation method doesn’t require deep analytics. Cross-check count increments against (1) the expected cycle time distribution (are increments spaced like the process?), and (2) shift change patterns (do counts jump during handoff or pallet swaps in a way that doesn’t match completed parts?). If the part-count doesn’t “behave” like the process, don’t use it to drive schedule promises.

Decision framework: which signal should be primary for each question?

The fastest way to stop signal arguments is to standardize a signal hierarchy: pick one primary signal per operational question, then use the others as supporting evidence. That prevents “metric shopping” and speeds up daily decisions—especially in multi-shift environments where the ERP view and the floor reality diverge.

Signal hierarchy (practical default)

• Producing now / in-process time: Cycle as primary; spindle as corroboration; power only as “is it even available?” when cycle isn’t available.

• Micro-stops and inefficiency inside the program: Spindle transitions inside cycle windows as primary; cycle as context.

• Fault response: Alarm as primary for triage; pair with cycle/spindle to see what was happening before the stop.

• Throughput / completed parts: Part-count as primary only after validation; cycle-time distribution as the sanity check.

• Availability / off-shift behavior: Power as primary; do not confuse this with utilization.

Now tie that hierarchy to common shop questions:

• “Are we producing right now?” Prioritize cycle. Corroborate with spindle (is it cutting or repeatedly pausing?). Ignore power unless cycle is unavailable or suspect.

• “Where are micro-stops killing us?” Prioritize spindle changes within cycle windows. If cycle stays on but spindle drops frequently, you’ve found stop-and-go behavior that won’t show up in a simple “run/stop” report.

• “Why did the cell miss schedule?” Combine cycle gaps (non-run time) with validated part-count and lightweight context notes. Don’t rely on alarms alone; the biggest losses are often non-alarm waiting and process holds.

• “Can we take on more work without adding machines?” Avoid power-based utilization. Use cycle-based run vs non-run, then identify leakage buckets (waiting on approval, material, staffing gaps, long tool changes, optional stops). This is how you recover capacity before capital expenditure.

When signals disagree: a quick troubleshooting checklist

• If power=on but cycle=off for long stretches, assume waiting/setup/hold until proven otherwise; “no alarm” doesn’t clear it.

• If cycle=on but spindle=off frequently, suspect optional stops, feed holds, inspection prompts, or tool-change/measurement patterns inside the job.

• If part-count increases without “process-shaped” timing, audit the counting event; don’t use it for throughput or WIP assumptions yet.

• If shift comparisons look “backwards,” verify all shifts are being judged on the same primary signal; power and warm-up can make one shift look artificially strong.

If you’re implementing monitoring across a mixed fleet, plan for signal integrity work: different controls expose different states, and the same label (like “cycle”) can be derived differently depending on integration. Treat rollout as instrumentation calibration, not a one-time IT task. Cost-wise, focus on what you need to trust first (cycle/spindle/part-count mapping and stop visibility) and what can be phased; details belong in the vendor’s pricing and implementation discussion rather than a generic checklist.

Finally, don’t underestimate interpretation speed. Even with good signals, teams get stuck translating timelines into actions. An assistant that turns “cycle off + no alarm + long idle” into plain-language hypotheses can reduce back-and-forth—especially across shifts. That’s the practical role of an AI Production Assistant: not replacing judgment, but shortening the time from conflicting signals to a focused question on the floor.

If you’re evaluating monitoring because your ERP numbers don’t match actual machine behavior, a good next step is a diagnostic demo: pick 2–4 pacer machines (modern and legacy), look at one week across shifts, and pressure-test which signals you can trust for utilization, stop patterns, and part completion. You’ll know quickly whether the data will accelerate decisions—or create new arguments. schedule a demo.