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.
Virtual COM port: Acessing a remote serial device as if the SCADA host posseses a native COM port.
Although serial device servers can also connect Modbus RTU devices to an Ethernet network, a gateway solution can meet almost every system requirement. Your host must be able to support Modbus TCP connections. This shouldn’t be a problem since Modbus TCP, as stated earlier, is very popular and already widely supported. Here are a few situations where you will need to use a designated gateway solution:
A serial port redirector keeps local HMI connections active even when new Modbus TCP SCADA systems are added.
All Access Pass
In projects with a big scope, several 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 handle this adequately, you need to remember that the serial port bandwidth stays the same. If multiple requests are received through the same serial port, you will likely experience a delay because the gateway needs to handle the earlier requests in the queue first. This means you need to calculate the proper polling time if you want to enable multiple masters to access the same Modbus RTU device simultaneously. For example, if one request takes 100 ms, five multiple connections would require you to wait at least 100 ms ×(5 − 1) = 400 ms before sending the next request. This means each SCADA host will need to use 400 ms (plus some tolerance) for polling cycle time.
The above offering is not the only solution. Some gateways support an agent mode, which actively and continuously retrieves data from connected devices. The updated data is stored in internal memory, which is used to reply to host requests. Although this solution is faster and more efficient, the data retrieved might not be the most current.
Send in the Agent
For some critical applications, it is vital to have fast responses from devices. However, due to Modbus’s one-polling-with-one-response behavior and the limited speed limitation of serial transmissions, speed is lacking when multiple Modbus RTU-supported devices are connected. In these cases, an agent gateway is needed. An agent gateway can send a Modbus command to each Modbus RTU-supported device one by one, so it can actively retrieve data from multiple Modbus RTU-supported devices and place them into a single register, storing the data in its internal memory. Thus, to get a faster response, the host just needs to retrieve data through an Ethernet connection. Besides, all the data can be arranged into a single data block in the gateway’s internal memory to retrieve data from a host with just one Modbus read command.
About Moxa’s Solutions
Moxa is the industry leader in serial-to-Ethernet connectivity. NPort® serial device servers support different operation modes, including Real COM Mode, TCP Client Mode, and UDP Mode, to control the way your serial devices connect to a network. Moxa’s MGate™ gateways enable protocol conversions between SCADA/PLC and devices with different protocols. Standout features that set MGate™ gateways apart from others in the industry include easy configuration with a user-friendly web console, easy maintenance with built-in monitoring and diagnostics, and reliable performance. To learn more about our solutions, download our brochure.
|Copyright © 2016 Moxa Inc. All rights reserved.|