Why do you publish pricing when others don’t?

Because it’s explainable and saves time. Most manufacturers want to know early if something is in the right ballpark — we respect that.

Are there contracts or long-term commitments?

No long-term contracts or lock-ins. Pricing is per machine and scales as your operation changes.

Is the AI Production Assistant an add-on?

No. The AI Production Assistant is included — there’s no separate AI tier or upgrade.

Is this a self-serve checkout or order form?

No. Pricing is transparent, but every setup starts with a short walkthrough to confirm fit and configuration.

How Machine Monitoring Systems Detect Downtime Automatically

Matt Ulepic
23 hours ago
9 min read

How machine monitoring systems detect machine downtime automatically

A lot of “downtime data” is really paperwork data: ERP notes, end-of-shift memory, or a supervisor’s best guess. That’s why two reports can contradict each other—and why multi-shift shops often argue about which shift “caused” the problem. Automatic downtime detection corrects the myth that downtime is something people reliably report. In practice, it’s a measurement problem: can you time-stamp when a machine stops producing and when it resumes, based on signals the machine actually emits?

The goal isn’t a prettier dashboard. It’s operational visibility you can audit: a downtime number you can trace back to a specific state change (cycle stopped, alarm asserted, spindle dropped, door opened) so the shop can act in the same shift—before you default to overtime, expediting, or another machine purchase.

TL;DR — how machine monitoring systems detect machine downtime automatically

“Automatic” downtime is captured from controller/electrical signals, not operator memory or end-of-shift edits.
Detection is a state-transition problem: running → idle/stop → running, with time-stamped boundaries.
Controller cycle status + alarm states are typically the strongest indicators of true stoppages.
Minimum-duration thresholds (debounce) prevent 20–40 second micro-gaps from becoming downtime events.
Mixed fleets need multiple signal paths (controller, I/O, power) and transparent rules per machine type.
Good systems separate “machine stopped” from “data stopped” (connection loss) so downtime isn’t inflated.
Accuracy should be validated on a short-cycle and a long-cycle machine across at least one shift change.

Key takeaway Automatic downtime detection is only “trustworthy” when every downtime event can be traced to a specific, time-stamped signal change on the machine—not an operator’s later explanation. In mixed-fleet, multi-shift shops, that auditability is what exposes hidden idle patterns and prevents ERP-reported performance from drifting away from actual machine behavior. Once the stop/start boundaries are credible, you can recover capacity before you spend on new equipment.

Automatic downtime detection: what “automatic” actually means on a CNC floor

On a CNC floor, “automatic” downtime detection means the system is listening to real shop-floor signals—typically from the CNC control, electrical characteristics, or discrete inputs—and deciding, continuously, whether the machine is producing or not. The stop is captured even if nobody logs it, and the restart is captured the moment the machine returns to a producing state.

Most systems do this by tracking machine-state transitions: running (in cycle / producing) → idle or stopped (not producing) → running again. Those transitions are time-stamped so you can see the true duration of the stop. That’s fundamentally different from manual downtime reporting, which usually captures only a reason code (if anything) and often misses the real boundaries—especially when operators backfill at lunch or the end of the shift.

In a multi-shift shop, the value is consistency. A day-shift lead might be diligent about logging stops; nights might focus on keeping parts moving and skip entries; weekends might run lean. Automatic detection normalizes measurement across those habits so you can compare shifts without arguing over whose paperwork is better.

The practical goal is straightforward: identify “not producing when it could be” fast enough that a supervisor, lead, or owner can respond the same shift—clearing a chip jam, escalating a tooling issue, adjusting scheduling—before lost time becomes lost shipments. This is the measurement foundation behind a broader machine downtime tracking program.

Where the monitoring system gets its truth: common signal sources

Automatic detection lives or dies by signal quality. In mixed fleets—different control brands, different vintages, milling and turning side by side—systems typically combine multiple sources to infer state reliably.

1) CNC controller status (cycle/run/hold)

The strongest signals usually come from the control: “in cycle,” “program running,” “feed hold,” “cycle start,” or similar status bits. These can be obtained via MTConnect, OPC UA, or controller-specific APIs, depending on the machine. The key is that these are explicit statements from the CNC about whether it believes it is executing a program—often the cleanest way to separate producing from not producing.

2) Alarm and message states

Alarm states (faults, interlocks, hard stops) are strong downtime indicators because they usually mean the machine cannot proceed without intervention. Even if the operator never enters a reason code, the alarm itself is a traceable “why now” for the stop boundary. Warnings and messages can also be useful, but they’re not always hard blockers—so the detection logic should treat them differently.

3) Discrete I/O (stack lights, doors, part-present)

Discrete inputs add context: stack light colors, door open/closed, chuck clamp state, pallet present, air pressure OK, etc. These signals help validate state decisions and reduce ambiguity. For example, “program paused + door open” may indicate in-process gauging or a part swap; “program paused + alarm active” suggests unplanned downtime.

