Modbus TCP Basics: A Beginner's Guide to the Industrial Network Protocol

With the rapid advancement of Industry 4.0 and the Internet of Things (IoT), industrial communication protocols are evolving from traditional serial communication, like Modbus RTU, to faster and more flexible Ethernet solutions. Modbus TCP (Transmission Control Protocol) is a key protocol in this evolution, bringing the simplicity and openness of the Modbus protocol into the modern network environment.

This tutorial is designed to systematically guide you from the ground up, helping you fully understand and master the core concepts of the Modbus TCP protocol, including the MBAP header, its differences from Modbus RTU, data exchange, and practical application techniques.

Whether you are a beginner or an engineer looking to solidify your foundational knowledge, this article will serve as a comprehensive guide to help you effortlessly navigate the use of Modbus TCP in industrial automation.

1. What is Modbus TCP?

Modbus TCP is a transmission mode within the Modbus protocol family that utilizes the standard TCP/IP network stack for data exchange over Ethernet lines. Unlike Modbus RTU, which is based on a Master-Slave model, Modbus TCP employs a Client-Server model. Typically, a Client device (such as a PC, PLC, or HMI) initiates requests, and one or more Server devices (like smart meters, I/O modules, or PLCs) respond to these requests.

The core advantages of Modbus TCP include:

• High Speed and Stability Based on Ethernet, it supports higher communication speeds and longer transmission distances via routers and switches.
• Easy Integration It uses standard TCP/IP networks, allowing for convenient integration with corporate IT networks to enable remote monitoring and data management.
• Multiple Client Access A single Modbus TCP server can simultaneously handle connections and requests from multiple clients.
• Open and Compatible The Modbus protocol is completely open and royalty-free, a benefit inherited by Modbus TCP, which enjoys widespread support.
• No T3.5 Limitation Unlike Modbus RTU, Modbus TCP does not need to account for the inter-frame silence time (T3.5) specific to serial communication, as the TCP/IP stack handles frame encapsulation and reliable transmission.

2. Physical and Network Layers: The Foundation of Modbus TCP

Modbus TCP relies entirely on standard Ethernet hardware and the TCP/IP protocol stack.

2.1 Ethernet

Ethernet is the most common network technology in Local Area Networks (LANs), providing the physical and data link layer foundation for Modbus TCP.

• Transmission Media Typically twisted-pair cables (like CAT5e, CAT6), but can also be fiber optics for longer distances and higher bandwidth.
• Connection Devices Various network devices are connected using hubs, switches, and routers.
• Transmission Rates Common speeds include 10 Mbps, 100 Mbps (Fast Ethernet), 1 Gbps (Gigabit Ethernet), and even higher.
• Topologies Common structures include star, bus, and others.

2.2 TCP/IP Protocol Stack

Modbus TCP operates at the application layer of the TCP/IP protocol stack.

• IP (Internet Protocol) Responsible for routing and addressing data packets to ensure they travel from the source to the destination address. Every Modbus TCP device requires a unique IP address.
• TCP (Transmission Control Protocol) Provides a reliable, connection-oriented byte stream service. It ensures that packets arrive in order, without loss or duplication, and handles flow control and congestion control. Modbus TCP typically uses the default port 502.

This network-centric nature of Modbus TCP allows industrial devices to seamlessly connect to existing corporate networks, facilitating data flow between different levels and greatly simplifying distributed control, remote diagnostics, and centralized management.

3. Modbus Data Model: Identical Data Structure to Modbus RTU

Modbus TCP uses the same core data model as Modbus RTU. This means that whether data is transmitted over a serial line or Ethernet, the internal data organization of the device remains the same. The Modbus protocol abstracts the device's internal data into four logically independent data tables with non-overlapping address spaces. Each table stores different types of data and has specific access permissions.

Important Notes

• PLC addresses are a common representation in industrial automation (1-based addressing), while Modbus protocol addresses are what's actually used in communication (0-based addressing). The conversion is Modbus Protocol Address = PLC Address - Base Address (e.g., 40001, 30001). For example, reference address 40003 corresponds to the protocol offset address 0x0002 (40003-40001).
• Coils and Discrete Inputs are bit-level operations, while Holding Registers and Input Registers are word-level (16-bit) operations.
• The address space for each table is independent. A coil at 0x0001 is completely different from a holding register at 0x0001.

