Industrial

Machines Older Than the Web, Reporting Every Fifteen Minutes

Nothing Here Is Broken

A recurring conversation starts with somebody proposing to replace working equipment in order to get data out of it. The flow meter from the nineties still measures to its original accuracy. The machine on the shop floor cost more than the monitoring project and has fifteen years left in it. The switchboard was rebuilt four years ago and nobody is opening it again for a nice-to-have.

The proposal is usually wrong, because most industrial equipment already speaks. It emits a pulse per unit of flow, or answers a Modbus query, or drives a 4-20 mA current loop, or closes a contact when something faults. Those outputs were designed for a local panel or a chart recorder, and they will talk to anything that asks politely. The retrofit is a listening exercise, and it is roughly two orders of magnitude cheaper than replacement.

The one honest caveat is that it is not plug and play, which is precisely why it is worth doing well. Every machine has a different register map, every meter has a different pulse weight, and the documentation is either missing or describes a firmware version the machine no longer runs.

The Five Interfaces You Will Actually Meet

Pulse outputs are the simplest and the most common on utility metering. The meter closes a contact once per litre, or per ten litres, or per kilowatt hour, and a counter on the other end accumulates. A battery-powered pulse transmitter wired to that output reports totals on an interval and derives a rate from the gaps between pulses. Nothing about the meter changes, its certification is untouched, and the billing it feeds keeps working exactly as before. The only real trap is the pulse weight, which is printed on the meter and is wrong in the site documentation about a third of the time. Read it off the meter, then verify against a known draw before trusting anything.

Modbus is where most of the interesting data lives, over RTU on RS485 for older equipment and TCP over Ethernet for newer. A bridge polls the registers you care about on a schedule and reports the values onward, which is a read-only operation the control system does not notice. The difficulty is never the protocol, it is the register map: a vendor document that covers a different firmware revision, registers that are documented as one thing and hold another, values scaled by a factor nobody wrote down, and the occasional device that returns a valid-looking number for a register that does not exist. Working out the true map is bench work with the equipment in front of you, and it is most of the engineering effort on a retrofit.

Current loops carry a single analogue value between 4 and 20 mA, and they are everywhere in process instrumentation because they are almost impossible to break. A sensor clamps onto the loop, reads the current without interrupting it, and reports the value. The existing controller carries on doing exactly what it did; the new device is an observer with no vote. Worth knowing: the 4 mA floor is deliberate, so a reading of zero means a broken wire rather than a zero measurement, and that distinction should survive into your data rather than being flattened to null.

Dry contacts are the humblest and often the most valuable. A pump fault relay, a tank level float, a door switch, a run signal. A digital input device watches the contact and reports transitions. A compressor fault that used to light a lamp in a plant room nobody visits at night becomes a message on somebody's phone, and that single change frequently pays for the whole project.

M-Bus turns up on heat meters and European utility metering and is worth naming because it looks like Modbus and is not. It has its own physical layer and its own addressing, and a bridge that speaks it exists; a bridge that speaks Modbus does not.

Read Only, and Say So Out Loud

The objection that stops retrofit projects is not technical, it is a plant manager reasonably asking what happens if this thing interferes with production.

The answer needs to be architectural rather than reassuring. A polling bridge on a Modbus bus issues read requests and never writes. A current loop sensor is a clamp, galvanically isolated, with no path to the loop. A pulse counter is a contact input. None of these can command anything, because they have no write path implemented at all, and that is a property you can demonstrate rather than promise.

This matters more than it sounds, because it changes who has to approve the work. A read-only observer on an existing bus is a much smaller conversation than a device that could conceivably tell a machine to do something. Keep it that way even when a write would be convenient, and if control is genuinely needed later, treat it as a separate project with its own risk assessment rather than smuggling it in.

The value of a retrofit is that the control system does not know it happened. Design for that literally: no write path, no shared failure mode, and nothing that stops production if the monitoring stops.

