FAQs

Question:

To connect Modbus RTU serial devices to an Ethernet network, do I need a specific protocol conversion gateway? Or can a serial device server achieve the same result?

Answer:

Before answering this question, you have to know which Modbus driver on the SCADA host you want to use. There are four possible options:

(1) SCADA host with Modbus TCP driver,

(2) SCADA host with Modbus RTU driver – with built-in serial port,

(3) SCADA host with Modbus RTU driver – without built-in serial port,

(4) SCADA host with “Ethernet Encapsulation” driver

Question:

If I have more than one Modbus RTU device connected to different serial ports on a gateway, how do I plan the TCP connection architecture? Can I use a single connection, or do I need to use a separate connection for each serial port?

Answer:

Most gateways provide flexible solutions that can be used to plan TCP connection architecture for more than one Modbus RTU device connected to different serial ports of the gateway. In general, there are three different methods you can use that are based on the routing mechanism:

(1) Link serial port to unique TCP port,

(2) Link serial port to unique IP address, and

(3) Use routing table.

Question:

How do I use a gateway to allow multiple SCADA hosts to access the same Modbus RTU devices simultaneously?

Answer:

Although the gateway can handle this properly, remember that the serial port bandwidth stays the same. So 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. That means you need to calculate the proper polling time if you want to enable multiple masters to access the same Modbus RTU device simultaneously.

Question:

I have two working Modbus master devices (PLC or HMI). How do I exchange the data between these two systems?

Answer:

In order to exchange data between two Modbus master devices, you need a gateway that can support master-master mode. In this mode, the gateway will work as the slave for both sides. One master can write the data to the internal memory of gateway, and another master can get the data to achieve the data exchange. Depending on the gateway you use, you can have both sides support Modbus RTU and Modbus TCP, or just Modbus RTU on one side and Modbus TCP on the other.

Question:

I have multiple Modbus RTU devices I need to query. I can use multiple Modbus commands to read all the register data but it takes too much time. Is it possible for the gateway to retrieve the data actively and put them into single register so I can just use one Modbus command to retrieve all the data?

Answer:

In order for the gateway to actively retrieve data from multiple Modbus RTU devices and place them into a single register, you need an agent gateway to store the data in its internal memory. The gateway also needs to send a Modbus command to each Modbus RTU device one by one. All the data will be arranged into a single data block on the gateway’s internal memory for you to retrieve with just one Modbus read command.

A “serial device server” is a standalone device that has at least one Ethernet port and one or more serial ports. Serial device servers are equipped with an embedded network operating system and allow computers to access serial devices over a network. A serial device server can transfer data transparently between serial interface and Ethernet interface, converting all serial data received for Ethernet protocol communications, as well as converting all Ethernet data received for serial protocol communications. Modern serial device servers can also provide a “virtual COM port” for host computers that lack an extra serial port, essentially converting an Ethernet port to a COM port. Besides these basic functions, more sophisticated serial device servers can even support PPP in serial or Telnet protocols over Ethernet networks. A serial device server can even be used for console management (which is why some vendors may call it a “console server”) or remote terminal applications in old banking systems (which is why it also sometimes called a “terminal server”).

A “virtual COM port” is not a “real” (i.e., physical) COM port on the host computer. Instead, a “virtual COM port driver” program under Windows is installed on the host computer to completely emulate the behavior of a local COM port. The driver is used for ports on a serial device server that connects to the host via a TCP/IP network. The serial port on the remote serial device server will exhibit the same behavior as a local COM port. This “virtual COM port” is configured to link to a serial device server. For example, COM3 is serial port 1 on a remote serial device server that has an IP address of 192.168.2.1. So when you write data to this port, all data will be sent to “192.168.2.1@serial port 1” by “virtual COM port driver”. All the requests to this virtual COM port will be re-directed to “192.168.2.1@serial port 1”. Because newer host computers often lack built-in serial ports, “virtual COM ports” are an invaluable tool for connecting legacy equipment in industrial automation.

A “transparent gateway” is the most basic way to use a Modbus gateway. Since Modbus RTU and Modbus TCP have the same PDU (Protocol Data Unit), and the only difference is the address field, it is easy for a gateway to transfer data between Modbus RTU and Modbus TCP. So when the gateway receives the Modbus TCP packet from the Ethernet network, it can simply replace the address field to fit Modbus RTU addressing and immediately send the packet to the serial port. When the gateway receives a reply from the Modbus RTU devices, it will reply to the Modbus TCP client.

An “agent gateway” provides another way to use a Modbus gateway to transfer the data between Modbus TCP and Modbus RTU. The agent gateway has its own internal memory to store data temporarily, and it will query the data from the connected devices continuously. When the SCADA driver query is received, the gateway will use the data stored on its internal memory to reply to the query. In this way, the gateway works as an agent to query device data actively. This feature can be used for protocol conversion where:

(1) The two protocols use different packet structure. For example, PROFIBUS and Modbus, EtherNet/IP, PROFINET, etc.

(2) The two protocols use different cycle times. Some protocols—such as PROFIBUS, PROFINET, and EtherNet/IP—exchange data within very short time cycles, which “transparent gateways” cannot accommodate.