Resources / Guide
Will It Work on My Old Machines?
It is the first question most plants ask, and it usually gets a salesperson's answer. Here is the engineer's answer: age is not the variable that matters. What the machine already emits is. This guide walks the ladder of what old equipment can give you, what each rung actually buys, and where the honest answer is that you need something other than us.
Age is a bad proxy. Ask what it emits.
Everyone asks the question in terms of years, because years are the thing you can see on a nameplate. But the year a machine was built tells you almost nothing about whether you can monitor it.
A 1994 press with an Allen-Bradley PLC and a serial port will hand you run and stop transitions, cycle events, and a stroke count this month. A 2019 machine on a closed proprietary control, where the vendor exposes nothing and sells its own portal, can be genuinely harder to read than the press that is twenty-five years older. Age is not the variable. Access is.
So replace the question. Instead of "how old is too old," ask three things about each machine:
- Does it have a control that speaks anything at all, open or otherwise?
- Can you reach that control on a network or a serial line without touching control logic?
- If the machine itself is silent, does something else in the plant already know what it was doing - a historian tag, a SCADA point, a job record in the ERP?
Ask those three per machine and your fleet sorts itself into readable and not readable, with the build year barely correlating. That sort is the real work, and it is worth doing before you talk to any vendor, including us.
The ladder of what old equipment can emit
Here is the ladder, best rung to worst. Most plants have machines on every rung at once. What matters is knowing which rung a given machine sits on, because that determines what you can measure and what it costs to get there.
Rung 1: a control with an open protocol. OPC-UA on newer PLCs and most SCADA servers. MTConnect, which is native to CNC and machine tools and is read-only XML over HTTP by design - you pull samples and events from the agent. FANUC FOCAS on Fanuc controls. This rung gives you the most: execution state, part counts, alarm codes, feed and spindle overrides, program name. Enough to separate in-cycle from between-cycle and give idle time an actual cause instead of letting it disappear into a utilization average. Note that a 1998 Fanuc can speak FOCAS. This rung is not about age.
Rung 2: an older PLC on Modbus. Modbus TCP if the machine has an ethernet card, Modbus RTU over a serial line (RS-485 or RS-232) if it does not. This is the workhorse for pre-2000 iron. You get run and stop transitions, cycle events, counts, and often a fault word. It is a thin signal compared with rung 1, but it is enough for availability, cycle-time distribution, and the minor stops that never reach a manual downtime log. A surprising share of old equipment lives here and its owners do not know it.
Rung 3: no useful control data, but existing historian or SCADA tags. If a machine is already trended in OSIsoft PI, Ignition, Kepware, Rockwell FactoryTalk, AVEVA Wonderware, or GE Proficy, the collection problem was solved years ago by someone else. You read what the historian already logs. The honest caveat: you get whatever a predecessor decided to log, at whatever scan rate they chose. Sometimes that is a rich picture. Sometimes it is one temperature every five minutes.
Rung 4: the machine is silent, but the ERP or MES knows the job. Orders, routings, scheduled runs, reported quantities, labor confirmations. This is not machine state and it never will be. But it lets you infer scheduled versus unscheduled: if a job was booked for six hours and reported nine, something happened, and now you have a bounded window to ask about. It is coarse. It is also real, and it is frequently the only thing available on predigital equipment like cold-heading machines.
Rung 5: nothing readable at all. This one gets its own section, because it is where our answer stops being yes.
Rung five: when the honest answer is not us
Some machines emit nothing. A predigital cold header. A mechanical press with a relay panel and a mechanical counter. A row of standalone equipment where the only output is a stack light and an operator's memory. For that equipment there is no clever integration waiting to be found. There is no port, no tag, no record. Something has to create a signal before any software can read one.
That means adding sensing: a clip-on current sensor on the power feed, a stack-light reader, a proximity switch counting strokes. And that is not us. KaizenFlow needs signals to read.
If your floor is mostly machines like this - older equipment, no PLCs worth reading, no ERP data - clip-on sensing is genuinely the faster start, and Guidewheel is a credible choice. Their sensor works on any age, make, or model, needs no integration, and the hardware is included in the subscription. We say that on our comparison page and we mean it here. Forcing a data-ingestion story onto a plant with no data to ingest would waste your time and ours.
It is also rarely all-or-nothing. Most plants are not uniformly silent; they have a few rung-five machines and a lot of rung-two and rung-three ones. Sensors on the silent machines and direct reads everywhere else is a perfectly sensible arrangement, and the two approaches do not fight each other.
The mixed fleet is the normal case
Nobody has a uniform floor. Real plants are a zoo: five decades of equipment, half a dozen control families, a couple of machines nobody has the manual for, and one brand where every unit somehow has a different control revision. Controls engineers routinely doubt they will ever get all of it monitored, and on the evidence they are right to.
Two things follow from that, and both are more useful than a vendor promising full coverage.
First, do not boil the ocean. Start with the lines that already emit, prove the value there, then expand. A staged rollout ordered by what the loss costs beats a heroic all-machine project that stalls in month four, every time. The lines on rung 1 and rung 2 are usually enough to establish whether the whole exercise is worth continuing.
Second, you probably do not need every machine. You need the constraint. Monitoring the bottleneck moves the number that matters; monitoring forty machines evenly mostly produces a bigger dashboard. If a machine is not the constraint and never will be, the case for instrumenting it is weak regardless of how easy it would be.
One more honest note: messy tags are normal. Inconsistent naming, tags that mean different things on line 2 and line 5, counters that reset for reasons lost to history. Nobody's tag dictionary is clean. Cleaning enough of them to measure is part of the work, not a prerequisite you have to finish first, and any vendor who acts surprised by your tag mess has not seen many plants.
What retrofit actually costs, in both models
There are exactly two ways to get data off an old machine: add hardware that creates a new signal, or read a signal that already exists. Neither is free, and the costs land in different currencies.
Sensor-first has real hardware and install cost, and works on anything. You buy a device per machine, and someone has to mount it: panel access, an electrician in some cases, a safe tap on the power feed, network or gateway coverage on the floor. Then someone owns those devices - batteries, firmware, the one that falls off. In exchange you get a method that does not care what your machine is, how old it is, or what your IT estate looks like, and live data quickly. On a floor of silent equipment, that is not a compromise. It is the only thing that works.
Signal-first has no hardware, and needs something to read. Nothing gets mounted, nothing gets maintained on the floor, and there is no per-machine device cost. The cost moves instead to access and mapping: credentials, network paths to controls that were never meant to be reachable, agreement from your controls team, and the tag mapping that makes a count on one line mean the same thing as a count on another. That work is real and easy to underestimate. And if a machine emits nothing, the cost is not high, it is infinite - the approach simply does not apply.
The question is not which model is cheaper in the abstract. It is which currency you have. A plant with an OPC-UA server, a historian, and an ERP already paid the expensive part of signal-first years ago. A plant with forty mechanical machines and a whiteboard has not, and would spend a year trying.
Both models share one cost that vendors underplay: someone still has to own it. Hardware or not, the system needs a person, and that person is usually your most capable engineer.
And yes, you could build it yourself
If you have a good controls engineer, the honest alternative to any vendor on this page is an ESP32 on the stack light, a FOCAS poller, Node-RED on a shop PC, and a weekend of wiring. For a handful of machines and basic run and stop visibility, that is real, cheap, and sometimes exactly enough. Overkill is its own kind of waste.
The limits show up later: the protocol zoo at scale, the hidden claim on your best technical person, and the system that quietly retires when its builder changes jobs. Our build versus buy comparison lays out both sides without a thumb on the scale, including the cases where building is the right call.
How KaizenFlow handles old equipment
With that context, here is the specific and narrow claim. KaizenFlow is software only. It reads what your equipment and systems already emit, on rungs 1 through 4, and it does not pretend to help on rung 5.
What it reads on older equipment:
- Modbus TCP and Modbus RTU over serial, which reaches the pre-2000 PLCs that never got an ethernet card.
- MTConnect and FANUC FOCAS for CNC and machine tools, including controls old enough to predate anything modern.
- OPC-UA for newer PLCs, SCADA servers, and most of the long tail that speaks a standard.
- A lightweight edge adapter for the oldest controllers, which sits alongside the machine and reads it. Where one is deployed, reads continue locally and sync when the link returns.
- Historians and SCADA: OSIsoft PI, Ignition, Kepware, Rockwell FactoryTalk, AVEVA Wonderware, GE Proficy.
- ERP and MES for job context: SAP, Microsoft Dynamics 365 Business Central, Oracle NetSuite, Oracle EBS, Infor, Epicor - so a silent machine still has a scheduled-versus-unscheduled story.
- The long tail: REST, ODBC/SQL, and CSV/SFTP, for the systems that expose nothing else.
That is part of 43+ pre-built connectors, listed in full on the integrations page. If something on your floor is genuinely bespoke, a net-new connector is built as part of design-partner onboarding rather than sold as a change order.
Three constraints worth stating plainly. There is no machine replacement and no rip-and-replace: your operators keep their HMIs and your equipment stays as it is. Connections are read-only by default, so KaizenFlow does not write to PLCs or send commands to the floor - it observes, it does not control, and a connectivity outage never stops a line. And most single-site connections are live in one to two weeks, because the timeline is credentialing and tag mapping, not construction.
If your fleet is CNC-heavy, the precision metal page goes deeper on reading older controls. If you want the measurement fundamentals underneath all of this, start with the OEE and TEEP guide.
Frequently asked
Can you monitor a machine with no PLC? Not by ourselves. KaizenFlow reads signals that already exist, and a machine with no PLC, no historian tag, and no job record is not emitting one. Something has to create the signal first, usually a clip-on current sensor on the power feed or a stack-light reader. If most of your floor looks like that, sensor-first vendors such as Guidewheel are the better starting point, and we would rather say so than force-fit an integration story onto a machine with nothing to integrate.
How old is too old? That is the wrong question, and it is the one everybody asks. Age is a bad proxy. A 1994 machine with a PLC you can reach over Modbus is easier to monitor than a 2019 machine on a closed proprietary control that exposes nothing. The right question is: what does this machine already emit, and can I get at it without touching control logic? Ask that per machine and your fleet sorts itself into readable and not readable, with the build year barely correlating.
Do we have to replace or upgrade our machines? No. KaizenFlow is software only. There is no machine replacement, no control retrofit, and no rip-and-replace. We read what your controls, historians, and ERP already produce and leave the equipment exactly as it is. Where a control is too old to reach directly, a lightweight edge adapter sits alongside it and reads. Connections are read-only by default, so nothing writes back to a PLC.
What about a mixed fleet of different brands and controls? That is the normal case, not the exception. Most plants run several decades and half a dozen control families under one roof, and nobody connects all of them at once. The practical move is to start with the lines that already emit, prove the value there, and expand. You rarely need every machine anyway, you need the constraint. Messy tags across a mixed fleet are also normal, and mapping enough of them to measure is part of the first two weeks.
Can you read a machine over serial? Yes. Modbus RTU over a serial line is a supported connector, and it is the workhorse for pre-2000 iron that never got an ethernet card. It will not give you the rich state a modern control does, but run and stop transitions, cycle events, and counts are usually enough to size availability losses and catch the minor stops that never reach a downtime log.
Own your output
Find out which rung your fleet is on
Tell us what your machines actually emit. If the answer is nothing, we will tell you that and point you at sensor-first vendors instead. If there are signals to read, an eight-week pilot ends in a savings report your finance team can sign.