Edge Gateway

Modbus RTU/ASCII to Modbus TCP

The Modbus converter: slaves on a serial RTU or ASCII bus, reached by a Modbus TCP client (master) through the gateway, which acts as the Modbus TCP server for it. A gateway service beside the flow, not a step in it.

Product page →

The data flow

Think of the gateway as standing between two worlds. On the network side it behaves like a Modbus TCP device. Your SCADA, PLC, HMI or software is the Modbus TCP client (the master): it connects to the gateway's IP address and port and sends normal Modbus TCP requests, exactly as it would to any Modbus TCP device. On the serial side the gateway is the master of the RS-485 bus. It takes each request the client sent, sends it down the serial line to the slave named by the unit ID, waits for the slave's reply, and hands that reply back to the client as a Modbus TCP response. The client never knows there is a serial line; the slaves never know there is a network.

	The serial side (the RTU / ASCII bus)	The network side (Ethernet)
What is spoken	Modbus RTU or Modbus ASCII, on an RS-485 or RS-232 line	Modbus TCP. Modbus over UDP is also available, for the few products that use it
What the gateway is	The master of the bus: it asks the slaves and waits for their answers	A server: it listens on a port and answers whichever client connects
Who it talks to	The serial slaves: meters, drives, sensors, each with its own unit ID	Your SCADA, PLC, HMI or software, acting as the Modbus TCP client (master)
What you set in the node	Serial port, baud rate, parity, data bits, stop bits, and RTU or ASCII framing	The address and port to listen on, and how many clients may connect at once

Good to know

Every function code is forwarded, reads and writes alike. Writes only reach the slaves when Forward write requests is switched on; validation warns about it every time, because any client that can reach the port could then change the devices.
Unit IDs can be renumbered. If your client expects slave 1 but the meter is unit 17 on the bus, the Unit ID map translates. A unit ID that maps to nothing is answered with exception 0B (gateway target failed to respond), which is what a real converter box replies.
Several clients at once. Up to Maximum masters clients may be connected. A serial line can only carry one request at a time, so their requests are queued and sent one after another.
The gateway can still poll the same bus for itself. A source node on the same serial port and the converter share the line; the runtime queues the two so they never collide.

In the editor

The converter has no ports and no wires: it is a service the gateway runs beside the flow. Listen on and Listen port are what the Modbus TCP client connects to; the serial fields describe the bus behind it.

It needs a Professional licence, which a trial is. A design may hold only converters and no source at all: that is a converter appliance, a serial-to-Ethernet Modbus box built from an edge computer.

This is not the same as Modbus Server out. The converter forwards a client's requests to real serial slaves, register for register, and can carry writes. Modbus Server out serves the gateway's own tags, which may have come from any protocol, as a read-only register map of its own.

Test it with the Modbus Simulator

The Simulator can be the RTU slave. Put it on one serial adapter and the gateway's converter on another, the two wired together (a pair of USB-serial adapters and a null-modem cable, or a virtual pair: com0com on Windows, socat on Linux), same baud, parity and stop bits. Then connect the Modbus Client to the gateway over TCP, as the client (master), and read the Simulator's registers through it: the Simulator's request log shows the forwarded RTU frames arriving, and the Client shows the answers.

From design to device

Validate. On the design page, Run validation. The editor's rules, the tag document and the runtime binary itself check the design; every issue names its node. Details: Validating a design.
Install. From the Devices panel download the installer for the device's platform (Windows x64, Linux x64 or Linux ARM64). Windows: extract and run Edge-Gateway-Console.exe from an administrator terminal. Linux (Debian, Ubuntu, Raspberry Pi OS): sudo dpkg -i the .deb, then sudo edge-gateway-console. It shows the device code. Details: Installing on the device.
Device code. Enter it in the Devices panel, choose a trial or one of your purchased licences, and press Download activation bundle: one small zip with the design and a licence bound to that machine, sealed so only that machine can open it. Details: Downloading.
Bundle. Give the zip to the console (drag it onto the program, pass its path, or put it beside the program and run it again; a USB stick is fine for a device without internet). It opens the bundle with its own code, installs the runtime as a service and starts it. The device never contacts the site. Details: Activation and the licence.

The console then opens the gateway's web view in a browser (on a device without a desktop it prints the address instead) and stays attached with the live view: devices up or down, values as they change, what was published, and the log.

The live view shows the converter as listening, with the connected clients and the count of forwarded requests.
A Modbus TCP client that connects to the gateway's port reads the serial slaves as if they were Modbus TCP devices, by unit ID.

Ctrl-C leaves the gateway running as a service. Run edge-gateway-console again at any time: it shows the service, the licence, every device and destination with what to check, the web view, and the live log. Running covers the data directory, secrets and the diagnostics.