Modbus RTU to TCP Gateway Setup Guide

Why Use a Modbus Gateway

Modbus RTU was designed in 1979 for direct serial communication over RS-485. It works well on short bus segments connecting a master controller to field devices—energy meters, VFDs, temperature sensors, valve actuators. The problem is that modern building automation supervisors and IP-based SCADA platforms speak Modbus TCP, not serial. They have Ethernet ports, not RS-485 terminals.

A Modbus RTU to TCP gateway sits between the IP network and the RS-485 bus, translating protocol frames in both directions. The supervisor sends a Modbus TCP request to the gateway's IP address on port 502. The gateway converts that request into a Modbus RTU frame—adding the CRC-16 checksum and stripping the MBAP header—then transmits it over the serial bus. When the RTU slave responds, the gateway reverses the process and sends the reply back over TCP.

Without a gateway, integrating legacy RTU devices into an IP-based BAS requires replacing every field device with a TCP-capable model (expensive and disruptive) or running dedicated serial connections from each controller (which limits supervisory access). A gateway preserves the existing RS-485 infrastructure while exposing every slave device to any Modbus TCP client on the network.

Gateway Types: Hardware vs Software

Gateways fall into two categories: purpose-built hardware appliances and software running on general-purpose computing platforms. Both perform the same protocol translation, but they differ in reliability, cost, and suitability for production BAS environments.

Hardware Gateways

Dedicated hardware gateways are the standard choice for production building automation installations. These are small DIN-rail or panel-mount devices with an Ethernet port on one side and one or more RS-485 (or RS-232) serial ports on the other. They run embedded firmware purpose-built for Modbus protocol conversion.

• Moxa MGate MB3170 / MB3270 — One- and two-port gateways supporting up to 16 simultaneous TCP master connections. Web-configurable. Widely deployed in BAS and industrial settings.
• HMS Networks Anybus AB7702 — Transparent gateway supporting up to 32 RTU slaves with web-based configuration.
• AutomationDirect MB-GATEWAY — Single-port RS-422/485 to Ethernet gateway supporting up to 12 TCP connections and 128 RTU devices.
• Advantech EKI-1200 Series — One-, two-, and four-port Modbus gateways with DIN-rail mounting.

Hardware gateways are preferred for production environments because they boot in seconds, have no operating system to patch, tolerate power cycling without filesystem corruption, and operate reliably in mechanical room temperatures (typically −10°C to 60°C).

Software Gateways

Software gateways run as applications or services on a Linux or Windows host that has both an Ethernet interface and a USB-to-RS-485 adapter. They are useful for lab testing, prototyping, and low-budget installations where a dedicated hardware gateway is not justified.

• mbusd — Open-source (BSD license) Modbus TCP to RTU gateway for Linux. Small footprint suitable for single-board computers. Presents RTU slaves as a single TCP endpoint. Available on GitHub (3cky/mbusd).
• diagslave — Free Modbus slave/server simulator for Windows and Linux. Useful for testing gateway configurations before connecting production devices.
• ESP32-based firmware — Open-source projects (zivillian/esp32-modbus-gateway, budulinek/arduino-modbus-rtu-tcp-gateway) turn an ESP32 with a MAX485 transceiver into a low-cost gateway configurable via a built-in web interface.

The key risk with software gateways in production is uptime. A Raspberry Pi running mbusd works until the SD card wears out or the OS needs a security update that breaks the serial driver. For permanent installations supporting critical HVAC or metering systems, hardware gateways are the safer choice. Reserve software gateways for development, commissioning, and non-critical monitoring.

Selecting a Gateway

Choosing the right gateway depends on the number of serial ports needed, concurrent TCP master connections, the physical environment, and budget.

One critical distinction: some gateways operate as transparent protocol converters (the TCP request passes straight through to the serial bus), while others act as Modbus TCP servers with an internal register cache that polls RTU slaves independently. Transparent gateways are simpler. Caching gateways improve performance when multiple TCP masters poll the same slave data, but they add configuration complexity and can serve stale data if the cache refresh rate is too slow.

