A portable industrial PC from 1990 — a 386 processor, DOS 6.2, a 640×480 CRT screen — spent years on a bench as a big, loud serial console that logged test data onto 3.5-inch floppy disks. Its owner later pulled the old 386 board, dropped in a modern single board computer, added a 32GB CF card, and installed a stripped-down Linux distribution with no graphical desktop. The chassis, keyboard and screen stayed in service, and the machine became a development platform that compiles and flashes microcontroller programs.
Keep the chassis, replace the board. The same logic holds on a factory floor. Weighing scales, labeling machines, temperature controllers and older PLC that have run for years usually only lose the computer sitting behind them. That is where the difficulty starts: nearly all of these devices speak RS-232 or RS-485, while a newly purchased embedded industrial pc is often shipped without a single usable serial port.
Marketing pages for industrial computers tend to be organized around compute: how many TOPS, how many cameras, whether a vision model runs on board. Those numbers genuinely matter for mobile robots. A legacy weighing scale that only speaks RS-485 does not care about any of them. It cares whether the port on the other end matches.
What decides the outcome is rarely the processor model. It is the combination of two variables: how far the legacy device sits from the new computer, and which operating system the legacy software runs on.
RS-232 and RS-485 are often treated as one thing, but their constraints differ entirely. RS-232 is point-to-point and short-range: one cable, one device, roughly 15 meters. RS-485 is a differential bus that carries multiple devices over several hundred meters, at the cost of termination and master-slave polling. The two cannot be joined with an adapter cable alone: RS-232 is single-ended signaling referenced to ground, while RS-485 relies on a differential pair, so a passive adapter has no conversion to perform between them.
Another detail that is easy to miss: many positions labeled "serial" on a modern computer are actually USB-to-serial virtual ports, with unstable drivers and power delivery. An industrial computer should provide physical serial ports on DB9 or terminal blocks.
Inside a single cabinet, a few meters apart, direct wiring is the simplest option, provided the new computer carries enough serial ports. Across workshops, between floors, or spread over several locations, running serial cable is not realistic. The workable approach is to convert serial to Ethernet locally: a serial device server beside the legacy equipment, one network cable to a switch, and the computer reads the data over the network.
The USR-TCP232-410s is one of these devices: one RS-232 port (DB9 male) and one RS-485 port that can operate at the same time, serial rates from 600bps to 230.4Kbps, a network port with 1.5KV electromagnetic isolation, wide-voltage input with reverse polarity protection, -40 to 85°C, and hardware plus software watchdog. There are two paths for the computer to reach the data: a program connecting over TCP (TCP Server, TCP Client, UDP, HTTPD Client and MQTT reporting are supported), or virtual COM port software, so an older program keeps opening the same COM port. The first path suits applications written against sockets; the second suits legacy software that only knows how to open a COM port by its number.
The trap is here: a serial device server moves bytes, it does not parse content. Whether the legacy device speaks a proprietary protocol or standard Modbus has to be identified by the host software or by the edge layer; if the computer side is expected to read directly over Modbus TCP, choose a model with Modbus RTU to TCP conversion built in.
This step causes the most rework. Configuration tools, SCADA packages and flashing utilities for legacy equipment are frequently Windows-only and no longer updated, and they do not move to Linux. The check is straightforward: list the software that ships with the legacy devices and see whether any of it requires Windows.
Where Windows-only software or an existing SCADA package is in use, an x86 model fits. The USR-EC300 ships with Windows as standard (Linux optional): i5-7200U, 128G wide-temperature SSD, six serial ports of which two switch between RS232/RS485/RS422 and the other four are fixed RS232, dual gigabit Ethernet, DC 12-36V input, -20 to 60°C, full aluminum fanless enclosure. Where serial ports are needed in greater number, the USR-EC500 offers eight.
Where the legacy device only outputs data over a standard protocol for an in-house program to read, an ARM model fits better: lower power draw, suited to unattended operation. The USR-EG528 uses a quad-core Cortex-A53 at 2.0GHz with four serial ports (two RS485 and two switchable RS485/RS232), plus two 100M Ethernet ports, DC 9-36V input, -25 to 75°C and hardware plus software watchdog. It ships with Ubuntu 24.04 and the WukongEdge engine, including local SCADA/HMI configuration, so serial data can be collected and turned into a screen without writing code. IEC 61850, DLT645, DNP3.0, BacNet and major PLC brands are supported, and Node-RED is pre-installed, so logic changes do not require a trip back to the office to recompile.
Where 4G/5G uplink or CAN bus devices are also involved, the USR-EG628 carries two RS485, one RS232 and one CAN port, two Ethernet ports, and built-in routing, VPN and firewall, with cellular and wired links backing each other up.
First, serial type and count: RS-232 or RS-485, how many ports, and whether they must work at the same time. On switchable ports, note that a single port can only be RS232 or RS485 at any given moment.
Second, the four serial parameters: baud rate, data bits, parity and stop bits must match the legacy device. This is where commissioning most often stalls.
Third, where the data goes: for local viewing only, choose a model with display output or local configuration; for MES, SCADA or cloud platforms, confirm first whether the uplink protocol is Modbus TCP, MQTT or a proprietary TCP, and whether offline buffering is required.
Legacy equipment does not disappear because the computer behind it was replaced, and there are only two ways to connect it. Settle distance and operating system first, then match serial port count and protocol. Choosing an embedded industrial pc that can keep talking to these devices for years is more practical than buying an extra measure of compute.
