How to track machine downtime without changing your machines
Fit a sensor outside each machine that reads a signal the machine already gives, such as a stack light or the current it draws. The sensor records when the machine runs and when it stops, with no wiring inside. Your downtime data then builds itself, instead of depending on a register.
By Lalit FauzdarPublished: Last updated:
Why do downtime registers undercount?
A register depends on a person noticing a stop, remembering it and writing it down. Short stops and busy hours get lost first.
- Operators are running the machine, so the register is filled at the end of the shift from memory.
- Stops under a few minutes feel too small to write, but they repeat all day.
- Times get rounded. A 23 minute stop becomes "half an hour" or "about 20 minutes".
- The reason written is often the easiest one, not the real one.
The result is a register that looks complete and still misses a large part of the lost time. The fix is to take the timing away from memory and give it to the machine.
How can you track downtime without opening the machine?
You read what the machine already shows on the outside. A sensor picks up a signal, a small device turns it into machine state, and the state goes to a dashboard.
Two signals cover most floors. The first is the stack light, the tower of coloured lamps on top of many machines. The second is a current clamp, a ring that sits around a power cable and senses how much current flows. A machine that is cutting draws more current than one that is switched on and waiting.
LiveMach uses its own ESP32 based device with sensors fitted outside the machine. Nothing is cut or rewired inside, and the device is electrically isolated from the machine. If the internet drops, the device keeps logging and syncs by itself afterwards.
The product page explains the hardware and the dashboard in full. Machine downtime tracking
What machine states should you track?
Four states are enough to start: running, stopped, idle and off. Every minute of a shift falls into one of them.
| State | Plain meaning |
|---|---|
| Running | The machine is doing its job. |
| Stopped | The machine has halted, for a fault or a wait. |
| Idle | Powered on, but not producing. |
| Off | Switched off, for example after the shift. |
Idle is the state people miss most. A machine that is on but waiting for material looks busy from the office, and a register rarely records it.
How do you know why a machine stopped?
A sensor can tell you that a machine stopped and for how long. It cannot tell you why. The reason has to come from the person at the machine.
LiveMach has an optional downtime reasons module for this. It is off by default. When you switch it on, the operator picks a reason for each stoppage from a short list, in a couple of taps.
Keep the list short. Six to ten reasons agreed with your supervisors works better than fifty. Typical groups are breakdown, changeover, waiting for material, waiting for operator, quality check and planned maintenance.
If you leave the module off, you still get the timing of every stop. Many plants find that the timing alone already shows the pattern.
What should you do with downtime data?
Sort the reasons by total lost time and fix the biggest one first. This chart is called a Pareto chart.
- 1Collect a week or two of stops, with reasons if the module is on.
- 2Add up lost minutes for each reason.
- 3Put the biggest reason first and look at how much of the total the top two or three cover.
- 4Pick one cause, name an owner, and agree what will change.
- 5Check the same chart again next week to see if it moved.
Do not start with ten problems. One fixed cause that stays fixed is better than ten that are discussed.
What do you need before you start?
You need a short list of machines, a view of what signal each one gives, and someone who will look at the data every week.
- A list of machines for the pilot. One machine or one line is enough.
- For each machine, whether it has a working stack light, and if not, a power cable that a clamp can go around.
- A rough idea of shifts and planned breaks, so planned and unplanned stops can be separated.
- A supervisor who owns the weekly review.
- Network access for the device: WiFi in range, or we discuss the options at the survey.
What can downtime tracking not tell you?
It shows when and for how long, not the root cause. It also depends on the signal it reads.
- It does not know why a machine stopped unless an operator selects a reason.
- It does not fix the cause. Somebody still has to act on the data.
- A machine with no usable lamp or current signal needs a different sensor, agreed at the pilot.
- Data is only useful if the weekly review actually happens.