Machine data when the PLC is twenty years old

Start with the decision, not the tag list

The first question is not which protocol the controller speaks. It is: what would you do differently tomorrow morning if you had the number? If the honest answer is “put it on a screen,” the project will be finished, technically successful, and quietly abandoned within a quarter. We have watched that outcome more than once, and it is never a technology failure. It is a failure to name a decision before building the thing that was supposed to inform it.

Good answers sound like this. We change over between four and seven times a shift and nobody agrees how long a changeover takes, so we cannot tell whether the new fixture helped. We are quoting a new part and our cycle time estimate comes from a spreadsheet built in 2011. Line three misses its number about one week in three and the supervisors blame different things. Each of those names a decision, an argument, or a piece of money. Each one also tells you exactly which signals matter, which is why the decision comes first and the tag list comes second.

What “twenty years old” actually means

Age is not the obstacle people expect. A controller from the early 2000s is a deterministic, extremely reliable computer that does one job well and has probably run for a decade without a reboot. What it lacks is the assumption that anyone will ever want to read from it over a network.

In practice you will meet some combination of the following. A serial port speaking a vendor protocol over RS-232 or RS-485. Modbus RTU, which is old, simple, and completely adequate. A discrete I/O rack where the only outward sign of a state is a relay contact. An add-on Ethernet card someone installed in 2009 that speaks an early industrial Ethernet dialect. An HMI running on a Windows PC of similar vintage, holding a vendor runtime whose license key is in a drawer, if it is anywhere. And, quite often, a working historian nobody mentions because the person who set it up left and the reports stopped being read.

The important consequence is that on old equipment there is usually no such thing as a self-describing tag. A modern controller hands you named tags with data types. An older one hands you an address — a data file and an element number, or a register offset — and the meaning of that address exists only in the program listing and in the memory of whoever wrote it.

Five routes to the data, cheapest first

These are ordered roughly by cost and by how much they disturb a running machine. Most plants end up using three of them at once, because a mixed floor demands a mixed approach and pretending otherwise is how projects overrun.

Route	What it is	When it is right	What it costs you
1. Read what already exists	HMI logs, historian tables, gauge output files, CMMS work orders, ERP transactions, the quality system	Almost always the first thing to check, and it is skipped almost every time	Days of investigation, no hardware, no risk to the machine
2. Poll the controller directly	Modbus RTU or TCP, the controller's native Ethernet protocol, or an existing OPC server	Controller is reachable, addresses are documented or derivable, controls engineer is available	Small; a converter and a workstation. Requires care about scan time
3. Protocol gateway at the machine	An edge device speaking the old protocol on one side and MQTT or OPC UA on the other	Many machines, several protocols, and you want one shape of data upstream	Hardware per machine or per cell, plus a network drop and configuration
4. Instrument the physics, not the controller	Current transducer on the drive, vibration sensor, photo eye, proximity switch, energy meter	Controller is closed, unsupported, or the OEM contract forbids connection	Sensors plus a cabinet and an electrician. Nothing touches the control program
5. Ask the operator	A ruggedized tablet at the station with a small number of large buttons	Reason codes, changeover start and stop, anything requiring judgment	The hardest one to sustain, and often the only source for why

Route four deserves more credit than it gets. A current transducer clamped around the motor lead of a machine tool tells you, with no connection to the controller at all, when the spindle is cutting, when it is idling, and when it is off. That is availability and a decent proxy for cycle count on a repetitive part, obtained without a single change to a machine the OEM would rather you left alone. It is not elegant. It is frequently the fastest path to a number people will argue about productively.

Route five is treated as a defeat, and it should not be. No sensor on earth knows that the line stopped because material did not arrive from the previous cell. That fact lives in a human being's head for about ninety seconds. If you do not capture it in that window, it is gone, and your downtime report will be a long list of stops with no explanations attached to them.

The read-only rule

Data collection reads. It never writes to a control program, never changes a setpoint, never issues a command. There are three reasons and each is sufficient on its own.

The first is safety. A control program is part of a machine that moves and can hurt somebody. Modifications belong to the controls engineer, under the plant's change control, with the risk assessment that goes with it.