Configuration Steps

The following steps apply to most hardware gateways. Specific menu labels vary by manufacturer, but the parameters are universal.

Step 1: Assign a Static IP Address

Connect the gateway to your workstation via Ethernet. Access the web interface—most ship with a factory default IP such as 192.168.1.1 or 192.168.127.254. Assign a static IP on the BAS VLAN. Do not use DHCP for production gateways—if the lease expires, the supervisor loses contact with every RTU device behind the gateway.

Step 2: Configure the Serial Port

Set the serial parameters to match every RTU slave device on the bus. All devices on a single RS-485 segment must share identical settings:

# Serial port configuration - must match all RTU slaves
# -----------------------------------------------
# Baud rate:    9600 | 19200 | 38400 | 57600 | 115200
# Data bits:    8
# Parity:       None | Even | Odd
# Stop bits:    1 | 2
#
# Most common BAS field device default: 9600 baud, 8N1
# Modbus specification default:          19200 baud, 8E1
#
# Serial mode:  RS-485 2-wire (half-duplex) for most BAS installations
#               RS-485 4-wire (full-duplex) only if all slaves support it

Step 3: Set the Modbus TCP Port

The standard Modbus TCP port is 502. Leave this at the default unless your network security policy requires a non-standard port. If you change it, every Modbus TCP client that connects to the gateway must be configured with the matching port number.

Step 4: Configure Response Timeout

The gateway needs two timeout values: the serial response timeout (how long it waits for an RTU slave to reply) and the TCP idle timeout (how long it holds a TCP connection open without activity). Set the serial response timeout to at least 500 ms. Older energy meters and VFDs may need 1,000 ms or more. If the serial timeout is too short, the gateway returns exception code 0x0B (Gateway Target Device Failed to Respond) even though the slave is healthy.

# Timeout configuration
# -----------------------------------------------
# Serial response timeout:  500-1000 ms (start at 1000 ms, reduce after testing)
# TCP idle timeout:          60 s (default on most gateways)
# Inter-request delay:       50-100 ms (required by some slower RTU slaves)
#
# Rule: TCP-side timeout > serial response timeout + bus turnaround time
# If the TCP master times out before the gateway finishes the serial
# transaction, the master sees a communication failure even though
# the gateway and slave are communicating correctly.

Step 5: Verify Connectivity

Before connecting the BAS supervisor, test with a standalone Modbus TCP client. Modbus Poll (Witte Software) or QModMaster (open-source) can send requests to the gateway's IP and display responses. Read a known register from a known slave—if the value matches the device's local display, the gateway is translating correctly.

Slave ID Mapping

In the Modbus TCP frame, the Unit Identifier field (byte 7 of the MBAP header) tells the gateway which RTU slave to forward the request to. The gateway uses this value as the slave address in the outgoing RTU frame.

In most transparent gateways, the mapping is direct: Unit Identifier 1 routes to RTU slave address 1 on the serial bus. Unit Identifier 5 routes to slave 5. No additional configuration is needed. This is the simplest and most common setup in BAS installations.

Some gateways support configurable ID mapping, where you remap Unit Identifiers to different slave addresses. This is useful when two RTU buses behind separate serial ports have devices with overlapping addresses. For example, if Bus A and Bus B both have a device at slave address 1, you could map TCP Unit Identifier 1 to Bus A slave 1 and TCP Unit Identifier 101 to Bus B slave 1.

# Slave ID mapping examples
# -----------------------------------------------
# Transparent (default on most gateways):
#   TCP Unit ID 1  -->  RTU Slave 1  (serial port 1)
#   TCP Unit ID 2  -->  RTU Slave 2  (serial port 1)
#   TCP Unit ID 10 -->  RTU Slave 10 (serial port 1)
#
# Remapped (multi-port gateway with overlapping slave addresses):
#   TCP Unit ID 1   -->  Serial Port 1, RTU Slave 1
#   TCP Unit ID 2   -->  Serial Port 1, RTU Slave 2
#   TCP Unit ID 101 -->  Serial Port 2, RTU Slave 1
#   TCP Unit ID 102 -->  Serial Port 2, RTU Slave 2
#
# Important: Unit ID 0 in Modbus TCP is a broadcast address.
# Most gateways forward it to RTU slave address 0 (broadcast,
# write-only, no response expected). Do not use Unit ID 0
# for read requests - the gateway will never return a response.

