Getting Data Out of Old Factory Machines: A Practical Guide to Machine Connectivity

Introduction

Walk through most factories and you will find machines that run perfectly well and report almost nothing. A press that has worked reliably for fifteen years. A CNC machine with a controller that shows alarms on its own screen and nowhere else. A line of injection moulders whose cycle counts are written on a whiteboard at the end of each shift. Downtime reasons are recorded from memory, if at all. Energy use is a single number on the monthly electricity bill.

Meanwhile, the questions management wants answered — why output dropped last Tuesday, which machine fails most, whether predictive maintenance is worth trying — all depend on data those machines are not sharing. The good news is that you rarely need new machines to get it. Industrial machine data integration is the practical work of reading what existing equipment can already tell you, adding simple sensors where it cannot, and moving that data reliably to somewhere useful.

This guide covers what data is worth collecting, how to find out what each machine can provide, the protocols involved explained in plain terms, a typical architecture, how to do it without disturbing production, and how to start small.

Start From the Question, Not the Sensors

It is tempting to try to collect everything. That produces large volumes of data nobody looks at. A better starting point is one or two questions that matter to the business, which then decide what you need to collect.

• "Why are we losing output?" needs machine state (running, idle, stopped, in alarm), cycle or part counts, and a way for operators to record downtime reasons.
• "Which machines fail, and can we see it coming?" needs alarm history and condition signals such as temperature, vibration, motor current or pressure.
• "Where is our energy going?" needs power or current per machine or per line.
• "Why do we get scrap?" needs process parameters (temperatures, pressures, speeds) linked to the batch or part being produced.

For most factories, the first question — understanding downtime and output — gives the quickest return and needs the least data. Machine state plus a part count, captured automatically, is already a large improvement on a whiteboard.

What Can Each Machine Tell You?

Every machine falls into one of three broad situations. Finding out which one applies to each machine on your floor is the first practical task.

Situation	How to recognise it	How to get data	Typical effort
Modern controller with an open interface	Recent PLC or CNC controller; manual mentions OPC UA, MTConnect or an Ethernet data interface	Read directly over the network from the controller	Low
Older controller with an industrial protocol	PLC with a serial or Ethernet port; Modbus or a vendor-specific protocol	An edge gateway reads the controller and translates its data	Moderate — needs the controller's register or tag map
No usable controller data	Relay-based or mechanical machine; controller locked or undocumented	Add retrofit sensors: current clamps, vibration, temperature, part-count sensors	Moderate, but does not touch the machine's control system

Retrofit sensors deserve special mention because they solve more problems than people expect. A current sensor clipped around a machine's power cable can tell you whether it is running, idle or off, and roughly how hard it is working, without any connection to the controller at all. A simple sensor on the output chute can count parts. A vibration sensor on a motor housing gives an early indication of bearing wear. None of these change how the machine operates.

The Protocols, in Plain Terms

Industrial equipment uses its own protocols, and vendor conversations are much easier when you know what they are.

Modbus is one of the oldest and most widely supported industrial protocols, available over serial connections (Modbus RTU) and over Ethernet (Modbus TCP). Data is held in numbered registers, and the protocol itself does not say what each register means — you need the machine's register map from the manufacturer or integrator. It is simple and very common, but has no built-in security, so it should only be used on a protected network.

OPC UA is a modern industrial standard. It is self-describing — a client can browse what data a machine offers and what it is called — and includes security features such as encryption and authentication. Where a machine supports OPC UA, it is usually the cleanest route.

MTConnect is a read-only standard designed for machine tools such as CNC machines. It reports machine state, program, spindle speed, alarms and more in a consistent format across manufacturers.

Vendor protocols — Siemens S7, EtherNet/IP and many others — are common on PLCs. Gateways and software drivers exist for most of them.

MQTT is different in kind: it is not how you read a machine, but a lightweight way of moving data onward once you have it. Gateways commonly read machines using the protocols above and then publish the results over MQTT to the system that stores and uses them.

A Typical Architecture

Most machine connectivity projects end up with the same shape: an edge gateway on the factory network that reads machines locally, and a data platform that stores and uses what the gateway sends.