The second is contractual: many OEM support agreements are void the moment a third party writes to the controller. Reading is usually permitted; writing usually is not. The third is practical. If the data system can write, every future line stoppage will be blamed on it, and you will spend two years proving a negative.

Scan time, and how to break a machine by being polite

A controller executes its program on a cycle. Depending on the processor and program size, that cycle is somewhere in the low single-digit to high tens of milliseconds. Communications are serviced within that budget. Polling a controller aggressively — especially an older one, especially over a serial link — can extend the scan and, in the worst case, disturb the timing the machine depends on.

The discipline is simple: match the poll rate to the physics. A press making forty strokes a minute does not need a ten millisecond poll; it needs to not miss a stroke, which a poll every few hundred milliseconds handles comfortably, and which a counter read once a second handles even better because the counter itself does the work. Temperature moves slowly. A running/stopped bit changes a handful of times an hour. Reserve fast polling for the two or three signals where a fast edge genuinely matters, and read everything else at a rate a person would consider unhurried.

Prefer counters and accumulators inside the controller over sampling. If the controller already increments a part count, read the count and take differences. Sampling a done-bit and hoping you catch every pulse is how you produce a part count that is quietly three percent low, which is worse than having no part count, because someone will build a report on it.

The single artifact that decides the project: the signal dictionary

Here is the failure we see most often. A plant stands up collection on six machines, streams four hundred tags into a time-series database, builds dashboards, and six months later cannot answer whether tag N7:23 on machine four is a good-part count or a total-stroke count, whether it resets at shift change, and whether the value is in tenths.

The fix is unglamorous and is the highest-value deliverable of the entire effort. For every signal you collect, one row: the address, the machine, a plain-English description of what it physically means, the engineering unit and scaling factor, the sampling or polling rate, the expected range, the reset behavior, whether it rolls over and at what value, the person who confirmed the meaning, and the date they confirmed it. That last pair matters more than it looks. A signal meaning is a claim by a human being, and claims should be attributable.

Build the dictionary as you go, not afterward. Confirming what a tag means is a five-minute conversation while the controls engineer is standing at the panel with the program open. It becomes a two-day archaeology exercise once the laptop is packed up. If a project has to choose between one more machine connected and the dictionary for the machines already connected, take the dictionary. Connected machines with unknown signals are not an asset.

Three quiet data problems that will cost you a month

Clocks disagree. There are at least three in play: the controller's, the edge device's, and the server's. Controller clocks drift and are frequently set wrong, sometimes by hours, sometimes by a year. Do not use the controller clock as the authority for anything you intend to compare across machines. Timestamp at the edge, against a synchronized clock, and record the controller's own view as a separate field so you can spot drift instead of being confused by it. Also decide, early and in writing, what a shift boundary means for a plant that runs across midnight and changes with daylight saving.

Counters roll over and reset. Sixteen-bit registers wrap. A counter that hits 32,767 and turns negative will produce a spectacular part count if your difference logic is naive. Counters also reset on shift change, on a mode switch, and sometimes when an operator holds a button for reasons nobody documented. Store the raw reading, compute the derived quantity downstream, and keep both. Then a rollover is a five-minute fix instead of a rebuild.

Counting is ambiguous. Strokes, cycles, parts, good parts, and shipped parts are five different numbers, and on a multi-cavity mold or a multi-out die they differ by a factor. Reject handling, jam recovery, and test cycles at start-up all inflate a raw count. Pick the definition, write it into the dictionary, and validate it by standing at the machine for an hour with a tally counter. That hour is the cheapest validation available and it is skipped constantly.

Downtime is a policy question wearing a technical costume

Nothing in this work generates more argument than downtime, and the argument is never about sensors. It is about definitions, and definitions are decisions the plant has to make before any number is published.

How long does a stop have to last before it is a stop? Below some threshold you have micro-stops, which are real losses but which will swamp a report if each one appears as a line item. Is a changeover downtime, or is it planned and excluded? Is a break downtime? Is a machine idle for lack of orders the same category as a machine idle for a broken sensor? Is planned preventive work an availability loss or is it outside the measured window entirely?

