Every conversation about production monitoring eventually reaches the same objection, usually delivered with a certain finality: our machines are old, they have no interface, there is nothing to connect to. It is stated as a reason the project cannot happen. In practice it is a description of almost every shop floor in the region, and it stopped being a real obstacle some years ago.
The assumption underneath the objection is that measuring a machine requires the machine to report something. That was true once. It is worth understanding why it no longer is, because the alternative that companies reach for instead is considerably more expensive.
What a typical shop floor actually looks like
Walk through a mid-sized production hall and count the machines. You will usually find three distinct generations working side by side.
A few recent machines with a modern controller, an ethernet port, and documented protocols. A larger group from the 2000s with a controller that technically has an interface, undocumented, from a vendor who no longer supports it. And a substantial group older than that, entirely mechanical or with control electronics that were never designed to talk to anything.
The last group is frequently the most productive equipment in the building. It is paid off, it is reliable, and the operators know its habits. Nobody is going to replace it to obtain a data point.
This is the trap. When monitoring is framed as a connectivity problem, the only affordable scope becomes the newest machines.
Which means you end up measuring the equipment you understand best and remaining blind to the equipment where the actual losses are.
Why the usual routes fail
Companies that try to solve this generally attempt one of three approaches. Each fails for a different reason, and it is worth knowing which failure you are heading for.
Connecting to the controller
Where a controller has a documented interface, this is the cleanest technical route. The difficulty is scope. It works on the newest machines and stops there. On older equipment you are dealing with undocumented protocols, vendors who have disappeared, and control cabinets that nobody wants to open on a running machine.
It also creates a dependency. Modifying anything inside a control cabinet raises questions about warranty, safety certification, and who is responsible if the machine behaves oddly a month later.
Installing sensors on each machine
Retrofitting sensors is possible, and specialist integrators do it well. It also means wiring, mounting, power supply, and a commissioning visit per machine. Cost and disruption scale linearly with the number of machines, which is precisely backwards from what you want.
The consequence is that the pilot covers three machines, the numbers look reasonable, and the extension to the remaining thirty never gets budgeted.
Asking operators to record it
The default fallback: a sheet on a clipboard, filled in at the end of a shift. It costs nothing to start, and it produces data with a systematic bias that makes it unusable for the purpose you wanted it for.
Stoppages get recorded in round numbers. Short interruptions vanish entirely, because writing down a four minute stop takes longer than the stop did. Entries get completed retrospectively, from memory, at the end of the shift. And the operator is being asked to document their own idle time, which is a conflict of interest nobody should be placed in.
A shift log shows two stoppages: one of thirty minutes for a tool change, one of fifteen for a material issue. Forty-five minutes of recorded downtime, which sounds manageable.
What the log does not contain is the eleven short interruptions of three to six minutes each: a jam cleared by hand, a wait for the forklift, a quick adjustment, a pause while someone found the right fixture.
Those eleven add up to roughly fifty minutes. More than both recorded stoppages combined, entirely invisible, and unlike the tool change they are mostly removable.
This is the specific reason manual logs mislead rather than merely being incomplete. They systematically capture the large, unavoidable losses and systematically miss the small, avoidable ones. Improvement effort then goes toward the wrong half.
The route most companies do not know about
There is a fourth option, and it works precisely because it ignores the machine’s electronics entirely.
A small wireless device attaches to a moving part of the machine. Not into the control cabinet, not wired into anything, nothing modified. It detects movement, and from that movement it derives cycles: when the machine is running, when it stopped, and for how long.
The insight is that a machine does not need to report that it is working, because a machine that is working is moving. Movement is a signal that every machine produces, regardless of age, manufacturer, or whether it has a controller at all.
| Controller connection | Wireless retrofit device | |
|---|---|---|
| Works on | Machines with a documented interface | Any machine that moves |
| Machine modification | Control cabinet access required | None |
| Installation per machine | Hours, with the machine stopped | Minutes, no stoppage required |
| Warranty impact | Needs to be checked | None |
| Adding a machine later | New project | Another device |
| Data depth | Everything the controller exposes | Run, stop, duration, cycle count |
That last row is the honest trade-off. A controller connection can expose spindle load, temperature, tool wear, and program numbers. A movement-based device cannot, and any vendor claiming otherwise is selling you something.
Whether that is enough depends on your question
This is where most decisions go wrong, in both directions. Companies specify a data depth they will never use, or dismiss a workable solution because it does not deliver data they do not need.
The useful test is to write down the question you actually want answered.
- “Where is this order and when will it be ready?” Movement data answers this fully.
- “How much of the shift did this machine actually run?” Answered fully.
- “How long are the stoppages nobody records, and when do they cluster?” Answered fully, and this is usually the most valuable question on the list.
- “Why did output drop on the night shift?” Answered partly. You will see that it dropped and when. The cause still requires a person.
- “Is the spindle load drifting on this machine?” Not answered. You need a controller connection.
Most companies without any production data are trying to answer the first three. They specify for the fifth, because it appears in every vendor presentation, and the project then costs several times what the actual question was worth.
What changes when the small stoppages become visible
The first report from a machine that has never been measured is usually uncomfortable, and predictably so.
Utilization comes in lower than anyone expected. Not because operators were idle, but because all those short interruptions were real and were happening the entire time, and everyone was estimating around them.
The pattern matters more than the number. A single utilization figure is a topic for an argument. A distribution of stoppages by time of day, by machine, and by duration is something you can act on.
Short stoppages that cluster at shift change point to handover. Ones that cluster on a single machine point to that machine. Ones that cluster after lunch point to something else entirely.
None of these conclusions require deep data. They require consistent data, captured for long enough that patterns separate from noise, on all machines rather than the three that were easiest to connect.
The objection worth taking seriously
There is one objection to production monitoring that deserves a real answer rather than a reassurance: that it will be experienced as surveillance.
That concern is legitimate, and how it plays out depends almost entirely on what happens in the first month. If the first use of the data is a conversation with an individual operator about their numbers, the system is finished. People will find ways to make the data say what they need it to say, and they are usually better at that than management expects.
If the first use is fixing something the data revealed, a recurring jam, a missing fixture, a handover that wastes twenty minutes every day, then it becomes a tool that removes friction from the operator’s own day. That difference is a management decision, not a technical one, and it should be made deliberately before the first device is installed.
A reasonable way to start
Pick the machine you argue about most. Usually there is one that management believes is a bottleneck and production believes is fine, and neither side has evidence.
Measure that one machine for a month. The cost is small enough not to require a business case, and at the end of it the argument is settled by data rather than seniority.
What typically happens next is not a decision to extend, but a request from a supervisor to measure a second machine, because they now want to know something specific about it. That request is the signal that the system is being used rather than tolerated.
This is how DigiPro System MES is normally deployed: device mounted in minutes, no machine modification, one machine or the whole hall, extended when someone asks for it rather than when a rollout plan says so.
How accurate is movement-based measurement?
For run time, stop time, and cycle counting it is reliable, because the underlying signal is unambiguous: the machine is either moving or it is not. Where it requires configuration is defining what counts as a stoppage. A three second pause between cycles is normal operation. A three minute pause is a stoppage. That threshold is set per machine during setup.
Does the device interfere with the machine?
It is not connected to the machine electrically or mechanically beyond being attached to it. Nothing is wired, nothing is modified, and no control signal is intercepted. Removing it returns the machine to exactly its previous state.
What about machines that run unattended overnight?
These are often where the measurement is most valuable, because nobody is present to notice a stoppage. A machine that stops at two in the morning and is discovered at six has lost four hours that no shift log will ever record.
Can this replace our ERP or production planning?
No, and it should not try to. Planning decides what should happen. This measures what did happen. The value comes from comparing the two, which is why the planned times in most ERP systems turn out to be optimistic once real execution data exists to check them against.
How many machines do we need to make it worthwhile?
There is no threshold. The economics work on a single machine if that machine is a bottleneck you cannot currently see into. Starting small is generally better, because it forces the question of what you will actually do with the data before you have committed to a hall-wide rollout.
Which machine do you argue about most?
That is usually the right place to start, and one month of data settles most of those arguments. Tell us what the disagreement is and we will tell you whether measurement would resolve it.