4. Protocol Structure: The Modbus TCP Data Frame (MBAP Header)

The core difference between a Modbus TCP data frame and a Modbus RTU frame lies in its header structure and error-checking mechanism. Modbus TCP adds an MBAP (Modbus Application Protocol) header to the standard Modbus PDU (Protocol Data Unit) and removes the CRC check found in Modbus RTU.

4.1 Data Frame Format Overview

The structure of a Modbus TCP request/response message is as follows:

[MBAP Header] [Modbus PDU]
   7 Bytes        N Bytes

4.1.1 MBAP Header - 7 Bytes

The MBAP header is unique to the Modbus TCP protocol and is used to manage Modbus transactions in a TCP/IP environment.

[Transaction Identifier] [Protocol Identifier] [Length] [Unit Identifier]
       2 Bytes                2 Bytes           2 Bytes        1 Byte

• Transaction Identifier - 2 Bytes

  • Purpose Set by the client to uniquely identify a Modbus transaction (pairing a request with its response). The client sets a transaction ID when sending a request, and the server must return the same ID in its response. This is crucial for clients handling multiple simultaneous requests.
  • Range 0x0000 to 0xFFFF. Clients typically increment this value for each new transaction.
  • Byte Order Big-Endian.

• Protocol Identifier - 2 Bytes

  • Purpose Identifies the Modbus protocol. For Modbus TCP, this value is always 0x0000.
  • Byte Order Big-Endian.

• Length - 2 Bytes

  • Purpose Indicates the number of bytes in the Modbus PDU that follows (this includes the Unit Identifier, Function Code, and Data fields).
  • Range 0x0000 to 0xFFFF.
  • Byte Order Big-Endian.

• Unit Identifier - 1 Byte

  • Purpose In some scenarios, this field acts as the slave address, especially when connecting to Modbus RTU serial devices through a Modbus TCP/IP gateway. The gateway uses this identifier to forward the Modbus TCP request to the corresponding Modbus RTU slave.
  • Range 0x00 to 0xFF (typically 1-247, consistent with the Modbus RTU slave address range).
  • Importance When a Modbus TCP device supports TCP/IP communication directly, this field is often set to 0x00 or ignored. However, if a Modbus TCP client needs to communicate with Modbus RTU devices connected via an Ethernet gateway, this field must be set to the target Modbus RTU device's slave address. It can be thought of as a "virtual slave address" or a "subnet address" within the Modbus TCP network.

4.1.2 Modbus PDU (Protocol Data Unit) - Variable Length

The Modbus PDU is the core part of the protocol and is essentially the same in both Modbus RTU and Modbus TCP. It contains the function code and its associated data.

[Function Code] [Data Field]
     1 Byte         N Bytes

• Function Code - 1 Byte

  • Purpose Defines the type of action the client wants the server to perform (e.g., read data, write data).
  • Most Common Function Codes Identical to those in Modbus RTU; refer to the list in the Modbus RTU tutorial.

• Data Field - Variable Length

  • Purpose Contains specific information required to execute the function, such as the starting address, the quantity of items to read or write, the values to be written, etc.
  • Length Varies depending on the function code.

4.2 Summary of Key Differences with Modbus RTU

1. Physical Layer
   • Modbus RTU Based on serial communication (RS-485/RS-232).
   • Modbus TCP Based on Ethernet (TCP/IP).
2. Frame Structure
   • Modbus RTU [Slave Address] [Function Code] [Data Field] [CRC Check]
   • Modbus TCP [Transaction ID] [Protocol ID] [Length] [Unit ID] [Function Code] [Data Field] (i.e., MBAP Header + Modbus PDU)
3. Addressing Mechanism
   • Modbus RTU Directly uses the slave address field to address a physical device.
   • Modbus TCP Uses an IP address and port number to address a device. The Unit Identifier may be 0x00 for direct Modbus TCP devices but is used as the RTU slave address when communicating through a gateway.
4. Error Checking
   • Modbus RTU Uses a 2-byte CRC-16 check and relies on a T3.5 silent interval to synchronize frames.
   • Modbus TCP Removes the Modbus RTU CRC check. Data integrity and reliable transmission are handled entirely by the underlying TCP protocol stack.
5. Communication Model
   • Modbus RTU Master-Slave model.
   • Modbus TCP Client-Server model.
