What manufacturing data to collect, and how to collect it

The shop-floor data worth collecting first is four records per machine: when it runs and stops, how many parts it makes, why each stop happened and which parts were scrapped. When you evaluate a data collection system, ask which of those records it captures with no typing, how it reads machines of every age, and how you check and export what it records.

Owners and plant managers deciding where to start get three things here: what sensors, controllers and operators each capture, why paper logs undercount, and a checklist to take into a vendor call.

What manufacturing data collection means#

The machine record sits at the bottom of every other system in the plant. ISA-95, the standard for connecting plant-floor systems to business systems, puts “the collection of data and the manipulation of physical processes” at Level 1, manufacturing execution systems (MES) at Level 3 and the activities of running the business, such as ERP, at Level 4.^[1]

For example, an ERP that reports the cost of a job needs the machine hours that job used. If those hours come from an operator’s estimate at the end of the shift, the job cost inherits the estimate.

Why manual collection falls short#

Most plants already collect data, on paper travelers, whiteboards or a spreadsheet filled in at the end of the shift. Manual records fail in three ways:

• Short stops go unrecorded. Nobody writes down a two-minute jam, and a busy machine has many of them in one shift.
• Times are estimates. A stop logged as “about 20 minutes” at 3 p.m. was written from memory.
• The data arrives late. A sheet read the next morning can’t help the shift that produced it.

Minor stops are short interruptions, often a minute or two long, that operators clear without calling maintenance staff.^[2] Vorne’s rule of thumb is to set the line between a minor stop and a logged stop by your policy for tracking reasons, for example a reason on any stop longer than two minutes.^[2] Anything shorter rarely reaches a paper log.

The missing 28 minutes don’t vanish from your results. The paper log counts them as run time, and in OEE minor stops count as a performance loss, so the machine looks slow instead of stopped and nobody looks for the cause.^[2] What is OEE? explains how the three factors split those losses.

What data is worth collecting#

Each record answers one question, and each has a natural source. Collect the first five on every machine before you add anything else; cycle time comes from the count at no extra cost.

Each role reads the same records at a different level:

• Operators need the count against the shift goal and the stops still waiting for a reason, at the machine.
• Plant managers need the fleet: which machines are down now, and which reasons cost the most hours this week.
• Engineers and maintenance need history: cycle times by part, the step that limits a line, and vibration trends on critical machines.

You don’t need vibration data on every machine. Add it where a breakdown stops a line or a repair costs days, for example on the spindle of the one 5-axis machining center that every job passes through.

Machine data and human context#

A machine record tells you when a machine stopped and for how long. It can’t tell you why. A spindle that sits still for 14 minutes looks the same in the data whether the operator was waiting for material, changing a tool or refilling coolant.

The reason comes from the person at the machine. A downtime category is a reason code an operator puts on a stop, such as Tool change or Waiting for material; the glossary entry lists what each one carries. The best stop record combines all three sources: the time from the sensor, the alarm from the controller where one is connected, and the reason from the operator.

Reasons pay off over weeks, not on the day. Datwyler’s injection molding plant found that “Tuesday shift transitions turned out to add 8 to 10 minutes of downtime, every week”, a pattern that showed up week over week once every stop carried a reason. The Datwyler story shows how three automatic rules classify routine stops and operators classify the rest.

Keep the reason list short enough to fit on one screen. An operator facing a long list picks whatever sits at the top.

Three ways to get data off a machine#

You can read a machine from the outside with a sensor, from the inside through its controller, or by having a person write it down. Most plants combine at least two.

An external sensor reads vibration, sound or a passing part, and decides from that signal whether the machine is running. It works the same on a 1985 manual-load lathe and a new machining center, because it never touches the control.

A controller connection reads what the control already knows, over standards such as MTConnect for CNC machines and OPC UA. OPC UA, released in 2008, includes message encryption, message signing and certificate-based authentication.^[3]

Even so, a connection to a PLC or CNC control is a security concern for many plants, and IT usually reviews it first. Sensor-based vs PLC machine monitoring compares what each method sees, signal by signal.

How often to record#

Record machine state as events, not snapshots. A state change event is a record written the moment a machine starts or stops, with its timestamp.

For example, a system that polls a machine every 15 minutes sees “running” at 10:30 and at 10:45, and misses a 9-minute stop in between. An event log records the stop at 10:34 and the restart at 10:43.

Ask where and how the running-or-stopped decision is made. A device that decides on the machine, every second, against settings fixed at calibration catches the stops a poll misses; how IoTFlows works shows that path for one system. Every metric downstream is built from that stream, so ask how calibration is checked too.

Counts and scrap can then be summed by hour or by shift from the same events. Vibration for machine health is the exception: a vibration spectrum is computed from the raw signal, sampled far faster than any state change.

A buyer’s checklist for a data collection system#

Take these questions into a vendor call. The right column is what a good answer sounds like.

Leave out questions about features the machine record doesn’t need. Payroll rules, supplier scoring and demand forecasting belong to other systems; a data collection system should feed them, not replace them.

Collect machine data automatically#

IoTFlows records state, part counts and stop times with a sensor on each machine, and operators add reasons and scrap. A SenseAi attaches with a magnet, reads vibration and sound from the outside and decides running or stopped every second on the device, with no PLC connection. Part counts and cycle times come from the same signal.

Operators classify a stop in a tap at the machine, in Operator View or in the iOS app, and automatic rules classify routine ones such as short stops and shift starts.

On Enterprise, the IoTFlows edge device brings in PLC, robot and CNC data through custom integrations, and reads only the controls you choose to connect. MiRus runs a two-way Epicor connector that ties every job to the machining and labor hours behind it, and the connector went live in about a month.

Where to start#

1. Pick one area

   Start with the machines that limit output, not the whole plant. The rollout plan walks through a first line, then operator adoption, then reasons.

2. Set shifts before you read any number

   Every figure is bucketed by shift as it arrives, so set the timezone and shifts first.

3. Write a short reason list

   Give operators reasons they can choose in a tap, grouped by how much each costs.

4. Validate the count

   Run ten parts, count them by hand and compare. The production quickstart walks through the check.

5. Review stops every week

   Rank reasons by the hours they cost with a downtime Pareto, fix the top one, and check the next week whether it shrank.