The RS485 Physical Layer Will Bite You

More retrofit failures trace to bus wiring than to software, and they present as intermittent read errors that everyone blames on the new device.

RS485 is a daisy chain, not a star. Adding a device on a spur off the middle of a run creates a stub, and a long enough stub reflects signals and corrupts frames for every device on the bus, not just the new one. Termination resistors belong at the two physical ends and nowhere else, and a bus that worked fine with two devices can stop working when a third is added at the wrong place with the wrong termination. Biasing resistors hold the idle state; without them a bus can sit in an undefined state between transmissions and produce phantom bytes.

Then there is the addressing. Every device on the bus needs a unique address, which is a problem when the machine you are adding to shipped with address 1 like everything else from that vendor. And the baud rate, parity and stop bits have to match the existing traffic exactly, which means measuring what the bus is actually doing rather than trusting a manual.

None of this is hard, and all of it is invisible until it fails intermittently three weeks later. Budget an hour with a bus analyser rather than an afternoon of guessing.

Custom Firmware Is Usually the Point

Off-the-shelf devices handle the simple measurements well: a temperature, a humidity, a door contact. Industrial retrofitting rarely fits that shape, because every machine is different in a way the product catalogue cannot anticipate.

Purpose-built firmware for a bridge reads the exact registers your equipment exposes, applies the scaling that vendor actually uses, formats the result the way your pipeline expects, and transmits on a schedule that balances usefulness against battery life. It can also do the thing that makes battery operation viable at all, which is report by exception: send when a value crosses a threshold or changes materially, and stay quiet otherwise. That one behavioural change routinely takes a device from months of battery life to years.

Firmware is also where protocol translation belongs. Modbus RTU, Modbus TCP, M-Bus, BACnet and a dozen proprietary dialects all become one clean payload format before they reach your server, which means the question of what a given machine happens to speak stops being anybody's problem downstream. The alternative, translating in the application layer, spreads vendor quirks through the whole system and guarantees that the fifth machine breaks the first four.

Power Is Easier Than You Expect

The reflex on retrofit projects is battery, because that is what wireless sensors do. Industrial sites are the one environment where that reflex is often wrong.

Legacy equipment usually has 24 V DC or mains available within a metre, and using it changes the design substantially. A powered bridge can poll frequently rather than hourly, can hold a long RS485 conversation reading twenty registers per cycle, and never needs a battery visit. Where the equipment has a control cabinet, there is generally DIN rail space and a supply in it already.

Battery still wins where the meter sits in a pit, a riser or a field with nothing nearby, and where reporting can be infrequent. The point is to check rather than assume, because a mains-powered retrofit is both cheaper to run and considerably more capable.

What Retrofitting Cannot Do

Some things genuinely require replacement and it is worth being clear about them.

If the equipment has no output at all, and some genuinely do not, there is nothing to listen to. Occasionally an external sensor can infer what is wanted, a clamp meter reading motor current to detect running state, for example, but that is a proxy and should be labelled as one.

If the measurement needs to be legally billable in a jurisdiction with metrology rules, a retrofit reading of an uncertified meter will not satisfy them. The meter itself has to be an approved instrument, and the retrofit only carries its output.

And if the data is needed at a rate the interface cannot supply, the interface is the limit. A pulse output emitting once per ten litres cannot tell you anything about a leak of half a litre an hour, no matter what is attached to it.

What I Provide

I do the part that does not generalise. That means reverse engineering the register map with the machine in front of me, writing the firmware for the bridge, and characterising the result on the bench before anything is installed, so the device that goes to site is one whose behaviour is known.

Around it goes the ordinary work: bus survey and wiring, enclosures rated for where they are actually going, the decision about power, and the pipeline that takes the readings into storage and the dashboards that people actually open. The firmware source, the register documentation and the calibration notes are yours at the end, which matters here more than usual: a retrofit is only as maintainable as the notes explaining what register 40074 meant on that particular machine.