Machine data collection methods run on a spectrum: manual paper logs, spreadsheets, operator entry on tablets, retrofit sensors, direct controller integration, and machine vision. Most plants need a mix. Machines report the what automatically; people supply the why; the value comes from landing both in one system.
Every plant collects machine data somehow, even if the method is a clipboard and a whiteboard. The question is not whether to collect, it is which method fits each machine and each signal, and how to combine methods without building three disconnected piles of data. This post lays out the whole spectrum honestly, including where manual collection still wins, and what each step up the ladder buys you.
What are the main machine data collection methods?
Six, in rough order of automation. Paper logs: operators write counts, downtime, and notes on forms. Spreadsheets: the same data typed in later, or logged directly at a shared terminal. Operator entry on tablets: digital forms at the machine, timestamped and structured at the source. Retrofit sensors: current clamps, photoeyes, stack light sensors, and vibration sensors reading the machine from the outside. Direct controller integration: tags read from the PLC or CNC over protocols like OPC UA, EtherNet/IP, or Modbus, with MTConnect as the common open standard on machine tools. Machine vision: cameras counting, inspecting, or reading displays where no other signal exists.
No plant should run entirely on either end of the spectrum. All-paper floors lose the short stops and pay a full shift of latency on every number. All-automatic floors capture beautifully precise data with no idea why anything happened. The plants that get value run a deliberate mix per machine, which is what the rest of this post is about.
Where does manual data collection still win?
Wherever the data is a judgment, a reason, or an observation. No sensor knows the line stopped because the incoming cartons were warped, or that the operator nursed a worn bearing through the shift by slowing the feed. Reason codes, quality observations, and shift notes are human data, and plants that automate everything else and drop this layer end up with precise records of stoppages nobody can explain.
What manual collection should never do anymore is carry the numbers. Counts logged by hand at shift end are reconstructions, not measurements; studies of self-reported logging aside, any supervisor who has compared a clipboard tally to a photoeye count knows the two disagree, and the clipboard flatters. Short stops in particular vanish from hand logs, which is why hand-logged OEE runs optimistic. Keep humans on context, move numbers to machines, and make the human entry fast: a tablet at the machine with two-tap reason codes beats a form filled out at shift end from memory, every time. That shift from paper forms to structured digital entry is its own project, covered in the paperless factory.
How do the methods compare?
The trade-offs are stable enough to put in a table. Cost figures are rough hardware-and-setup ranges per machine, not quotes, and latency means the delay between the event and the data being usable.
| Method | Typical latency | Number accuracy | Context captured | Rough cost per machine |
|---|---|---|---|---|
| Paper logs | Hours to a shift | Low, misses short stops | High, if anyone reads it | Near zero, plus retyping labor |
| Spreadsheets | Hours | Low to medium | Medium | Near zero, plus retyping labor |
| Operator tablets | Minutes | Medium | High, structured | Low hundreds |
| Retrofit sensors | Seconds | High for state and counts | None | Hundreds to low thousands |
| Controller integration | Sub-second to seconds | Highest, machine-internal | None | Low, if a port exists |
| Machine vision | Seconds | High when maintained | None | Hundreds to thousands, plus upkeep |
Read the table by columns and the strategy writes itself: nothing in the top rows can carry the numbers, and nothing in the bottom rows can carry the context. That is why the mix is not a compromise; it is the design.
What do automatic methods actually capture?
Three families, each with a distinct sweet spot.
Retrofit sensors read machines from the outside: run state from a current clamp, faults from the stack light, counts from a photoeye, health from vibration. They work on any machine regardless of age, install without touching controls, and cost hundreds rather than thousands per machine. Their limit is depth: they see the machine's behavior, not its internals. The full playbook is in how to connect legacy machines.
Direct controller integration reads what the machine already knows: exact counts, fault codes, recipe parameters, temperatures, speeds. Modern controllers expose this over OPC UA or native Ethernet protocols; machine tools commonly speak MTConnect, an open, royalty-free standard for machine tool data. Integration is the richest feed and the right default for connected controllers, with the plumbing covered in connecting PLC data to the cloud.
Machine vision covers the gaps: counting product on an open conveyor, reading a legacy seven-segment display, checking presence and orientation. Cameras have become cheap and the software has become good, but vision is still the method you choose when nothing simpler works, because lighting, lens fouling, and product changes all need ongoing care.
How do you choose a method for each machine?
Ask four questions in order. First, what question is this data answering? Downtime tracking needs state and reasons; quality tracing needs process values; scheduling needs counts and cycle times. The question determines the signal, and the signal narrows the method. Second, what does the machine already offer? A controller with an Ethernet port makes integration cheap; no controller pushes you to retrofit. Third, how fresh does the data need to be? Anything feeding live decisions, like machine monitoring or an andon response, must be automatic; monthly analyses tolerate slower paths. Fourth, who touches the data and where? If an operator must add context anyway, put a tablet at the machine and let one entry serve both the record and the reason.
A practical rollout, tying the answers together:
- List the decisions the data should feed. Downtime response, OEE review, scheduling, quality tracing. No decision, no signal.
- Map each machine's cheapest adequate method. Integration where a port exists, retrofit where it does not, vision only where nothing else reaches.
- Automate the numbers first. Counts and state across the floor beat deep integration on one showcase machine.
- Move human entry to the machine, on tablets, with structured codes. Two taps, not two paragraphs, and never at shift end from memory.
- Land everything in one system with shared timestamps. Machine events and human entries must interleave on one timeline or the why never matches the what.
- Review the feed monthly and prune. Signals nobody used in ninety days are cost, not capability.
Why does everything need to land in one system?
Because the questions that matter span the methods. "Why did line 2 miss plan Tuesday?" needs machine counts, downtime events, operator reasons, and the production schedule in one place. If the counts live in a historian, the reasons on paper, and the plan in a spreadsheet, the answer costs an afternoon of cross-referencing, so it gets asked rarely and answered roughly. The plants that escaped this trap did not buy better clipboards; they merged the streams, which is the argument developed further in manufacturing data silos.
Merged data is also what makes honest metrics possible. OEE calculation from automatic counts and timestamps, with operator reason codes on the losses, is a number you can act on. The same inputs feed daily production reporting without anyone retyping anything, which is usually the first visible payoff a crew notices.
Where does Harmony AI fit?
Harmony AI's approach is the merged spectrum. It connects machines across every method described here, integration on the connected controllers, retrofit sensing on the legacy iron, and puts fast structured operator entry on tablets at the machine, all landing in one operational layer with shared timestamps. Machines, software, and paperwork in one system is the design, not an integration afterthought, and it works on mixed-vintage floors without replacing anything. Harmony AI deploys in person, so the method-per-machine mapping above is done on your floor by Harmony AI engineers, not left as an exercise. The CLS case study shows what the end state looks like on a real plant, and the ROI calculators will estimate what shift-end reconstruction is costing you today.
What do the standards say?
The automatic end of the spectrum runs on open standards, which is what keeps a mixed-method stack coherent:
- OPC UA (IEC 62541, OPC Foundation) is the vendor-neutral standard for reading structured data from modern controllers.
- MTConnect, from the MTConnect Institute, is the open, royalty-free standard for machine tool data, widely supported on CNC equipment.
- Modbus, open since 2004 under the Modbus Organization and dating to 1979, remains the fallback read path on older controllers.
- MQTT (OASIS standard, ISO/IEC 20922) with Eclipse Sparkplug (ISO/IEC 20237) is the common transport that lets sensor data, controller data, and operator entries share one infrastructure.
Standards keep the methods composable. The judgment call, which method on which machine feeding which decision, is the part that has to be made on your floor.