In your BAS supervisor or SCADA master, the "slave address" or "device address" field in the Modbus TCP driver corresponds to the Unit Identifier. Set it to match the RTU slave address of the target device (or the remapped ID if using a mapping table). If this value does not match an actual slave on the bus, the gateway returns exception code 0x0B (Gateway Target Device Failed to Respond) after the serial timeout expires.

Common Gateway Mistakes

1. Confusing Modbus TCP conversion with RTU-over-TCP tunneling. Some gateways and serial-to-Ethernet converters offer a "raw TCP" or "virtual COM port" mode that tunnels raw Modbus RTU frames (including the CRC-16) inside TCP packets. This is not the same as Modbus TCP. A Modbus TCP client expects an MBAP header and no CRC. If the gateway is in tunnel mode, the TCP client receives frames it cannot parse. Always verify that the gateway is configured for true Modbus TCP protocol conversion, not serial passthrough.
2. Setting the TCP-side timeout shorter than the serial-side timeout. The gateway needs time to transmit the request on the RS-485 bus, wait for the slave to process it, receive the reply, and convert it back to TCP. If the TCP master's timeout expires before the gateway completes this round trip, the master logs a communication failure even though the slave responded correctly. As a rule, set the TCP master's timeout to at least twice the gateway's serial response timeout.
3. Using DHCP for the gateway's IP address. When the DHCP lease expires and the gateway obtains a new address, every Modbus TCP master pointing to the old IP loses connectivity. This cascades into BAS alarm storms and data gaps in trend logs. Always assign a static IP or use a DHCP reservation tied to the gateway's MAC address.
4. Forgetting to match serial parameters to the RTU bus. The gateway's serial port settings (baud rate, parity, data bits, stop bits) must match every slave device on the bus. A mismatch in any parameter means the gateway's RTU frames are garbled from the slaves' perspective. The gateway will report exception code 0x0B for every poll because no slave can decode the request. This is the single most common commissioning error.
5. Polling too many registers too fast through a single serial port. A serial bus at 9600 baud can move roughly 960 bytes per second. A single Modbus RTU transaction (request plus response) to read 10 holding registers takes approximately 30–50 ms depending on turnaround delay. If the TCP master sends 50 requests per second to 20 different slaves, the gateway queues the requests and serves them sequentially on the serial bus. Requests at the back of the queue time out before the gateway can process them. Reduce polling frequency, read multiple contiguous registers in a single request where possible, or split the load across multiple serial ports.

Platform Compatibility

Any BAS platform or SCADA system that supports Modbus TCP as a client can communicate through a gateway to reach RTU slaves. The gateway is invisible to the supervisor—it appears as a standard Modbus TCP server at a particular IP address.

In all cases, the key settings are the gateway's IP address, TCP port (usually 502), Unit Identifier (matching the RTU slave address), and the register addresses from the slave device's documentation. The gateway does not change register addresses or data types—it is a transparent pass-through at the application layer.

Source Attribution

The technical guidance in this entry is informed by the following sources:

• HMS Networks — Anybus Modbus RTU to TCP Gateway Product Documentation
• Moxa — MGate MB3170/MB3270 Modbus TCP Gateway Series
• AutomationDirect — Modbus Gateways Product Overview and MB-GATEWAY Documentation
• mbusd — Open-Source Modbus TCP to Modbus RTU Gateway (GitHub)
• Arduino Modbus RTU to TCP Gateway — Open-Source ESP32/Arduino Gateway with Web Interface (GitHub)
• control.com Forums — Discussion on Modbus TCP Unit Identifier and Gateway Slave ID Mapping
• Modbus Organization — Modbus Application Protocol Specification V1.1b3
• Continental Control Systems — Modbus Message Timing Reference