The edge gateway is a small industrial computer on the factory network. It reads each machine using whichever protocol that machine speaks, stamps every reading with an accurate time, and holds data locally if the connection to the platform drops — so a network outage creates a delay, not a gap. The data platform stores readings as time series under consistent names and units, so "spindle temperature on machine 7" means the same thing in every report. From there, data feeds dashboards, alerts and, where useful, the maintenance management system. This is the translation-layer work described on our Device & Protocol Integration page.

Doing It Without Disturbing Production

The fastest way to lose the factory's trust is to cause a stoppage while "just collecting some data". A few rules prevent that.

• Read only. The data collection system should never write to a machine's controller. Configure gateways and accounts so that writing is impossible, not merely unused.
• Separate the networks. Keep machines on their own network, with the gateway as the only bridge and a firewall that allows only outbound data. Industrial protocols such as Modbus have no built-in security, so machines should never be reachable from the office network or the internet.
• Involve the people who own the machines. Maintenance engineers, the machine builder and, where relevant, the controls integrator should agree what is being connected and how. Some machine warranties restrict changes to controllers; retrofit sensors avoid that issue.
• Work in planned windows. Any physical installation or controller configuration happens during planned maintenance, not mid-shift.
• Do not overload old controllers. Polling an old PLC too often can affect its performance. Start with sensible intervals — every few seconds for state, less often for slow-changing values — and adjust from there.

Start Small, Then Expand

A pilot on a handful of machines, answering one question, teaches more than a plan for the whole factory — and gives you real numbers to justify the next step.

Step three matters more than it looks. Comparing the automatic data with what people on the floor know is how you find mislabelled signals, wrong units and machines that report "running" while actually waiting for material. It is also how operators come to trust the numbers.

What Becomes Possible Once Data Flows

With reliable machine data, several things become straightforward. Overall equipment effectiveness (OEE) — availability multiplied by performance multiplied by quality — can be calculated live instead of estimated at month end. Downtime can be ranked by cause and cost, so improvement effort goes where it matters. Energy use per machine and per part becomes visible. And with enough history, condition signals can be watched for early signs of failure, which is the subject of AI for Operational Anomaly Detection: Finding Problems Before They Cost Money.

That last step is where machine connectivity pays off most, and it is only possible once the data foundations are in place. Our Predictive Maintenance platform monitors over 10,000 devices in this way, with alert thresholds tuned per device — but every deployment like it starts with exactly the groundwork described here.

Conclusion

Old machines are rarely the obstacle to factory data. Most can report their state through their controller, and those that cannot can be fitted with simple sensors that never touch the control system. Start from a specific question, survey what each machine can provide, use an edge gateway that reads but never writes, keep the factory network separate and protected, and agree names, units and time before collecting anything. Begin with a small pilot, check the data against what people on the floor know, and expand from there.

Frequently Asked Questions

Do we need to replace old machines to collect data?

Usually not. Many older machines can be read through their PLC using protocols such as Modbus, and those that cannot can be fitted with retrofit sensors — current clamps, vibration, temperature or part counters — without changing the machine.

Is connecting machines a security risk?

It can be if done carelessly. Keep machines on a separate network, use a gateway as the only connection point, allow only outbound data, never allow writes to controllers, and never expose industrial protocols to the office network or the internet.

What is the difference between Modbus, OPC UA and MQTT?

Modbus is an older, simple protocol for reading registers from controllers. OPC UA is a modern, secure and self-describing industrial standard. MQTT is a lightweight messaging protocol used to send data onward once it has been collected, rather than to read machines directly.

How much data do we need before predictive maintenance is possible?

Enough history to see what normal looks like for each machine, and ideally some recorded failures. Many factories start by using machine data for downtime and OEE, and build towards predictive maintenance as history accumulates.

Will data collection slow down our machines?

Not if it is set up properly. Read-only access, sensible polling intervals and retrofit sensors where controllers are fragile keep the impact on production negligible.

Further Reading

• Device & Protocol Integration
• Predictive Maintenance
• AI for Operational Anomaly Detection: Finding Problems Before They Cost Money
• Data Pipeline Engineering