Knowing what one part looks like is harder than it sounds.
The detection ladder from explicit signal to load signature, and the four situations where naive cycle detection produces confident, wrong numbers.
A monitoring system has to know what one part looks like. On a machine that reports a clean cycle-complete signal this is trivial. On a great many real machines it is not, and how a system behaves in those cases is the clearest available test of whether it was built by people who have stood on a shop floor.
This article covers how cycles are inferred when nothing clean is available, and — more usefully — the four situations where naive detection gets it wrong.
Best available method first.
Work down this ladder per machine, not per platform. A monitoring system that applies the last rung everywhere will produce counts that look confident and drift from reality; one that applies the first rung where it exists is simply reading a fact.
A program that produces four components in one machine cycle is common on bar-fed turning, multi-cavity moulding and any fixture holding several blanks. A detector counting cycles reports one part where four exist, and both output and performance are wrong by a factor of four.
The correction is a parts-per-cycle multiplier set per part number, not per machine, because the same machine runs different fixtures. If a system offers only a per-machine setting, it cannot handle a floor with mixed fixtures — which is most floors. Where the multiplier applies, it should be visible on the dashboard, so a supervisor can see that the count is derived rather than counted.
Many legitimate cycles contain pauses: an operator gauging a feature mid-program, a probing routine, a tool waiting for coolant to clear, a controlled dwell for thermal stability. A naive detector treats each pause as the end of one cycle and the start of another, inflating the count and destroying the cycle-time distribution.
The handling is a minimum-cycle threshold and a pause tolerance, both set from that machine's observed behaviour rather than a default. This is one of several reasons a fortnight of data beats a demonstration: the tolerances are learned from what the machine actually does, and a machine with a 45-second cycle and a machine with a 40-minute cycle need entirely different values.
A cycle that starts, stops for chip clearing or a broken tool, and resumes is one part with an interruption, not two cycles. Counted as two, output is inflated and average cycle time collapses; counted as one long cycle with no interruption recorded, availability is overstated and the stop disappears from the Pareto.
The correct treatment records one part, one cycle, and one stop within it — which requires the detector to hold cycle context across an interruption rather than resetting on every state change. If you are evaluating systems, this is a specific and revealing question to ask, because it cannot be answered convincingly by a demonstration on a machine running cleanly.
A machine running in manual or jog mode is doing something, but it is not producing. A dry run with no material loaded looks identical to production from every signal except the part it did not make. Setup cycles, first-off inspection and test pieces all present the same problem.
Two things resolve most of it: mapping the mode selector so manual and setup are distinguishable from auto, and treating the job or route card selection at the machine as the authority on whether output counts against an order. Neither is exotic, and both are frequently skipped because they require agreement rather than software.
Which rung of the ladder is this machine using?
A system that cannot answer per machine is applying one method everywhere, and is wrong somewhere.
How is a multi-part cycle handled?
Per part number, not per machine — otherwise mixed fixtures break the count.
What happens to an interrupted cycle?
One part, one cycle, one stop recorded inside it. Anything else distorts both output and availability.
Tuning over the first fortnight
Thresholds learned from the machine rather than set from defaults. A system that claims to be perfect on day one has not met your machines.