Modbus Gateway

Getting Data Out of your Modbus Devices

History

Originally developed by Modicon in 1979, Modbus RTU (remote terminal unit) grew to become one of the most popular protocols for industrial field devices due to its ease of implementation and very low troubleshooting costs.

In 1999, the development of Modbus TCP (transmission control protocol) marked the official move onto the new 21st century communication highway—the Internet. A Modbus TCP device could now be connected over the Internet from anywhere in the world, performing maintenance and repair, reducing support costs, and improving customer service. As a result, many systems now use Modbus TCP in SCADA (supervisory control and data acquisition) software, the central system gathering and analyzing real time data from field devices which generally support serial protocols, such as Modbus RTUs.

While both formats essentially fulfil the same functions, Modbus RTU is used in serial communications (RS-232 or RS-485) while Modbus TCP facilitates communications over TCP/IP networks. By use of a gateway device, field devices supported by Modbus RTU can easily communicate over Modbus TCP to take advantage of the Internet.

The Modbus and Modbus TCP protocol specification and implementation guide are available for download at www.modbus.org/specs.

What is Modbus Gateway

Many industrial devices, such as PLCs (programmable logic controllers), DCSs (distributed control systems), HMIs (human machine interfaces), instruments, and meters, use Modbus RTU as their communication standard. Most of the time, these devices are in a different section of the facility than the SCADA system through which they must integrate. However, SCADA supports the Ethernet-based Modbus protocol (TCP), which is different from the original serial-based Protocols (RTU), and a Modbus gateway is needed as a bridge for integration.

A Modbus gateway is a serial-to-Ethernet device server that performs protocol conversion between Modbus RTU and Modbus TCP. It can integrate Modbus serial devices on an Ethernet network, or connect slave(s) to master(s) between serial and TCP.

Benefits of Modbus
Gateway

Conversion between Modbus protocols has traditionally been done through use of extension communication modules in the PLC. While they are reliable due to their location within the PLC, disadvantages exist, including:

  • High cost due to occupying space within expensive PLC memory.
  • Difficulty to input a PLC extension module, as users must be familiar with the characteristics of Modbus protocols and write PLC programs to correctly implement it.
  • Cannot be used in certain applications.

In addition to removing the need for users to write PLC programs for the Modbus, benefits of Modbus gateway include:

  • Moves data without restrictions on vendors.
  • Openly published and is royalty-free (low cost).
  • Developed with industrial applications in mind.
  • Easy to deploy and troubleshoot.
  • 123456789
  • 987654321

Modbus Gateway
Applications

There are many SCADA software providers, each offering different capabilities to support Modbus drivers. Knowing your system’s exact requirements is crucial to selecting the most suitable communication devices to integrate field devices.

While standard serial device servers can sometimes connect Modbus RTU devices to an Ethernet network, a Modbus gateway solution is always recommended since it can meet almost every system requirement. A designated gateway solution is required in the following situations:

Network Redundancy

Ethernet provides multiple connection access capabilities. Up to 32 SCADA hosts can simultaneously query the Modbus RTU-supported devices when using gateways. Most serial device servers don’t support multiple masters and cannot provide this network redundancy.

Single connection for multiple Modbus RTU devices

Ethernet provides multiple connection access capabilities. Up to 32 SCADA hosts can simultaneously query the Modbus RTU-supported devices when using gateways. Most serial device servers don’t support multiple masters and cannot provide this network redundancy.

Simultaneous device access for Modbus RTU HMI and Modbus TCP SCADA

When you want to keep the existing HMI connections but the only available serial port on the device is already connected to a gateway, some gateways provide a serial port redirector to overcome this obstacle. The serial port redirector is very similar to a router in that the gateway can transfer the request between different serial ports based on the slave ID.

Modbus Gateway
Application Challenges

There are three major challenges when integrating Modbus-supported devices to SCADA systems:

  1. Dispatching a large number of Modbus serial devices over a TCP-connected architecture.
  2. Multiple SCADA hosts needing to access the same Modbus RTU-supported device.
  3. Ensuring a faster response time for mission-critical applications.

Dispatching a Large Number of Modbus Serial Devices

Managing a large number of network connections and planning the architecture of TCP connections can be extremely time-consuming and is one of the biggest pain points in setting up a Modbus system.

