Most plants know their long stops by heart: the gearbox that failed on a Tuesday night, the four-hour changeover, the power dip that tripped the whole line. Far fewer know how many times the case packer stopped for 40 seconds yesterday, because nobody wrote those stops down. Microstops are short stops an operator clears without calling maintenance, and on many lines they are the largest loss nobody measures. OEE, as most plants calculate it, folds them into a vague performance number. You cannot manage them from a manual log. You have to capture machine state automatically, rank the causes and act on them every day.
In my years as a reliability engineer in pulp and paper and building materials, the pattern never changed. The big failures got root-cause meetings. The small ones got a reset button. Together, the small ones made up the capacity we had already paid for but never saw, which some people call the hidden factory.
What counts as a microstop
A microstop is a stop that is too short to become an event. The operator sees a fallen bottle or a mis-fed carton, clears it, presses reset, and the machine runs again. Plants draw the line in different places, often somewhere between 2 and 5 minutes. The exact threshold matters less than applying one consistently across lines and shifts.
Microstops share a few traits:
- They are frequent. Dozens per shift on a busy packaging line is not unusual.
- Operators fix them, not maintenance. No work order exists, so the maintenance system never sees them.
- The cause is often somewhere else. A machine starved by its infeed or blocked by its discharge looks stopped, even though nothing is wrong with it.
- Each restart costs more than the stop. The machine ramps back up, the first products after a restart may be scrap, and the buffer between machines drains.
Where they land in OEE
OEE multiplies availability, performance and quality. Recorded downtime reduces availability. Unrecorded stops do not disappear. The machine still made fewer units than its ideal rate allows over the run time, so the loss shows up in performance. But performance also contains genuine slow running, so short stops and reduced speed are blended into one figure nobody can act on.
It gets worse if the ideal cycle time was set from what the line “normally” does rather than what it was designed to do. Part of the loss is then defined away entirely. A line at 85% performance looks respectable. The missing 15% might be forty microstops a shift.
Why manual logs undercount
Take a hypothetical case packer that stops 40 times in an 8-hour shift, for an average of 45 seconds each. That is 30 minutes per shift, or 6.25% of the shift, before counting the slower running while the machine and its infeed recover. The manual log for that shift might show two entries: a 10-minute jam and a 12-minute film change. The operator was not hiding anything. The log was never designed to see the other 38 events.
Logs undercount for structural reasons, not because people are careless:
- Thresholds. Many reason-code systems only ask for a reason when a stop exceeds a set duration. Everything below it is invisible by design.
- Recall. Logs completed at the end of a shift are written from memory, and memory keeps the dramatic stops and drops the routine ones.
- Rounding. A 40-second stop does not feel worth a line on the sheet, so it rounds to zero.
- Priorities. The operator’s job is to get the machine running. Writing it down comes second, and in a busy hour it does not come at all.
- Catch-all codes. When a reason is mandatory, “minor stop” or “other” absorbs everything. That is accurate and useless.
Capturing machine state automatically
The fix is to stop asking people to record what machines can report. The goal is a time-stamped state for every machine (running, stopped, starved, blocked or in planned downtime) at a resolution of one second or better. There are four common sources, and most lines end up using more than one.
| Source | What it tells you | Good fit | Limits |
|---|---|---|---|
| PLC tags | Run state, fault codes, starved and blocked bits, part counts | Machines with an accessible, documented PLC | Tag maps differ by machine builder; fault codes need translating |
| Motor current signature | Running, idling or off, from the main drive current | Older machines with no PLC, or a PLC you cannot touch | Shows that it stopped, not why |
| Stack-light sensing | The machine’s own view of its state: green, amber, red | Mixed fleets where every machine already has a light | Only as good as the way the light is programmed |
| Vision counts | Parts actually passing, gaps and pile-ups | Conveyors and discharge points; checking the real rate | Needs a clear line of sight and stable lighting |
PLC tags first, where you can get them
If the machine has a PLC, read the run state, fault words and part counters over OPC UA, EtherNet/IP or Modbus TCP. If the machine builder implemented PackML states, much of the mapping is already done. Read-only access is enough; nothing needs to write to the controller. The real work is the tag map: which bit means running, which fault code means “infeed jam”, and which counter holds good parts rather than attempts.
Current and lights where you can’t
For machines whose PLC is locked, undocumented or missing, a clamp-on current sensor on the main drive tells running from idling from off, using thresholds on the current draw. Watching the stack light tells you what the machine believes its own state is. Neither explains why the machine stopped, but both give honest start and stop timestamps, which is exactly what the manual log was missing.
Vision to see the material
A camera at the discharge counts what actually comes out. It catches slow running that state signals miss. A short clip buffered around each stop shows the jam itself, which often answers “why” faster than a fault code does.
A Pareto that means something
Once state is captured, every stop has a start, an end and a machine. The reasons come from three places: PLC fault codes, a one-tap prompt on an operator screen for stops above a set duration, and image clips. Keep the reason list short. Fifteen codes that people use beat sixty that they don’t.
Then rank, twice: by count and by total minutes. The two orders tell different stories. Here is a hypothetical week on a bottling line:
| Stop reason | Stops per week | Total minutes | Average duration |
|---|---|---|---|
| Labeler: label misfeed | 310 | 207 | 40 s |
| Infeed: bottle down | 240 | 120 | 30 s |
| Capper: cap chute jam | 95 | 143 | 90 s |
| Filler: blocked by packer | 60 | 180 | 3 min |
| Packer: film splice | 12 | 96 | 8 min |
The label misfeed is the largest loss by both measures, yet it would never appear in a log with a 2-minute threshold. Bottle-down stops are second by count but fourth by minutes, so they matter more for operator workload than for output. The filler’s “blocked” stops are not filler problems at all; they point downstream at the packer. Starved and blocked states are how you find the real constraint instead of blaming whichever machine happened to stop.
Keeping OEE honest
Once OEE is measured automatically, it becomes visible, and anything visible gets managed, sometimes in the wrong direction. These are the common ways the number improves without the line improving:
- Lowering the ideal rate so that performance looks higher.
- Reclassifying unplanned stops as planned, for example a “cleaning” break that is really a jam.
- Excluding startup or changeovers from run time.
- Raising the microstop threshold until the problem falls out of the report.
- Comparing OEE between lines that make different products, then using it as a target.
A few guardrails keep the measurement honest:
- Fix the ideal rate at nameplate or a validated best demonstrated rate, and change it only through a documented review.
- Report lost minutes and lost units next to the percentage. Minutes are harder to argue with.
- Use OEE to compare a line with itself over time, not lines with each other.
- Tie recognition to countermeasures completed and verified, not to the OEE figure itself.
Turning data into daily action
Stop data that nobody acts on is just a better-looking log. A daily rhythm that works on most lines:
- Start of shift. Review yesterday’s top three stop reasons per line, ranked by minutes. Ten minutes, standing up.
- One owner per reason. An operator, a technician or the line lead, with a date for the countermeasure.
- Short-interval checks. A line-side display shows stops so far this shift, so a recurring jam gets attention at 9 a.m. rather than at the end-of-week meeting.
- Repeat faults become work orders. If the same fault code fires more than an agreed number of times in a shift, a maintenance work order is raised automatically.
- Verify the fix. Compare the two weeks before and after each countermeasure. If the minutes did not move, the countermeasure did not work.
The fixes themselves are usually unglamorous: a worn guide rail, label stock with the wrong curl, a photo-eye dirty enough to see ghosts, or an accumulation table too short to absorb a two-second hiccup downstream. None of them needs a capital request. All of them need someone to see the pattern first.
Where to start
Pick the line’s constraint machine and instrument it for two weeks without changing anything. Then compare the automatic record with the manual log for the same shifts. The gap between the two usually does more to start a microstop program than any presentation.
Next, put a cost on the minutes. The method in what a minute of downtime really costs, or the downtime cost calculator, turns “6% performance loss” into a dollar figure a plant manager can weigh against a guide rail and a few hours of technician time.
Our Equipment Performance & OEE Tracking service does this capture across mixed fleets, including machines with no PLC, using tags where they exist and current, stack-light or camera signals where they don’t. The Performance module in Perflens Console shows microstops and loss trees by shift, on a server in your plant. The tooling matters less than the habit, though. Measure every stop, rank them honestly, and fix one reason a week. The hidden factory gets smaller one guide rail at a time.