Documentation
Remote Modbus RTU: reach an RS-485 serial bus over the internet
Remote Modbus RTU is the textbook case of multi-site supervision: the meters, sensors and controllers speak Modbus RTU on an RS-485 serial bus, and the software that must poll them is hundreds of kilometers away. Two paths exist — and they deserve an honest presentation. Either you extend the serial link itself with Virtual-IO, the remote serial port feature of VIGIL-MESH: the supervision software opens a virtual COM port as if the bus were local. Or the site already has a Modbus TCP gateway: then you carry Modbus TCP through the mesh, encrypted, without opening a port.
The need: polling an RS-485 bus that sits on another site
Modbus RTU was born on the serial line: a single master polls slaves addressed 1 to 247, most often over an RS-485 pair. The protocol is everywhere — energy meters, measurement units, drives, controllers, PLCs — but it only knows its bus. As soon as the supervision software, the configuration tool or the historian live elsewhere, the question arises: how do you reach the bus without leasing a line, without exposing the site on the Internet, and without stacking up boxes?
Centralized supervision
An operator follows several sites — utility rooms, stations, buildings. Each site’s meters and controllers speak Modbus RTU; the supervision runs at headquarters.
The vendor tool
The drive’s or controller’s configuration software only knows a COM port and the RTU protocol. No network option, and the equipment is far away.
One-off diagnostics
A dubious value, a slave that stopped answering: you need to read a few registers and watch the bus traffic — without sending someone on site.
Two honest paths, depending on what the site already has
There is no single path that is “best everywhere”. The right choice hangs on one question: does the site already have a Modbus TCP gateway in front of its RS-485 bus?
A machine on site (industrial PC, Linux box) is wired to the bus through a USB–RS-485 adapter and becomes the provider: it shares its device path. The supervision machine mounts a local virtual port — a real COM port on Windows, a pty /dev/ttyVIGIL-<name> on Linux — and your Modbus RTU master opens it as if the bus were plugged into the workstation. The detailed mechanics are described in Remote serial port.
- Nothing changes on the slave side: the bus, the addresses, the registers and the master tool stay identical — only the COM port the tool opens is virtual.
- One writer at a time: writing is exclusive, which matches the Modbus single-master model. Up to 8 machines can watch the traffic read-only.
- End-to-end encrypted inside the mesh session, access granted machine by machine, nothing exposed on the Internet.
If the equipment already speaks Modbus TCP, or if the site already has a Modbus RTU/TCP gateway in front of its bus, there is no point extending the serial link: the mesh carries Modbus TCP like any IP flow. A machine on site joins the private network through a single outbound connection; the supervision reaches that machine by its overlay address, and it relays the authorized Modbus TCP flow to the gateway. ACLs limit access to the strict minimum.
- The protocol stays native: no extra conversion — the supervision speaks Modbus TCP to the gateway as if it were local.
- No open port: port 502 is never exposed on the Internet; access goes through the private network and its ACLs.
- Already documented: this path — site gateway, least privilege, limits — is covered in depth in Remote Modbus and SCADA access. This page does not duplicate it.
| Site situation | Recommended path |
|---|---|
| Bare RS-485 bus, no gateway — and a tool that only speaks COM/RTU | Path A: Virtual-IO, virtual COM port on the supervision side |
| Modbus RTU/TCP gateway already in place, or Modbus TCP devices | Path B: Modbus TCP carried through the mesh |
| Several people need to watch raw RTU traffic (diagnostics) | Path A: read-only fan-out to several machines |
Real case: supervision at headquarters, the bus three hours away
A utility room hosts a dozen energy meters on an RS-485 bus, polled over Modbus RTU. The historian and the energy reports run at headquarters, three hours away by road. The site has no Modbus TCP gateway, no fixed IP, no IT staff — and company policy rightly forbids opening a port on the site’s router.
Until now, readings were taken on site, a laptop plugged into the bus: one trip per measurement campaign, and no visibility between two visits.
- 1Install a provider machine on siteA Linux box or industrial PC, wired to the bus through an auto-direction USB–RS-485 adapter, is enrolled into the network. The machine only makes outbound connections.
- 2Create the share in the Virtual-IO tabWeb console → the network → Virtual-IO tab: share name, provider machine, device path (
/dev/ttyUSB0…), then baud rate and parity matching the bus (for example 9,600 8N1 or 19,200 8E1 — reuse the meters’ existing configuration). - 3Grant read-write to the supervision machineIt alone will issue the requests (one writer — consistent with the single Modbus master). Other machines stay at “none”, or “read” for passive diagnostics. Save.
- 4Point the Modbus master at the virtual portOn Windows, the driver creates a real COM port; on Linux, the share appears as
/dev/ttyVIGIL-<name>. Configure your supervision software exactly as on site: same baud rate, same slave addresses, same registers. - 5Widen the response timeout, then validateAdd the Internet link’s round-trip latency to the slaves’ usual response time, with margin, and check the behavior over a few full polling cycles before going to production.
Modbus RTU timing: what an Internet link changes
Modbus RTU delimits its frames with silences on the bus (the well-known inter-character times). That mechanism stays local: the provider machine’s serial port is what talks to the bus, at the bus’s speed. What crosses the Internet is the request-response round trip between your master and the provider — and that latency adds to every transaction.
Limits and beta status
Access is granted machine by machine — no whole-subnet exposure. Plans are detailed on the pricing page.