6. Multi-Device Access
   • Modbus RTU One master can poll multiple slaves, but typically only one master is active at a time.
   • Modbus TCP A Modbus TCP server can accept connections and requests from multiple clients simultaneously.

5. Exception Responses: The Error Handling Mechanism

When a client sends a valid request that the server cannot process (for example, requesting to read a non-existent register address or a data value that is out of range), the server returns an exception response frame instead of a normal response.

5.1 Exception Response Frame Format

The Modbus PDU portion of a Modbus TCP exception response frame is identical to that of Modbus RTU, but it is still preceded by the MBAP header.

[MBAP Header] [Function Code + 0x80] [Exception Code]
   7 Bytes            1 Byte              1 Byte

• MBAP Header The structure is the same as in the request frame, but the "Length" field will be smaller (typically 3 bytes: Unit Identifier + (Function Code + 0x80) + Exception Code). The Transaction Identifier is returned unchanged.
• Function Code + 0x80 This indicates an exception response. The server sets the most significant bit of the original function code to 1 (by performing a bitwise OR with 0x80), informing the client that an error occurred. For example, if the request function code was 0x03, the exception response function code will be 0x83.
• Exception Code A single byte that indicates the specific type of error.

5.2 Common Exception Codes and Their Meanings

6. Practical Application Examples: A Deeper Look at the Communication Flow

By examining specific command and response examples, we can better understand how Modbus TCP works.

6.1 Example 1: Reading Temperature Sensor Data (Function Code 0x03 - Read Holding Registers)

Suppose we have a temperature sensor server at IP address 192.168.1.100 on port 502. Its current temperature value is stored in a Holding Register at address 40001 (Modbus protocol offset address 0x0000). We want to read this single register. Since it's a direct Modbus TCP device, we'll set the Unit Identifier to 0x00.

Command Sent (Client -> Server):

00 01   00 00   00 06   00   03 00 00 00 01
|-----| |-----| |-----| |--| |-----------|
 Trans ID Prot ID Length  Unit ID  Modbus PDU (Func Code+Data)

Command Breakdown:

• 00 01 The Transaction Identifier, set to 1 by the client.
• 00 00 The Protocol Identifier, fixed at 0.
• 00 06 The Length, indicating 6 bytes follow (Unit ID 00 + Func Code 03 + Start Address 0000 + Quantity 0001 = 6 bytes).
• 00 The Unit Identifier. Set to 0x00 here, indicating a direct Modbus TCP device.
• 03 The function code for Read Holding Registers.
• 00 00 The starting register address is 0x0000 (corresponding to reference address 40001).
• 00 01 Request to read 1 register.

Device Response (Server -> Client):

00 01   00 00   00 05   00   03 02 00 64
|-----| |-----| |-----| |--| |----------|
 Trans ID Prot ID Length  Unit ID  Modbus PDU (Func Code+Data)

Response Breakdown:

• 00 01 The Transaction Identifier, matching the request.
• 00 00 The Protocol Identifier, fixed at 0.
• 00 05 The Length, indicating 5 bytes follow (Unit ID 00 + Func Code 03 + Byte Count 02 + Data 0064 = 5 bytes).
• 00 The Unit Identifier.
• 03 The function code, indicating a normal response.
• 02 The byte count, meaning 2 bytes of data follow (as we read one 16-bit register).
• 00 64 The actual data read. 0x0064 converted to decimal is 100.