None of those has a universally right answer. All of them have a right answer for your plant, and the only wrong move is leaving them implicit, because then finance, operations and maintenance will each compute a different availability number and the meetings will be about arithmetic rather than about machines. Write the definitions on one page. Have the plant manager sign it. Put the page in the same repository as the code.

The same caution applies to OEE. Availability times performance times quality is a fine composite, and it is only as honest as the ideal cycle time in the denominator of the performance term. In most plants that number came from a quotation, was optimistic when written, and has not been revisited since the tooling changed. An OEE built on a fictional ideal is a number that goes up when you re-baseline and down when someone is honest, which teaches the organization that the metric is political. If you cannot defend the ideal cycle time, publish availability and quality, publish the actual cycle time distribution, and leave the composite alone until the standard is rebuilt.

The network, briefly and seriously

Plant control networks and business networks are separated for good reasons, and a data project is a common way for that separation to quietly erode. The pattern that holds up is one direction: the collection service sits on the control network side, reads from equipment, and pushes outward through a controlled path to the business side. Nothing on the business side initiates a connection inward. No inbound remote access to the control network is created for convenience. If a vendor needs remote support, that is a separate, brokered, logged arrangement, not a side effect of a monitoring rollout.

What it costs, in ranges

We will not pretend to a precision nobody has. The hardware is the small number. An industrial edge gateway or protocol converter is typically in the low hundreds to low thousands of dollars per machine or cell. Add-on sensing for route four — a current transducer, a photo eye, an enclosure, and an electrician for an afternoon — lands in a similar band per machine, sometimes lower. A tablet and mount for the operator interface is a consumer-scale expense.

The engineering is where the money and the calendar go, and it is dominated by discovery rather than by code. For a first line, four to eight weeks from kickoff to a number the plant will defend is a realistic range, assuming a controls engineer is available a few hours a week. Additional lines of the same type are much faster; a different line type restarts discovery, which is why plant-wide estimates built from the first line run low.

Where you do not need an outside firm

If your equipment is recent and the OEM sells a data package for it, buy theirs. It will be cheaper than any integration and it will survive their firmware updates, which a custom driver may not.

If the only question is how many parts were made, and the ERP already carries a production reporting transaction, the answer is already in your database. The work is a query and a definition, not a sensor.

If the plant has not agreed on what downtime means, no vendor can fix that. It is an internal decision, it takes one meeting and a written page, and doing it first will save you from paying somebody to build a dashboard that gets argued into irrelevance.

The mistakes that repeat

• Piloting on the newest machine — it proves nothing about the equipment that actually needs the work
• Buying a platform before knowing which tags exist, then discovering the licensing is per tag
• Sampling a done-bit instead of reading the controller's own counter
• Letting the collector write, which makes it the suspect in every future stoppage
• No operator input path, so you have precise stop durations and no reasons
• A dashboard with no owner and no standing meeting where it is used

A sequence that works

• Name one decision that a number would change, and one line that matters
• Inventory what is already recorded in the HMI, historian, CMMS and ERP before adding anything
• Write the definitions for stop, micro-stop, changeover, planned and unplanned, and get them signed
• Pick the cheapest route per machine, not one route for the whole plant
• Build the signal dictionary as you connect, with a name and a date on every meaning
• Validate against a human count for one shift before anyone builds a report
• Put the number in an existing meeting that already happens, rather than creating a new one
• Expand only after the first number survives a month of people trying to disagree with it

Bottom line

Old controllers are not the hard part of machine data, and treating them as the hard part is what produces expensive systems nobody uses. The protocols are documented and stable, and where they are impossible you can instrument the physics instead. What is genuinely difficult is naming a decision worth informing, agreeing on what a stop is, recording what a signal means while the person who knows is still standing there, and getting a human being to tell you why the line went down. Do those four things on one line, prove the number survives the people who will be measured by it, then expand. In the other order you will own a large collection of well-timestamped numbers that nobody believes.

Frequently asked questions