4) Power/current sensing (fallback for legacy controls)

When controller data isn’t available—common with older machines—systems may infer activity from spindle load, motor current, or overall power draw. This can be effective, but it has pitfalls: warmup cycles can look like production, a spindle running without cutting can be misread as “running,” and short idle pauses may not show up cleanly. Power-based methods work best when paired with practical rules and, where possible, a few discrete signals for confirmation.

5) Time sync and sampling rate

Downtime boundaries are only as good as the timestamps. If devices are not time-synchronized, a stop might appear to start “before” the signal that caused it. Sampling rate matters too: if you only poll every 30–60 seconds, you’ll smear short events and blur the exact start/stop times—creating noise that looks like utilization leakage. A well-implemented setup keeps clocks aligned and samples frequently enough to catch real transitions without generating false micro-events.

How raw signals become downtime events: the state-machine logic

Once signals are collected, most monitoring platforms apply deterministic “state-machine” logic: a clear set of rules that maps combinations of signals into a small number of machine states, then turns state changes into events. This is where “automatic” becomes measurable and auditable.

A typical model looks like this:

Running (producing): the CNC indicates in-cycle/program running, or a validated proxy indicates active cutting/processing.
Idle (ready but not producing): not in cycle; no alarm preventing operation; often a “could run” condition.
Stopped/Down (blocked): alarm/interlock active, E-stop, fault state, or another condition that prevents immediate production.

Event creation is simple in concept: when the system detects a transition into a non-running state, it opens an event and starts timing. When the machine returns to running, it closes the event and records the duration. The difference between a useful system and a noisy one is the handling of edge cases.

Debounce and minimum-duration thresholds prevent false downtime from micro-stops. Without thresholds, a short-cycle mill with frequent tool changes and part swaps would generate a flood of “downtime” events that are really normal process steps. Systems typically require the machine to remain non-running for a configurable minimum duration before labeling it downtime.

Connection-loss handling is another make-or-break detail. If the data stream goes quiet, the system should not automatically assume the machine is down. Good logic distinguishes “machine stopped” from “data stopped,” so a network hiccup doesn’t inflate downtime and trigger the wrong conversation.

Finally, auditability matters: the system should store the contributing signals at the moment of transition (for example: cycle status flipped to not-in-cycle, alarm code asserted, feed hold on). That makes the record defensible when a lead asks, “Why did it call this downtime?” This is a core expectation when evaluating machine monitoring systems in a real job shop environment.

The hard part: separating true downtime from normal non-cutting time

In CNC job shops, “not cutting” is common—and not all of it is a problem. If automatic detection treats every non-cutting moment as downtime, you’ll chase the wrong issues and lose confidence in the numbers. If it’s too permissive, you’ll miss utilization leakage that quietly eats capacity.

Common non-cutting cases that require careful handling include tool changes, pallet swaps, probing, washdown, and warmup cycles. These can be normal parts of the process, but their durations vary by part, setup, and operator method. A single fixed threshold across the whole shop often fails because job shops have huge cycle-time variance: short-cycle milling alongside long-cycle turning, and repeat jobs alongside new work.

A practical approach is to separate what can be inferred automatically from what needs later classification:

Often inferable: alarm-driven stops (fault active), E-stop states, cycle not running with clear block conditions.
Often ambiguous without context: door open + feed hold, program stop without alarm, extended “idle” between cycles.

This is where discrete I/O helps. For an optional add-on scenario: door-open plus feed hold during in-process gauging may be planned check time rather than unplanned stoppage. Without a reason code, a system may conservatively flag it as “idle” (not producing but not clearly down) until someone later classifies it. That “idle” state is still valuable: it highlights where time is being spent, even before you’ve standardized reason codes, and it often reveals shift-to-shift differences in how long checks, part swaps, or waiting periods actually take.

When your shop’s ERP shows “machine complete” but the machine spends long stretches idle between cycles, the gap isn’t theoretical—it’s recoverable capacity. That’s why many teams connect downtime detection directly to machine utilization tracking software efforts: you can’t recover time you can’t see, and you can’t trust what you can’t audit.

Scenario walkthroughs: what the system sees, and what it records

Below are two annotated, mixed-fleet scenarios that show how signals become a downtime record. The point is not the exact signal names (they vary by control), but the logic: signals change → state changes → an event opens/closes with traceable evidence.

Scenario 1: Short-cycle vertical mill with frequent micro-gaps

You have a vertical mill running short-cycle work. Between cycles, there are repeated 20–40 second gaps for part swaps and quick tool-related actions. If you label every gap as downtime, your report becomes unusable. A system typically applies a minimum-duration threshold so those micro-gaps remain “idle” (or are ignored as transitions) while a true stop is captured.

Assumption for this example (hypothetical): the shop configures a minimum-duration threshold in the 2–5 minute range for “downtime event creation” on this machine type.

Timestamp

Key signal changes observed

Inferred state

Downtime record