Most factories run machines that were built long before anyone said “IoT”. They work, they are paid for, and nobody wants to replace a press that still makes good parts. The question is how to get useful data from them without risking production. The answer is almost always a layered one: find out what the machine already offers, read it carefully, and add sensors only for what is missing.

Find Out What the Machine Already Speaks

Start with documentation and the controller itself. Many older machines already expose data through a serial port or Ethernet interface, even if nobody has used it in years. Look at the controller’s manual for supported communication options. Check the nameplate and electrical drawings for the PLC or drive model, then check the manufacturer’s current documentation for its available interfaces.

Two names come up constantly. Modbus is an old, simple protocol that exposes numbered registers over serial lines or Ethernet; it is easy to read but carries no description of what each register means, so you depend on a register map. OPC UA is a newer, more structured standard that includes naming, data types, and security features, which makes it friendlier for integration but requires a controller or gateway that supports it. Plenty of machines speak neither and use a proprietary protocol, which is where gateways come in.

Three Realistic Retrofit Routes

You generally have three options, in rising order of effort.

The first is reading the controller directly. If it supports a standard protocol, a gateway or edge device polls it and republishes the data in a modern format. This gives you the same values the machine uses internally, such as counters, states, and alarms.

The second is tapping signals. If the controller is closed, you can read existing electrical signals, such as a tower light, a cycle-complete output, or a motor contactor, using a small input module. This is crude but surprisingly effective for run, stop, and fault status.

The third is adding independent sensors: current clamps, vibration sensors, temperature probes, or counters. These ignore the controller entirely and measure the machine from outside.

Route	What you get	Main risk
Read controller via protocol	Rich internal data, alarms, counters	Register maps may be missing or wrong
Tap existing signals	Run, stop, fault, cycle counts	Limited detail, wiring work
Add external sensors	Independent condition data	Mounting, calibration, extra cost

Keep Access Read-Only

This is the most important rule. Early projects should read data, never write to the controller. A misconfigured write to a register can start a motor, change a setpoint, or clear an alarm. Configure the gateway account and protocol permissions so that writes are impossible, and test that restriction. Anything involving control belongs in a separate, deliberate project with safety review.

Also respect the controller’s limited capacity. Older PLCs can slow down if polled too aggressively, which could disturb the very process you are trying to observe. Poll at a modest rate, start slow, and watch for any change in cycle time.

Handle the Register Map Problem

With Modbus especially, the map is the whole game. If the manufacturer supplied one, verify it by comparing values against the machine’s display or against known events. Start the machine, stop it, change a setting, and observe which registers move. Document each register with name, unit, scaling, and data type. A raw value of 750 might mean 75.0 degrees after scaling, and getting that wrong silently ruins every chart downstream.

Keep byte order and data type in mind: multi-register values can be stored in different orders depending on the device, and one wrong assumption produces nonsense numbers. If numbers look implausible, suspect the interpretation before suspecting the machine.

Protect the Network

Connecting old equipment widens your attack surface, because many legacy controllers have no meaningful authentication. Put them behind a gateway or firewall, keep them off the general office network, and allow only the specific connections required. Follow your site’s OT security policy and involve whoever owns it. Requirements vary, and a qualified industrial security professional should review anything that touches production networks.

Example: An Older Packaging Line

Consider a packaging line with a decades-old controller that offers a serial Modbus port. The team requests the register map from the manufacturer, finds it partly out of date, and verifies values by running the line through start, stop, and jam conditions. They install a read-only gateway that polls a few registers every few seconds: run state, product count, and fault code. For motor health, which the controller does not expose, they add a current clamp on the main drive. Within a month the team can see true downtime reasons by shift, instead of relying on handwritten logs. They never touched the control logic.

Decide What Data Is Worth Collecting

More data is not better data. Pick a small set tied to a decision: run state for availability, counts for throughput, fault codes for downtime reasons. Sort out time synchronization so records from different machines line up, and store raw values alongside scaled ones so you can fix scaling errors later.

Plan for maintenance of the integration itself. Gateways need updates, configurations need backups, and someone must own them. A retrofit with no owner decays quietly.

Frequently Asked Questions

Can I always read data from an old PLC? Not always. Some controllers have no usable interface, and in those cases signal tapping or external sensors are the fallback.

Is OPC UA always better than Modbus? It offers more structure and security features, but Modbus is simpler and widely supported. Use what your equipment supports and what your integration needs.

Will polling slow down my machine? It can on older controllers if done too often. Start with low rates and watch cycle times closely.

Do I need the manufacturer’s permission? Check your warranty and service agreements. Some require notification or approval before connecting third-party devices.

Should I write setpoints back to the machine? Not in a first project. Keep read-only until you have a reviewed, safety-assessed reason to do otherwise.

Next Step

Choose one machine and find its controller model and manual this week. Write down which interfaces it offers and which three data points would settle your biggest recurring argument about downtime. That list defines your first retrofit.