How To Architect Your Systems to Get the Most Out of Your Modbus Devices

In all likelihood, your automation applications forge ahead thanks to Modbus. It is also safe to say that this widely used industrial communications protocol, following a master-slave architecture, will remain the lifeblood of networks for a long time to come. Its two prominent formats—Modbus RTU and Modbus TCP (a modified version of the former)—work their magic in serial-based communications and Ethernet-based connections, respectively.
A number of reasons justify Modbus’s status as the de facto industrial communications protocol. Modbus RTU, specifically, is easy to install in field devices. Furthermore, it allows for easy troubleshooting that is not too costly. Modbus RTU’s cousin, Modbus TCP, is for the same reasons the marrow in Ethernet connections. The snag is that they have communications issues, and therefore need a mediator to smooth things out between them. So, network engineers are constantly scrambling for the right solution to ensure that all the serial devices can communicate with the SCADA host. This has become a pertinent issue as more and more serial devices are connecting to Ethernet networks.
Along with this issue of incompatibility, other challenges also come with the territory. The first challenge involves the vast array of proprietary SCADA software on the market. As each software program brings different supporting abilities for Modbus drivers, things become complicated for system operators to match the right product with their network’s requirements. Throwing them further off balance are continuous requests by multiple SCADA hosts to access the same Modbus RTU-supported device. In addition to all the foregoing, operators must also ensure a faster response time of devices in mission-critical applications.
In this article we will suggest solutions to these challenges. Most of the solutions involve embedding gateways in your network to make sure you get the most out of your serial devices.

The Link That Makes Things Tick
Right now, the marketplace is crowded with SCADA software offering different capabilities to support Modbus drivers. Therefore, you need to know beforehand exactly which SCADA software will be the perfect match for your system. In this section, we will briefly look at a few common scenarios.

• 1. A SCADA host with a Modbus TCP driver: A protocol conversion gateway is the most obvious solution here. A gateway will allow you to use Modbus TCP protocol to communicate with Modbus RTU-supported devices. When the gateway receives the Modbus TCP request, it converts the packet to a Modbus RTU packet and sends it to the Modbus RTU-supported devices immediately.

• 2. A SCADA host with a Modbus RTU-driver—without a built-in serial port: If you want to use your existing SCADA program and devices, but your original SCADA host does not have a built-in serial port, a serial device server can be used to build a virtual COM port for the serial port on the remote serial device server connected to your serial devices. This configuration allows you to access remote serial devices through the serial device server as if it had a native COM port. The serial device server will install the virtual COM port driver on your SCADA host to create a virtual COM port. To enable the virtual COM port, the serial device server must be configured to virtual COM mode. The data sent to this virtual COM port will be transferred to the remote serial port of the serial device server. Actions for the modem signal will also be handled in the same way. Since you can use the virtual COM port in the same way as a native local COM port, you can send the Modbus RTU request to the COM port directly, just as you would if it were a physical COM port. Read More >>

---

Virtual COM port: Acessing a remote serial device as if the SCADA host posseses a native COM port.

Read More