A card reader at the door, three drives in the main electrical cabinet, two temperature controllers in the control box, an older PLC at the loading point, and every one of them left with nothing but a serial cable. Getting all of them read at a single machine in the control room has little to do with parameters at first; it is the naming that gets in the way. One page says serial gateway, another says serial device server, and once the port count rises it becomes terminal server. The line between the terms is simple: one serial port brought onto the network is a serial device server; several ports means searching for a terminal server; when the unit sits in a plant and also has to understand a protocol such as Modbus, the phrase people search for is serial gateway. Underneath, all three are doing the same thing: a serial to ethernet converter turns a serial port into an address on the network and leaves the device itself alone.
The test is simple. Two devices sitting far apart, unable to share one RS-485 bus, each get their own unit. RS-232 is a point-to-point signal that runs out after a dozen meters or so; RS-485 ties neighboring devices onto one bus, provided those devices belong together on that same line. Keeping one converter per piece of equipment leaves them independent: adding one or losing one disturbs nothing else.
The USR-N510 fits here: a single serial port, offered either as RS232/422/485 three-in-one or as RS485 only, with an ST Cortex-M7 running at 400 MHz; TCP Server, TCP Client, UDP Server, UDP Client and HTTPD Client modes; MQTT 3.1 and 3.1.1 with SSL/TLS including two-way certificates; conversion between Modbus RTU and Modbus TCP with multi-host polling, up to 128 data points, and Modbus address mapping; all four serial parameters changeable from the network side; wide DC 5-36 V input with reverse-polarity protection.
Dedicated single-port units scale badly. Management cost grows in a straight line: one IP address, one configuration page, one cable, and one parameter backup each. Past three devices mounted on the same cabinet panel, a single multi-port unit beats a row of individual converters: one IP, one sheet of settings, and shorter wiring inside the cabinet. This is the tier the industry calls a terminal server, or a multi-port serial device server; the difference between the two names is only port count and mounting style.
The USR-N540 carries four serial ports, each selectable in software as RS-232, RS-422 or RS-485, with all four working independently; every serial port supports two sockets configured as primary and backup; one WebSocket channel comes alongside TCP Server, TCP Client, UDP Server, UDP Client and HTTPD Client; Modbus RTU converts to and from Modbus TCP with multi-host polling, and the unit can act as a Modbus RTU master, polling devices and passing the results onward as MQTT JSON. There is USR-VCOM for virtual COM ports, SSL/TLS encryption, 15KV ESD protection on the serial ports; metal housing rated IP30 at 222×142×29 mm, wall mounting or an optional DIN rail, -40 to 85 °C, wide-input power with reverse-polarity protection, and a Reload button held down to restore factory defaults. Where two ports are enough, the USR-N520 is the more compact option: 150×98.8×30 mm including terminals and mounting ears, dual RS485/RS232, the same Modbus gateway functions and 128-point collection. One documented deployment connects charging piles to a charging operations platform.
Device servers and terminal servers do one job: carry bytes from the serial port to the network port without looking inside them. A gateway does one layer more, reading the protocol. Where the registers sit, which values one frame carries, how each variable should be named: somebody has to fill that in. The dividing line is easy to state. Reading directly over Modbus TCP, or letting older software keep opening a COM port, is handled by the first two tiers. Turning the data into JSON for an in-house platform, sorting it against a point table before reporting it upward, needs a gateway.
The USR-N720 covers that step. Its Ethernet version provides 2×RS485 plus one network port, and the cellular version adds one more interface for cellular; it supports up to five connections at once (two MQTT, two TCP and one PUSR), with SSL available on MQTT and TCP alike; both Modbus and DL/T645-2007 convert to MQTT JSON with customizable JSON fields, covering 1000+ data points; traffic falls back to an SD card when the link breaks and is forwarded again once it returns; metal housing, DC 9-36 V, -40 to 85 °C, 86×30×98.5 mm, DIN rail or wall mounting, hardware and software watchdogs, and parameters and firmware both reachable remotely through the cloud platform.
Whichever tier the choice falls into, the table has the same columns: which piece of equipment it attaches to, whether the port is RS-232 or RS-485, baud rate, data bits, parity and stop bits, the Modbus slave ID, the destination IP address and port, and who reads it. That table decides the port count. How many devices sit together decides between USR-N510, USR-N520 and USR-N540; whether the protocol has to be understood decides whether the job stops at the first two tiers or moves up to the USR-N720.
Two points tend to be underestimated. The first is polling time: the more devices and points hang on one RS-485 bus, the longer a full round takes, so the sampling interval follows the length of the entire round rather than the response speed of one device. The second is what happens after commissioning: per-port parameters and firmware versions should be exported and archived at handover, and later additions copied from that template, which leaves less room for error than configuring each port by hand.
In the end the name only shapes which search terms lead somewhere useful. What decides the shape of the hardware is where the devices sit, how many there are, and who receives the data. Write those three down and the right tier follows on its own; serial to ethernet adapter is simply the shared name for all three forms.
1. Does a serial device server alter the protocol?
Not by default. Standard operation is transparent: whatever bytes arrive on the serial port come out at the other end unchanged. Only with the Modbus gateway mode enabled does it repackage RTU frames into Modbus TCP messages.
2. How many machines can read one serial device at once?
That depends on how many clients the TCP Server supports, and on the serial link itself. In multi-host setups one path usually writes while the others only listen; on the Modbus side, polling queues the hosts and runs them one after another.
3. Must all four ports on a four-port unit be configured identically?
No. Each port on the USR-N540 selects RS-232, RS-422 or RS-485 independently, serial parameters are set per port, and all four run at the same time.
4. Can an RS-232 device be wired into an RS-485 port?
It cannot. RS-232 is a single-ended signal referenced to ground, while RS-485 is differential, and a passive adapter changes neither the levels nor the topology. The port version should be chosen against what the equipment actually puts out.
5. Why does transparent transmission feel solid for console access yet shaky for continuous data?
Console sessions are short exchanges between a person and a device, where connecting at all matters most; continuous data puts the pressure on automatic reconnection after a link drops. That behavior belongs to the device's own reconnect mechanism, and a run of continuous data during acceptance testing shows it quickly.
6. With virtual COM software already in place, is a gateway still needed?
It depends on where the data goes. Handing it to one older application on Windows is fine with virtual COM ports alone. Sending it to an in-house platform or the cloud takes the extra layer that reads the protocol and maps the points.
7. Is data lost while the link is down?
Devices doing transparent transmission keep no buffer, so whatever happens during the outage is gone. When retention matters, pick a model with offline storage and confirm during acceptance that it re-sends what was cached.
8. At what point should single ports give way to a multi-port unit?
Two things: whether the devices sit close enoug
