Modbus TCP protocol is an industrial communication protocol that allows two or more devices to communicate with each other via an Ethernet network. ModbusTCP is actually the Modbus protocol (Or Modbus RTU) running over an Ethernet TCP/IP network.
Table of Contents
MODBUS AND MODBUS TCP
Every control engineer today has to understand the Modbus TCP protocol. However, it doesn’t mean the engineer needs to know every bit of the protocol. Instead, it’s better to understand Modbus TCP uses and setup.
In this post, we will touch on the fundamentals of the Modbus TCP protocol, and in the next post series, we will dive into the real uses of this industrial protocol.
To explain Modbus TCP, we have first to discuss his ancestor, the serial Modbus.
Introduction to Modbus
The Modbus protocol was created by a company called Modicon in 1979. It is initially developed for Modicon PLCs and industrial automation systems. It has since become an industry-standard method for transferring data between industrial control devices.
Over the years, Modbus RTU has become very popular, and even though today it is considered an outdated protocol, you can still find it in many applications.
On a Modbus network, devices communicate using a master-slave (client-server) approach constraint for only one device, the master (client), to initiate transactions.
The rest of the Modbus network devices act as slaves (servers) and respond with the desired action requested in the transaction, which can be sending the requested data back to the master.
Modbus TCP Protocol
Modbus TCP is basically the Modbus RTU protocol with a TCP interface running on Ethernet.
Like Modbus RTU, Modbus TCP operates on a client/server principle, but in this case, the client (master) initiates both requests and responses from a server (slave).
Any device can be a client or a server. Therefore, many devices are the same time clients and servers.
A network can bring together many clients. At the same time, several clients can send requests, many servers can respond, and a client can talk to various servers.
A server can simultaneously respond to several clients.
Furthermore, Ethernet directs and ensures data delivery to all the devices at the same time.
ModbusTCP protocol uses a 10 Mbps Ethernet standard to convey the entire structure of Modbus messages.
The Modbus TCP protocol offers fast communication to many devices in a single network. On a Modbus TCP/IP network, a device can be:
To establish connections and data exchange between devices, the Modbus TCP messaging service must provide a listening socket on port 502. It is important to note that the listening port 502 TCP is reserved for Modbus communications.
If the number of client and server connections exceeds the number of allowed connections (from 1 to 16), the oldest unused connection is shut.
Access control mechanisms can also be activated to verify that the IP addresses of remote clients are authorized. By default, IP addresses that the user does not configure are barred from access when the security mode is enabled.
A Modbus server module is responsible for receiving requests and implementing actions (reading and writing in particular) to respond to them. The execution of these actions is carried out in a completely transparent way for the application programmer.
Difference between Modbus TCP and Modbus RTU
The table below specifies the most impotent differences between Modbus RTU and Modbus TCP:
Serial RS485 - RS422 - 2/4 wire
Multi Clients (Master)
Multi Servers (Slave)
Limited, usually not more than 1000m
Unlimited with fiber and satellite
OSI Model for Modbus TCP
To better understand how Modbus TCP/IP is structured, we need to review the Open Systems Interconnect (OSI) Model:
The top layers, 5-7, are usually united to form the fifth layer, the Application layer. When Modbus is stated as the application layer, we get the Modbus TCP.
The first four layers are the same for every Ethernet-based protocol.
There are a few protocols in the application layer, For example, FTP, DNS, SMPT, HTTP, and more. Each one of these protocols has its specific purpose. For Modbus TCP, the primary application layer protocol of interest is Modbus.
Modbus functions operate on memory registers to monitor and control devices on the network. Menufecterurs of Modbus devices usually publish a Register Map. Before trying to communicate with a device, you should refer to the register map for the specific device to understand its operation.
Modbus data model structure consists of four basic data types:
- Discrete Inputs – 0xxxx
- Coils (Outputs) – 1xxxx
- Input Registers (Input Data) – 3xxxx
- Holding Registers (Output Data) – 4xxxx
The service request (Modbus Protocol Data Unit) comprises a function code and additional data bytes, depending on the function. In most cases, the additional data is usually a variable reference, such as a register address, as most Modbus functions operate on registers.
Modbus Functions & Registers
The client (master) provides the server (slave) with additional information required by the slave to complete the operation specified by the function code. The request data typically includes register addresses, offset values, and data to be written.
- Read Coil Status (01) – This command will read the ON/OFF status of discrete outputs or coils (0xxxx reference addresses) in the slave/server.
- Read Holding Registers (03) – Reads the binary contents of holding registers (4x reference addresses) in the slave device.
Read Input Registers (04) – This command will read the binary contents of
- Input registers (3x reference addresses) in the slave device.
Force Single Coil (05) – Forces a single coil/output (0x reference address) ON or OFF.
- Preset Single Register (06) – This command will preset a single holding register (4x reference address) to a specific value.
Force Multiple Coils (15) – Simultaneously forces a series of coils (0x reference address) either ON or OFF.
- Preset Multiple Registers (16) – Presets a block of holding registers (4x reference addresses) to specific values.
- Report Slave ID (17) – This command returns the model, serial, and firmware.
For a function to work, one must specify the starting register and quantity of registers to be read/write.
When the server device responds to the client, it uses the function code to indicate either a normal response or an exception response if an error has occurred.
A normal response simply echoes the original function code of the query, while an exception response returns the original function code with its most significant bit set to ‘1’.
Modbus TCP/IP ADU Format
The Modbus protocol defines the PDU (Protocol Data Unit), independent of other communication layers. The Encapsulation of the protocol Modbus over TCP / IP introduces an additional field (MBAP Header) at the unit level of application data or ADU (Application Data Unit).
The client (who initiates the Modbus transaction) builds the ADU. In the same way, the Function field PDU code indicates to the server the action to take.
Upon receiving a client request, the server analyzes the MBAP header of the Modbus ADU. If this corresponds to a Modbus header, a Modbus transaction is instantiated.
When the maximum number of simultaneous transactions allowed exceeds, the server constructs an exception response (Exception Code 6: Server Busy).
Otherwise, a transaction is instantiated and initialized with the following information:
- the identifier of the TCP connection used (provided by the TCP module Management).
- The Modbus transaction ID is contained in the MBAP header.
- The Unit Identifier is also contained in the MBAP header.
Then, it is the turn of the PDU field to be analyzed. The server is ready to perform the requested service if this is recognized as a valid field.
Once the request has been processed, the Modbus server builds a response that must be sent to the TCP Management module.
Depending on the treatment outcome, two types of responses are possible: a positive response or an exceptional response, whose objective is to provide the customer with information concerning the detected errors while processing the request.
The PDU of the Modbus response must be prefixed with an MBAP header built from the information stored when receiving the request: Unit Identifier, Protocol Identifier, and Transaction Identifier.
The server also provides information, the “Length” field, indicating the length of the PDU + Unit Identifier field. Finally, the Modbus response is sent to the client.
Upon receiving the response, the Modbus client uses the Transaction Identifier to find the corresponding request sent over the TCP connection. The response is ignored and discarded if this does not match any query known to the client.
Otherwise, the Modbus client analyzes and uses the response to build the confirmation, which will then be sent to the application.
The response analysis consists of checking the MBAP header and the PDU of the response Modbus. Suppose this comes from a Modbus server directly connected to the TCP / IP network.
In that case, identifying the TCP connection is sufficient to identify the remote server without ambiguity. Thus, in this case, the Unit Identifier is not meaningful and should be ignored.
On the other hand, if the server is connected to a network, and the response comes from a router, the Unit Identifier (which in this case will not be equal to 0xFF) must be taken into account for the identification of the server by the client.
Regarding the PDU analysis of the response, the client checks the compliance of the Function Code as well as the format of the reply.
We discussed the most impotent technical features of ModbusTCP, but as we stated at the beginning, you will not need to implement the protocol in most cases. You only need to understand its basics and use it to connect a device to a Modbus TCP network.
Therefore, in the post Learn ModbusTCP With Examples, we will show a few real-world applications of ModbusTCP.