Can you retrofit a legacy PLC for IIoT without touching its logic?
Yes. Reading the signals that are already there, instead of reprogramming the controller that produces them.
That distinction is the entire retrofit problem. Most integrators already know how to get data out of a machine. What stops them is the cost of touching a program nobody wants to requalify.
Why PLC retrofit projects stall: it's the risk, not the machine's age
A PLC running the same ladder logic for twelve years is not a technical problem. It is proof the logic works. The actual barrier to retrofit is what happens the moment someone opens that program: a change request, a validation cycle, a production line that cannot go down for testing, a warranty clause that treats any firmware edit as a modification voiding support, and, more often than any vendor wants to admit, nobody left on the team who fully understands the original logic well enough to touch it safely.
None of that has anything to do with obsolescence. It has to do with risk. And risk is exactly what a retrofit project should be designed to avoid, not introduce.
Poll the PLC, don't reprogram it: the non-invasive data capture method
There are two fundamentally different ways to get IIoT data out of a machine that already has a working PLC:
- Rewrite the program. Add data-logging logic inside the existing PLC, expose new registers, modify the scan cycle. This requires access to the source program, a full requalification of the control logic, and a change window on a machine that is, by definition, running production.
- Read what's already there. Poll the PLC's existing communication port (Modbus RTU over its RS-485 bus, Modbus TCP over Ethernet, or OPC-UA if the controller exposes it) or tap spare digital/analog I/O in parallel: run/stop, fault, cycle-end signals that are frequently already wired to a terminal block with nothing connected. Neither approach changes a single line of the running program.
The second path is what makes a retrofit approvable in a change-control meeting instead of blocked by one.
ESP32 PLC vs. GateBerry: choosing the right retrofit device
Industrial Shields covers this with two devices built for different scopes of the same problem. Neither replaces the other. Using the wrong one for the scope just adds cost or complexity.
| Scope | ESP32 PLC | GateBerry |
|---|---|---|
| Typical use | Single machine, single tap point | Multiple machines, multiple protocols, one site |
| Footprint | Compact, mounts inside the existing cabinet | DIN-rail, dedicated gateway enclosure |
| Connectivity | Native WiFi and Bluetooth, optional LoRa for distant points | Modbus RTU/TCP, OPC-UA, MQTT, CAN, LoRa, GPS, 4G LTE (modular) |
| Processing | Local read and publish | Local protocol translation and aggregation across sources |
| Programming environment | Arduino IDE, built on the Arduino open ecosystem | Linux-native: Python, Node-RED, Docker |
If the job is one machine and one signal set, an ESP32 PLC wired in parallel is often the entire retrofit. If the job is a panel with three legacy PLCs speaking three different protocols, a GateBerry sitting alongside them, reading each one and publishing one consistent feed, is the faster route to a usable dataset.
PLC retrofit architecture: from the existing controller to your dashboard
The pattern stays the same regardless of which device does the reading:
Existing PLC (unchanged) → signals tapped via Modbus polling or parallel I/O → ESP32 PLC or GateBerry → MQTT, OPC-UA or Modbus TCP → whatever platform you already run: Grafana, a SCADA historian, an MES, or a cloud IoT service.
Nothing in that chain requires the existing PLC to expose anything it doesn't already expose, and nothing in it requires a change window longer than the time it takes to land a few wires on a terminal block.
Example: predictive maintenance data from 146 legacy looms
Problem: A textile manufacturer needed predictive and preventive maintenance data, consumption tracking and downtime analysis, including stop reasons, across 146 looms running two shifts a day. The existing loom controllers were never built to expose any of that.
Requirements: No changes to the existing control logic on any of the 146 machines. Data covering run/stop state, downtime reasons and consumption, aggregated at scale across two production shifts.
Solution: The same non-invasive approach described above: an ESP32 PLC or GateBerry wired in parallel to the existing signals on each loom, publishing over MQTT to a central platform, without opening a single controller's program.
Result: Real-time downtime, downtime-reason and consumption data now cover all 146 looms across both shifts, feeding predictive and preventive maintenance decisions that used to rely on manual logs.
Get started: PLC Solution Library, ESP32 PLC and GateBerry
The PLC Solution Library includes working code for exactly this: Modbus RTU and TCP polling, MQTT publishing, and parallel I/O reading, filterable by device and protocol. If your next retrofit needs one of those, you are not starting from a blank sketch.
Explore ESP32 PLC for single-machine retrofits, or GateBerry for multi-protocol, multi-machine gateways, at www.industrialshields.com.