Engineers are painstakingly aware of the high stakes involved when planning the topology of a Modbus-RTU-to-Modbus-TCP network. It is especially in networks that consist of a large number of Modbus serial devices that things can go wrong, such as connectivity errors at field sites. What’s more, nothing is more discouraging than hours of dedicated planning coming undone in the field.
To engineers, spending too much time and effort on planning a Modbus network’s topology and segmenting devices into subgroups is already counter-productive. The most taxing part of the job is the monotony of keying in hundreds of Modbus slave IDs to set up each gateway’s Modbus slave ID routing table, which lists the connections of Modbus devices (Modbus slave IDs) to specific serial ports on a gateway. Thus, it is no surprise that engineers wish for solutions that save valuable time when setting up multiple Modbus gateways.
For engineers, the ideal situation would be just to send out Modbus requests to a Modbus gateway, and the latter would automatically find the correct serial port that connects with the target Modbus device. The development of such solutions is especially relevant now in the era of the Industrial Internet of Things (IIoT) where a large number of serial devices are migrating to Ethernet-based networks.
Managing a large number of Modbus devices
A key challenge of setting up a Modbus technology is determining the number of gateways needed to transmit data between a large number of Modbus devices and the supervisory control and data acquisition (SCADA) systems. Multiport Modbus gateways are more adept than one-port gateways at managing a large number of Modbus devices. For example, one 16-port Modbus gateway can replace 16 one-port Modbus gateways. For applications where space and budgets are issues, using a multiport Modbus gateway is ideal, as more physical space becomes available and less money is spent, only one power cable and one Ethernet cable are required, and fewer devices need to be configured and managed. Furthermore, the large number of IP addresses needed for 16 one-port gateways can be consolidated into a single IP address. For SCADA systems, another benefit is lower connection fees as they are normally charged according to the number of connections to the system.
However, engineers first need to segment all these devices into groups and then connect them to a specific port on the gateway. This why a well-created Modbus slave ID routing table for a gateway’s serial port is so important, but creating this routing table is time-consuming. Two types of routing mechanisms—both very intricate—address the different requirements in Modbus-based networks.
Routing by an IP address or TCP port
Some Modbus gateways perform serial port mapping via an IP address or TCP port. This mechanism is suitable for engineers who want to monitor field devices in segments. All the Modbus slave devices that are connected to the same serial port through daisy-chain wiring correspond with a specific IP address or TCP port. That is, each serial port corresponds with a unique IP address or TCP port.
A drawback is that engineers have to manually configure as many IP or TCP connections as the number of serial ports in use. In large-scale Modbus environments, systems usually adopt a large number of multiport gateways, making configuration a time-consuming task—not to mention the extremely high connection fees involved. Furthermore, serial-port mapping with IP addresses or TCP ports needs to be manually maintained by an engineer, which requires the engineer to identify the serial port that a device is connected to, as well the corresponding IP address or TCP port.
Routing by using a gateway’s Modbus-ID routing table
For engineers who care about connection fees and don’t need to monitor devices in segments, a more popular option is using a Modbus slave routing table, whose main purpose is to indicate which Modbus device, is connected to which serial port on a gateway. Once a gateway receives a Modbus request for a specific Modbus device, it can dispatch this request via the referring Modbus slave ID routing table to the serial port that is connected to the target Modbus device.
However, creating as well as managing a Modbus slave ID is laborious. Engineers have to bundle the Modbus slave IDs into groups and then connect each group to a different serial port. For example, slave IDs 1 to 5 are connected to serial port 1, slave IDs 6 to 10 are connected to serial port 2, and so on. According to this method, engineers will have to set the routing rules 16 times for a 16-port Modbus gateway. The situation becomes much more tedious if serial port 1 , for example, is connected to ID 1, ID 6, and ID 11, and serial port 2 is connected to ID2, ID 7, ID 12, and so on, because engineers need to keep track of what IDs are connected to each port. Engineers will then have to set routing rules as many times as the number of Modbus slave IDs.
Just one click
A new patent-pending technology promises to make the lives of engineers much easier. This technology only requires a single click to help the gateway detect which serial port is connected to a target Modbus device, allowing it to automatically dispatch a Modbus request to the correct serial port. It automatically creates the routing table, saving significant time and costs as engineers no longer need to manually create the Modbus slave ID routing table, eliminating possible human error in the process. Furthermore, it eliminates the effort needed to double-check the actual connections at field sites.
The Auto-Device-Routing function is featured in Moxa’s MGate MB3000 Series, which consists of high-performance Modbus gateways with 2, 4, 8, or 16 serial ports. The MGate MB3000 Series also supports routing by IP address or TCP port. For more information, read our white paper on automating modbus gateway routing setup.