Result The client successfully reads the temperature value as 100 (which could represent Celsius, Fahrenheit, or an integer with an implied decimal point, depending on the device's specification).

6.2 Example 2: Setting an Output Coil Status (Function Code 0x05 - Force Single Coil)

We want to set the output coil at address 00001 (Modbus protocol offset address 0x0000) of a device at IP 192.168.1.101 to the ON state. Assume this device is a Modbus RTU slave with an RTU address of 02, connected via a Modbus TCP gateway.

Command Sent (Client -> Server/Gateway):

00 02   00 00   00 06   02   05 00 00 FF 00
|-----| |-----| |-----| |--| |-----------|
 Trans ID Prot ID Length  Unit ID  Modbus PDU (Func Code+Data)

Command Breakdown:

• 00 02 The Transaction Identifier, set to 2 by the client.
• 00 00 The Protocol Identifier.
• 00 06 The Length.
• 02 The Unit Identifier. Set to 0x02 here to instruct the gateway to forward this request to the connected Modbus RTU slave with address 2.
• 05 The function code for Force Single Coil.
• 00 00 The coil address is 0x0000 (corresponding to reference address 00001).
• FF 00 The value to write. 0xFF00 sets the coil to ON, while 0x0000 would set it to OFF.

Device Response (Server/Gateway -> Client):

00 02   00 00   00 06   02   05 00 00 FF 00
|-----| |-----| |-----| |--| |-----------|
 Trans ID Prot ID Length  Unit ID  Modbus PDU (Func Code+Data)

Response Breakdown:

• For function code 0x05, a normal response from the slave/server is to echo the original request back to the client, confirming the action was successfully performed.
• 00 02 The Transaction Identifier, matching the request.
• 00 00 The Protocol Identifier.
• 00 06 The Length.
• 02 The Unit Identifier.
• 05 The function code.
• 00 00 The coil address.
• FF 00 Confirms the coil was set to ON.

Result The slave's coil 00001 is successfully turned on.

7. Data Types and Byte Order: Handling Complex Data

Just like Modbus RTU, Modbus TCP uses the 16-bit (2-byte) register as its fundamental data storage unit. Therefore, when handling more complex data types like 32-bit integers or floating-point numbers, Modbus TCP also faces challenges related to data type conversion and byte order.

7.1 Common Data Types in Modbus

7.2 Byte Order and Word Order Issues

When a data type occupies two or more registers (like a 32-bit integer or float), the arrangement of these registers and the byte order within each register become critically important. Different device manufacturers may use different byte and word orders, which is a common source of data parsing errors.

Assume we have a 32-bit value 0x12345678, which occupies two 16-bit registers:

• Register A holds 0x1234
• Register B holds 0x5678

Here are several common byte and word order combinations:

1. ABCD (Big-Endian)

   • Word Order High word first (Register A, Register B) -> 0x1234 0x5678
   • Byte Order High byte first within each word -> 12 34 56 78
   • Common In Modicon, Siemens, older Rockwell devices.
   • Storage Order High byte -> Low byte (left to right).

2. DCBA (Little-Endian)

   • Word Order Low word first (Register B, Register A) -> 0x5678 0x1234
   • Byte Order Low byte first within each word -> 78 56 34 12
   • Common In Intel/PC architecture, some Japanese PLCs.
   • Storage Order Low byte -> High byte (left to right).

3. BADC (Swapped Big-Endian)

   • Word Order High word first (Register A, Register B) -> 0x1234 0x5678
   • Byte Order Low byte first within each word -> 34 12 78 56
   • Storage Order Low byte (Word 1) -> High byte (Word 1) -> Low byte (Word 2) -> High byte (Word 2).

4. CDAB (Swapped Little-Endian)

   • Word Order Low word first (Register B, Register A) -> 0x5678 0x1234
   • Byte Order High byte first within each word -> 56 78 12 34
   • Storage Order High byte (Word 2) -> Low byte (Word 2) -> High byte (Word 1) -> Low byte (Word 1).

Solution

• Consult the Device Manual Always check the server device's communication manual first, as it should specify the data types and byte order used.
• Test with Online Tools When the manual is unclear, use a Modbus debugging tool to try different byte order combinations until the data is parsed correctly.
• Handle in Program Logic In the client application, perform the necessary byte or word swapping operations based on the server's requirements.

8. Modbus TCP Application Scenarios

The network capabilities of Modbus TCP give it a unique advantage in various industrial applications:

1. Plant-wide SCADA/HMI Systems

   • Centralize data collection from numerous field PLCs, DCSs, and smart devices into a SCADA (Supervisory Control and Data Acquisition) system or HMI (Human-Machine Interface) for real-time monitoring and control.
   • Ethernet-based deployment simplifies wiring and increases data transmission efficiency.

2. Distributed Control Systems

   • In large plants or geographically dispersed sites, Modbus TCP connects different controllers and I/O modules to achieve coordinated control.
   • Remote device access and control can be easily implemented using routers and VPNs.

3. Industrial IoT (IIoT) and Cloud Platform Integration

   • Modbus TCP devices can directly upload data to corporate servers or cloud platforms for big data analytics, predictive maintenance, and production optimization.
   • Facilitates data integration with higher-level systems like MES (Manufacturing Execution Systems) and ERP (Enterprise Resource Planning).

4. Networking Serial Devices

   • Existing Modbus RTU devices can be converted to Modbus TCP devices using serial device servers or Modbus gateways, enabling network-based management.
   • This approach is cost-effective as it avoids replacing existing equipment and is a preferred solution for upgrading older facilities.

5. Device-to-Device Communication

   • Modern smart devices (like robots, CNC machines, and smart sensors) can communicate directly via Modbus TCP in P2P (peer-to-peer) or multipoint configurations, enabling inter-device collaboration and information sharing.

9. Practicing Modbus TCP with Online Tools

While theoretical knowledge is important, hands-on practice is the best way to master Modbus TCP. We highly recommend using the Modbus Online Tool to aid your learning and debugging:

1. Modbus TCP Command Generator

   • Automatically generates standard Modbus TCP request frames (including the MBAP header) based on parameters like Transaction ID, Unit ID, function code, starting address, and quantity.
   • Ideal for verifying that the commands you construct manually are correct.

2. Modbus TCP Data Parser

   • Input a hexadecimal Modbus TCP response frame, and the tool will automatically parse the MBAP header, function code, and data content.
   • Supports parsing for various data types (like UINT16, INT16, UINT32, FLOAT32) and byte orders (ABCD, DCBA, BADC, CDAB), helping you verify if the data read from a device is correct.

10. Common Problems and Solutions

You may encounter some common issues when implementing Modbus TCP in practice. Understanding their causes and solutions can significantly improve your debugging efficiency.

10.1 Connection Failure or Inability to Establish a Connection

Symptom

The client fails to connect to the server or disconnects immediately after connecting.

Common Causes

• Incorrect IP Address or Port Number The IP address or port number configured in the client does not match the server's settings.
• Network Unreachable A network disruption exists between the client and server, possibly due to a damaged cable, switch failure, or a firewall block.
• Server Not Running or Unresponsive The Modbus TCP server application is not started, or the device itself is faulty.
• Firewall Blocking A firewall on the PC or network (including Windows Firewall or an industrial firewall) is blocking TCP port 502.

Solutions

• Verify IP Address and Port Ensure the IP address and port (default 502) are correctly configured and identical on both the client and server.
• Ping Test Use the ping <server_ip_address> command on the client PC to test network connectivity. If the ping fails, check cables, switches, and routers.
• Test Port with Telnet Use the telnet <server_ip_address> 502 command on the client PC to check if the port is open. A successful connection indicates the port is accessible.
• Check Server Status Confirm that the Modbus TCP server is powered on and running correctly.
• Configure Firewall Ensure that the port used by Modbus TCP (usually 502) is allowed through the firewalls on both the client and server.

10.2 Communication Timeout

Symptom

The client sends a request but does not receive a response from the server within the configured time limit.

Common Causes

• Network Latency High network traffic, transmission across a wide area network, or low-quality network hardware can cause excessive packet delay.
• High Server Load The server is handling too many requests simultaneously, leading to a slow response time.
• Invalid Request Address or Data Range The server receives the request but cannot process it (e.g., trying to read a non-existent address range) and fails to return an exception response, instead getting stuck or discarding the request.
• Incorrect Unit Identifier When communicating through a gateway, an incorrect Unit Identifier prevents the gateway from forwarding the request to the target RTU device.

Solutions

• Increase Timeout Period Lengthen the client's timeout setting to accommodate network latency or slow server responses.
• Check Network Conditions Use network analysis tools to assess network latency and bandwidth.
• Optimize Server Configuration If possible, review the server's performance and configuration to reduce its load.
• Verify Unit Identifier If communicating with an RTU device via a gateway, ensure the Unit Identifier matches the target RTU slave address.
• Confirm Request Validity Make sure the requested register addresses and quantities are within the valid range for the server device.

10.3 Data Parsing Errors (Incorrect Values)

Symptom

A response is successfully received from the server, but the parsed data does not match the expected values (e.g., a temperature reading appears as garbled text or a large, incorrect number).

Common Causes

• Incorrect Byte Order or Word Order Configuration This is the most common issue, especially when dealing with 32-bit data (UINT32, INT32, FLOAT32). The Modbus TCP protocol itself requires the MBAP header to be big-endian, but the byte and word order of the data within the PDU is determined by the device manufacturer.
• Wrong Data Type Selection For instance, trying to parse a floating-point number as an integer, or a signed number as an unsigned one.
• Incorrect Register Address Mapping The requested register address does not match the actual data address defined in the device manual.
• Scaling or Offset Not Applied The device may output a raw ADC value that needs to be converted into a physical quantity through calculation.

Solutions

• Consult the Device Manual Strictly follow the device manual to confirm the data type, number of registers used, byte order, and word order.
• Try Different Byte Order Combinations Use an online Modbus tool or debugging software to test all possible byte order combinations (ABCD, DCBA, BADC, CDAB) until the data is displayed correctly.
• Confirm Data Type Ensure the client uses the same data type for parsing as the server provides.
• Verify Register Addresses Double-check that the requested register addresses are correct and correspond to the specific data points on the device.
• Apply Scaling/Offset If the device outputs raw values, add the necessary conversion formulas to the client application.

11. Advanced Learning Suggestions

1. Modbus TCP Security

   • Understand the potential security threats Modbus TCP faces in an open Ethernet environment, such as data tampering and unauthorized access.
   • Learn how to enhance Modbus TCP communication security using VPNs, firewall rules, VLAN segmentation, and TLS encryption (Modbus Secure).
   • Food for thought What security measures are essential in an industrial control network?

2. Network Diagnostic Tools

   • Become proficient with network protocol analyzers like Wireshark to capture and analyze Modbus TCP packets. This will help you gain a deep understanding of the MBAP header, PDU structure, and quickly diagnose network and application layer issues.
   • Learn how to filter Modbus TCP traffic and interpret the captured data frames.
   • Practice Try capturing a Modbus TCP communication session and manually parsing its key fields.

3. Modbus Gateway Configuration and Application

   • Gain in-depth knowledge of the features, configuration methods, and application scenarios of Modbus gateways from different brands (e.g., MOXA, Advantech).
   • Master how to connect Modbus RTU devices to a Modbus TCP network via a gateway and understand the role of the Unit Identifier in this process.
   • Food for thought In a multi-layered network architecture, how should the placement and quantity of gateways be planned?

4. Programming Modbus TCP Clients/Servers

   • Try writing your own Modbus TCP client and server applications using languages like Python (with libraries such as pymodbus), C++ (e.g., libmodbus), Java, or .NET.
   • Deepen your understanding of protocol details (like MBAP header construction, data parsing, and exception handling) through programming practice.
   • Project Develop a simple Modbus TCP client to read data from a simulated server, then try creating a server that responds to client requests.

5. Comparative Study of Other Industrial Ethernet Protocols

   • Learn about other major industrial Ethernet protocols besides Modbus TCP, such as EtherNet/IP, PROFINET, and OPC UA.
   • Compare their differences in terms of performance, features, openness, complexity, and real-time capabilities to make informed protocol choices in projects.
   • Food for thought In which scenarios is Modbus TCP the best choice? In which scenarios do other protocols have an advantage?

6. Large-Scale System Integration and Performance Optimization

   • Learn how to optimize performance in large Modbus TCP networks by reducing polling cycles, refining data acquisition strategies, and using multi-threading.
   • Understand how to manage concurrent connections and a large number of data points.
   • Challenge Design a system architecture capable of efficiently collecting data from hundreds or even thousands of Modbus TCP data points.

12. Conclusion

As a cornerstone of industrial Ethernet communication, Modbus TCP is increasingly becoming a core protocol in modern industrial automation systems due to its network capabilities, high speed, and ease of integration. After completing this tutorial, you should have:

• A clear understanding of the basic concepts of Modbus TCP, its client-server model, and its Ethernet-based physical and network layers.
• Mastered the structure of the unique Modbus TCP MBAP header and its role in communication.
• A deep understanding of the dual role of the Unit Identifier in the Modbus TCP protocol (often ignored in direct device communication but used as a slave address for gateway passthrough).
• A clear grasp of the key differences between Modbus TCP and Modbus RTU in terms of frame structure, error checking, and addressing.
• Learned how to identify and handle Modbus TCP exception responses.
• Understood how to send requests and parse responses through practical examples.
• Recognized the importance of data types, byte order, and word order, and learned how to resolve related issues.
• An awareness of the main application scenarios for Modbus TCP and the skills to practice and debug using online tools.

By staying curious and continuing to practice and learn, you will be able to skillfully apply the Modbus TCP protocol in various industrial automation projects, building stable, reliable, and high-performance industrial network communication systems and contributing to the development of the Industrial IoT.