Traditionally, each Modbus gateway has one port that can handle 31 Modbus RTU slaves. If a large number of devices is needed to be monitored, you would need to install one Modbus gateway for every 31 devices. The installation process involves finding multiple different locations, power sources, and TCP connections. In addition, the multiple gateways would have to be configured and maintained separately

To solve the issue, some manufacture introduced 8-port and 16-port gateways, with each port capable of connecting to 31 Modbus RTU slaves, greatly increasing the number of devices that can be connected to just one gateway.

While this solution enabled each serial port to be configured to associate with either a TCP port or IP address, TCP connections were still required and there was no way to automatically track which devices were associated with each TCP port or IP address.

To tackle the massive TCP connections need for massive deployment, a slave ID routing table is developed on some advanced Modbus gateways. This type of gateway allows users to track which slave ID is on each serial port by manually mapping the connections during setup. When a gateway receives a Modbus request for a specific device, it can dispatch this request via the slave ID routing table to the serial port that connects to the target Modbus device. The slave ID routing table also makes it easier to manage Modbus serial slave devices by reducing the required number of TCP network connections (and associated fees) to just one connection.

While the routing table is a significant improvement over traditional Modbus gateway configurations, manually creating and managing the table in a large deployment project can still be challenging and laborious. To tackle this challenge, an industrial communication manufacture, Moxa Technologies, has further developed an application, Auto-Device Routing (ADR), that automatically creates the slave ID routing table with just one click. ADR, featured in the Moxa advanced Modbus gateways, receives incoming SCADA requests and automatically detects which serial ports are connected to the target device. ADR then sends the request to the correct serial port. The automatic creation of the slave ID routing table significantly reduces time for ID mapping and maintenance, and makes it much easier to add new serial devices to the system.

Multiple Host to Monitor Multiple Modbus Serial Devices For large projects, multiple hosts could monitor a territory, as well as act as a redundant host to monitor devices in other territories when required. Therefore, Modbus RTU-supported devices need to be connected to multiple masters to allow simultaneous access.

Although a gateway can adequately handle this, the serial port bandwidth will stay the same. If multiple requests are received through the same serial port, there will likely be a delay due to the requests already in the queue. Proper polling time must be calculated if you want to enable multiple masters to simultaneously access the same Modbus RTU-supported device.

To solve this challenge, a high-density agent gateway which can act as a Modbus Master, actively and continuously retrieving data from connected devices is developed. The retrieved data is stored in internal memory, which is then used to reply to host requests. Since the requests will not all have to go through the same serial port, there will be no delay. In addition, there will be less error due to time-out from requests in a busy Modbus network.

Although using an agent gateway is faster and more efficient, keep in mind the data retrieved may not be the most current in real-time.

Ensuring a faster response time for mission-critical applications

Some critical applications require fast, real-time responses from devices. When multiple Modbus RTU-supported devices are connected, speed can be greatly diminished. This reduction is due to Modbus behavior (one polling with one response) and the speed limitation of serial transmissions. The development of agent gateway is also intended to address this need.

An agent gateway features two mode options, agent mode and intelligent mode. In agent mode, users can manually configure the Modbus gateway to poll data based on user-defined commands. In intelligent mode, the Modbus will learn and remember commands that it frequently receives from SCADA, and automatically use them to poll the data. Intelligent mode requires the least amount of configuration and is the easiest to maintain.

A high-density Modbus gateway with agent or intelligent mode enabled can send a Modbus command to each Modbus RTU-supported device one by one, enabling it to actively retrieve data from multiple Modbus RTU-supported devices and place them into a single register, storing the data in its internal memory. Therefore, to get a faster response, the host just needs to retrieve data through an Ethernet connection. All of the data can be simply arranged into a single data block in the gateway’s internal memory to be easily retrieved from the host with just one Modbus read command.

Final Thoughts

Although there are many challenges that communications engineers face while setting up a Modbus system to quickly and efficiently communicate with SCADA, advanced gateways nowadays alleviate many of the common pain points. With intuitive features such as the slave ID routing table and auto-device routing, adding and communicating with devices can be as easy as a single click. In addition, gateway can act as an agent to ensuring field devices response time in a large Modbus network.

After many decades of technological advancements, the future of Modbus Gateway is finally here to revolutionize the way we control, monitor, and connect all of field devices.

Scroll To Top