Serial to Ethernet: Moving RS-485 Devices Without Rewiring the Plant
A serial gateway looks like a wire replacement and behaves like a protocol change. Timing, addressing and error handling all move, and each one has a way of biting late.
There is a large installed base of perfectly good instruments speaking Modbus RTU over RS-485, and a persistent desire to get their data somewhere modern without paying to rewire a plant. The serial-to-Ethernet gateway is the standard answer, and it works. It is worth understanding what it actually changes, because the failure modes appear weeks later and are attributed to the wrong thing.
There are two distinct products sold for this and the difference matters. A serial tunnel, sometimes called a virtual COM port, transports raw bytes across the network and presents them to software as a local serial port. It is protocol-agnostic and therefore works with anything, including proprietary protocols, but it forwards the timing problem intact. A protocol gateway terminates Modbus RTU on the serial side and speaks Modbus TCP on the network side — it understands the frames, so it can handle the serial timing locally and answer network requests properly. For Modbus, the protocol gateway is almost always the right choice; the tunnel's advantage is only that it supports protocols the gateway does not.
Timing is where most of the trouble is. Modbus RTU delimits frames by silence: a gap of three and a half character times marks the end of a message. Ethernet does not preserve inter-byte timing. A tunnel that buffers bytes and sends them when convenient can destroy those gaps, so a slave sees one long malformed frame or two frames merged. Good tunnels have settings for this — pack on a delimiter, pack on a timeout, pack on a length — and configuring them correctly is the difference between reliable and intermittent. Latency also changes: a serial poll had a deterministic round trip, and a network poll has a variable one, so response timeouts that were generous on a wire become marginal over a network, and dramatically so over a VPN or a cellular link.
Addressing is the second change, and the one most likely to surprise. On a multidrop RS-485 segment, each device has a unit ID, and that ID is unique only on that segment. Put several segments behind gateways and the IDs collide. Modbus TCP carries a unit identifier field for exactly this reason, and a decent gateway maps a TCP unit ID to a serial address on a particular port. Many masters ignore the field or set it to a constant, at which point a system with two gateways starts returning the wrong device's data — plausibly, silently, with correct-looking values. Deciding the unit ID mapping deliberately and writing it down is a five-minute job that prevents a class of bug that is nearly impossible to diagnose from the data.
Concurrency is the third. A serial bus is strictly one transaction at a time; a network port accepts many simultaneous connections. Point three polling clients at one gateway and they will queue behind a bus that has not become faster. The symptoms are timeouts under load and a system that works during commissioning and degrades when a second application is connected. Gateways differ substantially in how well they serialise and queue requests, and some simply drop the overflow. Decide early whether the gateway or a single client is the arbiter — usually the cleanest pattern is one poller that owns the bus and republishes the data, rather than several applications competing for it.
Then the physical layer, which the gateway does not fix and which is often the actual underlying problem. RS-485 is a bus, not a star: it wants a daisy chain, termination at both ends and one ground reference. Stubs, a star topology, missing or doubled termination, and a floating common are extremely common in installations that grew over time, and they produce exactly the intermittent errors that get blamed on the new gateway. Before adding Ethernet, check the segment: count the devices, check the termination, look at the baud rate and cable length together, and scope the waveform if anything is marginal. Adding a gateway to a marginal bus produces a networked marginal bus.
Finally, security, because this is the step at which a serial device that was inherently isolated becomes reachable from a network. These devices have no authentication and no concept of a bad actor; Modbus has no security at all. A gateway is therefore a boundary, and it belongs in a segmented zone with a firewall rule that permits only the specific master, not a convenient any-to-any. Many gateways also ship with a web interface and default credentials, and that interface is now a device on your network with its own vulnerability history.
Done deliberately, this is a good migration: it preserves working instruments, avoids rewiring and gets the data into a modern stack. Done as a wire replacement, it moves the problem from the plant floor into the network, where it is harder to see.