A machine that has run for fifteen years, a PLC in the cabinet still holding steady, one RS485 port, and a touch panel already sitting on it. The plant wants output counts and machine status inside a system. The first reaction is usually that the PLC program will have to be changed. Two weeks of downtime go onto the schedule, a quote lands on the plant manager's desk, and the project stops there.
To avoid being locked in to one vendor, someone once assembled a setup by hand: gear hanging from string, cabling exposed, a caption making fun of it. Six months later people still called it temporary. Further back, an almost identical build from five years earlier carries one line with it: if it is not broken, just replace the string. Retrofits of old equipment tend to end the same way: to keep from touching the PLC, more and more goes into the cabinet, and the temporary arrangement becomes permanent.
Whether the program has to change is not a yes-or-no question. The usual approach at the industrial IoT gateway layer is to sort the work by depth into three levels, and where to start depends on what has to be read.
Level one: read only, not a single byte of the program changes
With a PLC on site, the first thing to establish is not the gateway but what that PLC already exposes.
If the PLC has an Ethernet port and speaks Modbus TCP, the gateway becomes a Modbus master and reads register by register. That is the easiest path, and the only thing needed is the register map, taken from the original programmer or exported from the project file. If there is only a serial port and the touch panel occupies it, the gateway can join the same RS485 bus in passive listening mode: it takes no slave address and sends no requests, collecting only the question-and-answer traffic already on the wire. Wiring is two conductors tapped onto the bus. If the PLC uses its own brand protocol (S7, MC and the like), the gateway reads it by that protocol, provided the PLC side permits external access. On some models that permission is a setting in the hardware configuration that has to be downloaded once, which needs a maintenance window.
As long as nothing is written back into the PLC, not a line of the program changes. That is the floor for this level, and the line between a retrofit and a replacement.
Level two: for commands, check whether the PLC already exposes an address
Start, stop, recipe change, reset, alarm clear, all of these count as control. Control does not automatically mean a program change: if a coil or holding register already exists for the action, the gateway can write to it directly. Older machines are rarely that tidy. The test is straightforward. Split the requirements into two columns, read and write, then take each item in the write column and ask whether an address exists whose value performs that action. The items with no answer are the ones that genuinely need a program change.
Level three: when the program really has to change, it is usually three cases
First, a value that exists only inside the PLC and is not mapped to a communications area, such as cycle time or a pass-fail verdict. Second, event recording on the PLC side, recipe changes and latched alarms included. Third, external actions that must follow the PLC timing exactly.
The cost at this level is not in writing a few rungs of ladder logic. It sits in validation and accountability: who signs off, who owns a problem afterwards, whether the old program was archived. That work belongs in a planned shutdown, not squeezed into the same window as a digitalization project.
Downtime has to be counted in pieces
Tapping the bus stops production. Downloading hardware configuration stops production. Bringing the gateway online and reading only does not. Count the three together and a half-hour job gets quoted as a week.
There is a plain way to keep downtime short, and it works: listen for one shift, receive only, and match the captured frames against what the operator does, item by item, until the meaning of every point is settled. Then run read-only polling for a week and check the point list against actual output. After those two steps the drawing and the cabinet describe the same thing, and wiring can go ahead without rework. One rule is worth holding during the retrofit: leave the PLC program alone, get the gateway passing data, let the floor see numbers, and keep any program change for the next planned shutdown.
Polling rate: do not slow the PLC down
Faster is not better. The RS485 line previously carried nothing but the touch panel's question-and-answer traffic. Add a gateway and there is more traffic on the bus, so screen response can get slower, which is the most frequent complaint after data collection is added to an old machine. The safe approach is to work out how long one polling round takes from the baud rate and the number of points, set the interval just fast enough, and prefer change-of-state collection with reporting on change.
Four things the gateway has to handle at this layer
Pulling data from different protocols, arranging points into a table, deciding under what conditions to report, and holding data locally when the network drops. Those four separate an industrial IoT gateway from a plain router.
USR-M300 provides one RS232/485 port plus one RS485 port, one WAN/LAN port plus one LAN port, two digital inputs, two digital outputs and two analog inputs for current signals. Serial, Ethernet and I/O can be collected at the same time, up to 2000 data points. On the protocol side it converts between Modbus RTU and TCP and handles common PLC protocols. Reporting uses standard MQTT and TCP, and connects to PUSR Cloud, Alibaba Cloud, AWS, ThingsBoard and Azure, with reporting conditions and alarms configurable. Internet access is available over LTE 4G/3G, Ethernet and ADSL, with routing, VPN and a firewall built in. A dual-core processor runs at up to 1.2 GHz on Linux, Node-RED covers graphical programming where special logic is needed, and I/O extends modularly across DI, DO, AI and AO. On the industrial side there is level-3 EMC protection, wide-voltage input, an operating range of -25 to 75 degrees Celsius, and DIN-rail or wall mounting, with a Reload button for factory reset. Certification covers 3C, CE, FCC, ROHS, WEEE, CTA, ANATEL, ECAS ROHS, MTC, NBTC, RCM, SRRC and TDRA, plus EN 18031 cybersecurity certification.
Closing
Keeping the PLC is achievable; the price is accepting the order of operations: read first, argue about writing second, change the program last. Reverse that order and the downtime on the quote often costs more than the hardware. It is also why two conductors tapped onto that bus often say more about whether a retrofit was worth doing than a whole new system would.
1. Can data really be collected without replacing the PLC?
Yes, for the part the PLC already exposes. Ethernet with Modbus TCP, the traffic already running on a serial bus, and reads over the brand protocol where external access is permitted all fall inside read-only territory. No program change is involved.
2. Does adding collection affect the PLC scan cycle?
Read requests use communications resources rather than the scan program. What feels it first is other equipment on the same bus, typically touch panel response. Work out the baud rate and the number of points per round, set the interval just fast enough, and collect on change.
3. How much downtime does the retrofit need?
Three separate items: tapping the bus stops production, downloading configuration stops production, and gateway commissioning with read-only polling does not. Do the listening and point-list verification during normal production, and the shutdown shrinks to the wiring, whose scope depends on spare terminals and duct space in the cabinet.
4. What if the register map cannot be obtained?
Three routes: ask the original programmer, export it from the project file, or listen on the bus for one shift and match frames against operator actions. The last is slowest but needs neither downtime nor drawings.
5. The PLC has one communications port and the touch panel already uses it. What then?
Two options: join the same RS485 bus in passive listening mode, taking no address and sending no requests, or add a communications module to the PLC, which means downtime for wiring. Try the first. If traffic on the bus is already tight, listening may lose frames, and that is when the module becomes necessary.
6. How many points should one machine collect?
Count what the machine needs to show, not every register. List output, run status, alarms and key process parameters, then keep 30 percent headroom. USR-M300 tops out at 2000 points.
7. Is data lost when the network drops?
Two places to look: whether buffering and backfill sit at the device or at the platform, and that has to be settled in the design phase. What the gateway can do is detect an exception locally and raise an alarm on configured conditions, instead of waiting for the platform to poll and notice.
8. Beyond collection, is an industrial computer needed for local decisions?
It depends on complexity. Thresholds, ranges and simple interlocks can be configured on the gateway with Node-RED. Vision, a long-term historian, or d
