When designing and commissioning Modbus serial buses, we sometimes encounter situations where it makes sense to switch from a serial link to an Ethernet network and transmit data over it. These are in particular:
A serial line device, which may be an air conditioner or a fan coil controller, will be called a slave (in a network environment also a server) because it provides data for a Modbus query. The query is sent by a master (usually called a client in a network environment), such as a process controller (PLC), a graphic terminal (HMI), or a visualization program (SCADA) in a computer.
A wide choice of converters with two interfaces - Ethernet and RS485 - is available on the market. The question is, how they actually transmit data on the network. Upon closer examination, we find that there are more and differ in how data from the serial link is “packed” into network packets and interpreted at the other end. Even "unpacking" requires some hardware or software that must be supported on the other end of the line. The most commonly used modes are:
In the following, we will look at each mode in more detail and show specific examples of topologies and their advantages and disadvantages.
A virtual COM port is actually a software driver that is installed on a computer. The driver is supplied by the converter manufacturer, the converter is called terminal server.
There are many manufacturers of terminal servers and it is always necessary to use the driver supplied by its manufacturer. Communication protocols between the virtual COM port and the terminal server may vary.
In addition, the virtual serial port needs to be configured: we need to determine at least at what IP address the hardware converter will be found in order to establish a connection with it. However, other parameters of serial communication (speed, parity, number of stop bits…) are also important, which are then transferred to the converter and set as serial port properties. To do this, either the web interface of the converter or the menu in Device Manager - see above in Serial adapters with multiple ports.
On the network, the driver finds the converter from the serial line to the Ethernet, connects to it and opens the data transfer channel. Everything that programs in the PC write to the virtual port, is sent to the converter by the driver, and the converter sends the data to its serial port. Vice versa, data coming to the serial port are sent to the PC by the converter, where the driver writes it to the virtual COM port. The packet is usually closed and sent after some time of inactivity on the line, this time can be adjustable. The whole system does not care at all what kind of data is sent along the line, i.e. what the individual bytes mean. This is basically an advantage, the terminal server can theoretically be used to transmit any communication protocol. But there are a few snags, as we'll see below.
The network communication between the virtual COM port and the terminal server is manufacturer specific. Nowhere is standardized what the data transfer should look like; In addition to the serial data itself, control signals, commands for setting up the terminal server, etc. are also communicated over the network. The advantage of the terminal server is that the data transmission is usually encrypted so that it is not possible to intercept the communication between the program and serial devices over the network. It is also recommended - if possible - to set the terminal server so as to accept connections only from the IP address of the virtual COM port (or in the serial bridge connection from the IP address of the opposite terminal server), which enhances network security.
This solution looks simple and universal, but it has features that can significantly reduce its use:
There is a delay in transmission. In the case of direct interconnection of two serial devices, the packet delay is determined only by the signal propagation rate over the cable. However, in the case of a terminal server, it is necessary to take into account not only the time needed for data processing in the driver and the terminal server, waiting for the end of the packet (see above), but especially the delay in transmission in the network infrastructure. The total delay can be up to hundreds of milliseconds. This can be recognized by the client program as a timeout - communication error, leading to outages and error messages.
It is a fact that when operating in a local network, a delay problem usually does not occur: the response time in the network is in the order of milliseconds, while the timeout tolerance is adjustable in hundreds of ms. However, the assumption is that this is a request-response communication, such as the M-Bus protocol for reading energy meters. If we tried to connect like this two parts of a serial bus, which, for example, uses a collision detection communication protocol to access the line, it is unlikely to work properly.
It is a point-to-point communication. Only one virtual COM port or serial bridge counterpart can be connected to one terminal server. Of course, it has its reasons. If we want to access the server from two clients, it must also be allowed by the communication protocol, as we will see below. A terminal server is really just a tunnel to transfer data between two serial ports.
The client must be a PC with a suitable operating system to install the virtual COM port on it. If we have a PLC or other device on which the driver cannot be installed, we can use the following mode - serial bridge. The terminal server usually does not solve the situation when we do not have a serial port on the PLC, because "there is no way to get data through the PLC Ethernet port to the serial protocol driver in the runtime PLC".
For a device that has a free serial port, two back-to-back terminals can be connected and configured to create a transmission channel. This configuration is called a serial bridge because the serial link “bridges” the network and the serial devices can communicate with the PLC as if they were connected directly by the serial link. However, the timing problem described above exacerbates this. In addition, there are double hardware costs.
So finally we get to full routing:
This mode at the application level already works with the protocol we know, converting Modbus TCP to Modbus RTU and back. Unlike the Terminal Server mode, where Modbus RTU would still be packed (and possibly encrypted) in TCP packets on the Ethernet side, in the case of a Modbus router on the network interface, we find Modbus TCP. The converter therefore also solves protocol conversion and works with data at the Modbus protocol level. So it has to understand Modbus, it's no longer just "shifting anonymous data".
How does it work?
Modbus query and response on a serial line (called Modbus RTU) looks like this:
Temperature reading from register 17 with functions F03, station address 1
01 03 00 10 00 01 85 CF
01 03 02 07 9E 3B DC
Values are a hexadecimal representation of transmitted bytes. In this form, they are provided by a serial monitor, the so-called port monitor. This is either a client device function (PLC, SCADA) or an external program that monitors the bus operation via a serial converter.
If we disassemble the data according to the description of the Modbus protocol (which is not that difficult), we find the following:
|01||station address - line address in the range 1… 255, the device with this address is queried by the master for data|
|03||Modbus function 03 - Read multiple registers - method of data reading|
|00 10||starting address - 16 decimal for reading register 17 (addresses are numbered from 0, registers from 1), in which we know that the current temperature is available|
|00 01||the number of registers to read, one in this case|
|85 CF||at the end is the CRC - the checksum of the previous data|
|01||station address - the response is repeated as in the query|
|03||Modbus function 03 - in the response is repeated as in the query|
|02||number of bytes that follow (except the checksum)|
|07 9E||value: 079E hex = 1950 decimal = 19.5 ° C (in order to get decimal places, the integer value must be divided by 100 - this and more can be found in the Modbus table provided by the device manufacturer)|
|3B DC||at the end is the CRC - the checksum of the previous data|
The checksum should be used by each party as a telegram integrity check. If the received CRC does not agree with the actual calculation based on the previously received data, something has been transmitted incorrectly and the entire query needs to be repeated.
The same Modbus TCP query is a little more extensive. The picture shows the communication recorded in Wireshark. This is a program which can analyze some protocols down to the application level, as we can see in the middle part of the window. In the upper part there are two Modbus TCP queries and two answers, below is the detail of the second one.
The blue part of the telegram is the Modbus TCP query itself. We are only interested in the left, hexadecimal interpretation; in the right part are the same data as text, which does not make sense for Modbus. The black and white part at the beginning of the telegram is actually a transport envelope of the lower layers of communication, including the TCP / IP protocol. We could say that a cargo - a Modbus TCP telegram - loaded in a TCP / IP wagon - is traveling on the network. We will only deal with a part of Modbus TCP:
04 B7 00 00 00 06 01 03 00 10 00 02
04 B7 00 00 00 05 01 03 02 08 7E
We will analyze the telegram again according to the Modbus TCP standard.
|04 B7||transaction ID, usually an increasing number, is used by the client to match a query and a response|
|00 00||protocol identifier: 0 = Modbus, there are always zeroes in these two positions|
|00 06||the number of bytes that follows|
|01||station address (called unit identifier here)|
|03||functions (same as Modbus RTU)|
|00 10||register; 16 dec for reg. 17 (same as Modbus RTU)|
|00 01||number of registers to read|
|04 B7||transaction ID, taken from request|
|00 00||protocol identifier: 00 = Modbus|
|00 05||the number of bytes that follow|
|02||number of data bytes (seemingly redundant value, see third line, but it is there for full compatibility of this part of the telegram with Modbus RTU)|
|08 7E||08 7E hex = 2174 dec = 21.74 ° C, the temperature has risen somewhat during experimentation|
The lines in bold are common to both Modbus RTU and Modbus TCP. Modbus TCP is missing a checksum, which is unnecessary to calculate and transmit, because the integrity of the telegram is guaranteed by its "envelope" - the TCP protocol. On the contrary, there are the first three more lines: Transaction ID, protocol identifier, and the number of following bytes.
When converting a query from Ethernet to a serial line, the Modbus router takes pure content (transmitted data without TCP overhead) from the TCP telegram, removes the first six bytes, calculates and adds a checksum, and sends it all to the serial line. Upon receiving the response, it removes the checksum from the serial packet, adds the Transaction ID from the Modbus TCP query, the Protocol identifier and the number of bytes of the remainder of the telegram - and returns the Ethernet response as a Modbus TCP telegram.
This means that "behind the router" there is a serial line with one or more serial devices. We can communicate with several serial devices via one IP address of the Modbus router. We only need to know the bus configuration and set up the client program accordingly. The devices are connected according to the topology on the left.
When creating a topology, we must always be aware of which device is the server and which is the client. In the figure to the right there is a seemingly similar connection, "Modbus device with serial link - Modbus router - Modbus device with Ethernet interface", but the router functions differ significantly. Connection according to the picture on the right will be discussed in the next part of the article, now we are interested in a serial device as a slave.
If we have multiple serial lines in the system with multiple modbus routers, their link address ranges may overlap. The Modbus device is uniquely determined by the combination of the router's IP address and the device's link address. The Modbus TCP client will simply address each Modbus TCP device separately via its IP address. Thus, both addressing methods in the figure below are possible.
A number of parameters can be set in the Modbus router using the web interface or the configuration program. For example, for a Domat R035 router, it is necessary to determine at first that the device should work as a Modbus router. The converter must be set to Industrial Automation mode and in the Industrial Automation Settings section check that the current protocol is Modbus RTU Serial Slave. This corresponds to the topology in the picture on the upper left, the device on the serial line is slave (server). (The second option, Serial Master, is shown in the second part.)
In addition to network settings and serial line parameters (speed, parity…), this is actually the only configuration you need to enter in the router. Other parameters can be left in the default values. In the next section we will look at several cases of more complex topologies and their solutions.