Scribd
Upload
9 views

Architect Systems Modbus Devices

Uploaded by

WERMER MORA
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
9 views

Architect Systems Modbus Devices

Uploaded by

WERMER MORA
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

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.
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:

1. Multiple masters or redundancy: In addition to enabling remote access, Ethernet connections also
provide multiple connection access capabilities. Most gateways can support up to 32 connections, which
means up to 32 SCADA hosts can query the Modbus-RTU supported devices simultaneously. Although
it will be difficult for a serial device server to provide network redundancy in this situation, as most
serial device servers do not support multiple masters, a gateway, on the other hand, will have no
problem.
2. Simultaneous device access for old Modbus RTU HMIs and new Modbus TCP SCADA systems:
Although Ethernet connections offer easy-to-deploy remote access, there may be times you want to keep
your existing local HMI connections active. The problem is the serial port on the device is already
connected to a gateway, so there is no available serial port for the HMI connection. In this situation,
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.
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.

You might also like