meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
automation:s7_modbus [2026/03/24 19:50] – [Modbus/TCP] vamsanautomation:s7_modbus [2026/03/25 08:46] (current) – [Modbus/TCP] vamsan
Line 67: Line 67:
  
 Although quite different, they can sometimes be integrated, such as in multimaster (hybrid) RTU scenarios. In this scenario, a signal converter needs to be integrated into the TCP network. The converter has its own IP address to receive Modbus/TCP telegrams. It's crucial that the client is aware of the Modbus/RTU network behind the converter, which uses traditional RTU addressing. Often, clients cannot manage both RTU addressing and TCP simultaneously, so verifying their ability to do so is essential. The Siemens TIA Portal is suitable for this task, and I will offer an example of its use later. Although quite different, they can sometimes be integrated, such as in multimaster (hybrid) RTU scenarios. In this scenario, a signal converter needs to be integrated into the TCP network. The converter has its own IP address to receive Modbus/TCP telegrams. It's crucial that the client is aware of the Modbus/RTU network behind the converter, which uses traditional RTU addressing. Often, clients cannot manage both RTU addressing and TCP simultaneously, so verifying their ability to do so is essential. The Siemens TIA Portal is suitable for this task, and I will offer an example of its use later.
 +
 +|< 100% >|
 +|{{ :automation:modbus_s7_rtu_1.svg |Modbus RTU shema}}|{{ :automation:modbus_s7_tcp_1.svg |Modbus TCP shema}}|{{ :automation:modbus_s7_hybrid_1.svg |Modbus RTU-TCP hybrid shema}}|
  
 |< 100% >| |< 100% >|
Line 79: Line 82:
 ^Addressing|Master ID: 0, slave ID: 1 to 247|IP Address (like: //192.168.178.123//)| ^Addressing|Master ID: 0, slave ID: 1 to 247|IP Address (like: //192.168.178.123//)|
 ^Wiring|3-core cable with shielding or 4-core cable|Ethernet cables (RJ45) and network switches| ^Wiring|3-core cable with shielding or 4-core cable|Ethernet cables (RJ45) and network switches|
- 
- 
-|< 100% >| 
-|{{ :automation:modbus_s7_rtu_1.svg |Modbus RTU shema}}|{{ :automation:modbus_s7_tcp_1.svg |Modbus TCP shema}}|{{ :automation:modbus_s7_hybrid_1.svg |Modbus RTU-TCP hybrid shema}}| 
  
 ==== Modbus/RTU ==== ==== Modbus/RTU ====
 +{{ :automation:modbus_s7_rtu_1.svg|}}
 +Modbus/RTU was the first Modbus communication method and remained the main standard until Ethernet became popular. It remains widely used today, partly because its hardware integration is simpler and more affordable than Modbus/TCP. As a result, it is likely to stay available for quite some time.
  
 === Comparison of RS-232 and RS-485 ===  === Comparison of RS-232 and RS-485 === 
Line 174: Line 175:
  
 === Modbus/RTU Error Checking (CRC) === === Modbus/RTU Error Checking (CRC) ===
-Even though "No Parity" (8N1) lacks bit-level checking, Modbus RTU is still secure because every full packet ends with a 16-bit CRC (Cyclic Redundancy Check). If a single bit is flipped during transmission due to noise, the CRC will fail, and the receiving device will ignore the command.+Even though //"No Parity"// (**8N1**) lacks bit-level checking, Modbus RTU is still secure because every full packet ends with a 16-bit **CRC** (//Cyclic Redundancy Check//). If a single bit is flipped during transmission due to noise, the CRC will fail, and the receiving device will ignore the command.
  
 The **CRC** (//Cyclic Redundancy Check//) is an error-detection method that ensures data integrity in Modbus RTU. It is a 16-bit (2-byte) value appended to each message. The **CRC** (//Cyclic Redundancy Check//) is an error-detection method that ensures data integrity in Modbus RTU. It is a 16-bit (2-byte) value appended to each message.
Line 185: Line 186:
  
 ==== Modbus/TCP ==== ==== Modbus/TCP ====
 +{{ :automation:modbus_s7_tcp_1.svg|}}
 Modbus/TCP (also known as Modbus TCP/IP) is a version of the Modbus protocol designed for Ethernet network communication. It wraps standard Modbus messages into TCP/IP packets, enabling reliable, high-speed data exchange. Modbus/TCP (also known as Modbus TCP/IP) is a version of the Modbus protocol designed for Ethernet network communication. It wraps standard Modbus messages into TCP/IP packets, enabling reliable, high-speed data exchange.
  
Line 193: Line 195:
   * **Addressing:** Uses IP addresses to identify devices instead of the 1-byte Slave ID used in serial versions.   * **Addressing:** Uses IP addresses to identify devices instead of the 1-byte Slave ID used in serial versions.
  
-=== Modbus TCP Frame Structure === 
  
-The Modbus TCP frame (//Application Data Unit// or **ADU**) consists of a specialized header (**MBAP**) followed by the standard Modbus PDU.  +==== Modbus/TCP and Modbus/RTU Hybrid ==== 
- +{{ :automation:modbus_s7_hybrid_1.svg|}}
-|< 100% >| +
-^Field^Length^Description| +
-^Transaction ID|2 Bytes|A request number used to match responses with requests.| +
-^Protocol ID|2 Bytes|Always 0 for Modbus services.| +
-^Length|2 Bytes|Count of remaining bytes (Unit ID + PDU).| +
-^Unit ID|1 Byte|Used for routing through gateways to serial Modbus devices; otherwise often set to 255 or 0.| +
-^Function Code|1 Byte|Defines the operation (e.g., Read Holding Registers).| +
-^Data Field|Variable|Contains the actual payload (register addresses, values, etc.).|+
 ==== Modbus Registers and Coins ==== ==== Modbus Registers and Coins ====
 Modbus data is structured into four main //"data banks"// or //"storage units"//, categorized by whether the data is a single bit or a 16-bit word, and whether it is read-only or read-write. Modbus data is structured into four main //"data banks"// or //"storage units"//, categorized by whether the data is a single bit or a 16-bit word, and whether it is read-only or read-write.
Line 228: Line 221:
  
 {{ :automation:modbus_s7_04.png |Modbus Register short and long Addressing}} {{ :automation:modbus_s7_04.png |Modbus Register short and long Addressing}}
-==== Modbus Telegram structure ====+ 
 +==== Modbus Telegram Structure, ADU/PDU ==== 
 +In Modbus, the Application Data Unit (ADU) represents the complete message frame sent over a physical network. It functions as an //"envelope"// that encloses the Protocol Data Unit (PDU)—the main message with commands and data—while also including addressing and error-checking fields specific to the communication method. 
 + 
 +The ADU's structure changes based on whether you're using Modbus RTU (serial) or Modbus TCP (Ethernet): 
 + 
 +{{ :automation:modbus_s7_12.svg |Modbus Telegram Structure, ADU and PDU}} 
 + 
 +|< 100% 50% 50% >| 
 +|**Modbus/TCP** ADU (Ethernet)|**Modbus/RTU** ADU (Serial)| 
 +|**MBAP** Header (7 Bytes): \\ - Transaction ID (2 Bytes): Matches requests with responses. \\ - Protocol ID (2 Bytes): Always 0 for Modbus. \\ - Length (2 Bytes): Number of remaining bytes. \\ - Unit ID (1 Byte): Used for routing to serial devices through a gateway. \\ **PDU** (Function Code + Data): The core command. \\ \\ Max Size: 260 bytes.|Slave **Address** (1 Byte): Identifies the target device (1–247). \\ **PDU** (Function Code + Data): The core command. \\ **CRC** (2 Bytes): A Cyclic Redundancy Check used to detect transmission errors. \\ \\ Max Size: 256 bytes.| 
 + 
 +Error checking by Modbus/TCP is managed by the TCP layer and is not included in the ADU. 
 + 
 +=== Modbus Protocol Data Unit (PDU) === 
 +The //Modbus Protocol Data Unit// (**PDU**) is the core message structure common to all Modbus variants (RTU, ASCII, and TCP). It defines the actual command and data being exchanged between a client and a server, independent of the network medium. The PDU consists of two primary fields with a maximum combined size of 253 bytes. 
 + 
 +^Field^Size^Description| 
 +^Function Code|1 Byte|Tells the server which action to perform, such as Read, Write, Diagnostic.| 
 +^Data Field|0–252 Bytes|Contains request details such as register addresses, quantities, or the actual data values being transmitted or returned.| 
 + 
 +**Function Code Types** 
 + 
 +The function code ranges from 1 to 255 and is categorized by its purpose:  
 +  * **Public Codes (1–64, 73–99, 111–127):** Standardized, well-defined commands like **03** (//Read Holding Registers//) or **16** (//Write Multiple Registers//). 
 +  * **User-Defined Codes (65–72, 100–110):** Reserved for custom device functions not defined by the standard. 
 +  * **Exception Responses (128–255):** When an error occurs, the server returns the original function code with its highest bit set (//Original Code + 0x80//).  
 + 
 +**Data Field Structure** 
 + 
 +The structure of the data field changes depending on whether the PDU is part of a Request or a Response: 
 + 
 +  * In a **Request**, the Starting Address (2 bytes) and the Quantity of items to read or write (2 bytes) are typically included. 
 +  * In a **Response**, it presents a Byte Count along with the requested data values. 
 +  * **Addressing:** All addresses within the PDU data field are 0-based offsets ranging from 0 to 65.535. 
 + 
 +**Data Encoding (Endianness)** 
 + 
 +Modbus uses Big-Endian representation for all 16-bit values within the PDU. This means the //Most Significant Byte// (**MSB**) is transmitted before the //Least Significant Byte// (**LSB**). //Example:// A register value of 0x1234 is sent as 0x12 followed by 0x34. 
 + 
 +=== Modbus Function Codes === 
 +The table below details the standard Modbus function codes, which cover data access, diagnostics, and advanced functions used in both RTU and TCP variants. The first byte in a PDU is the Function Code, indicating the operation that the telegram performs. 
 + 
 +|< 100% >| 
 +^Code (Hex)^Code (Dec)^Function Name^Data Type^Access| 
 +^0x01|01|Read Coils|Bit (0x)|Read| 
 +^0x02|02|Read Discrete Inputs|Bit (1x)|Read| 
 +^0x03|03|Read Holding Registers|16-bit (4x)|Read| 
 +^0x04|04|Read Input Registers|16-bit (3x)|Read| 
 +^0x05|05|Write Single Coil|Bit (0x)|Write| 
 +^0x06|06|Write Single Register|16-bit (4x)|Write| 
 +^0x07|07|Read Exception Status|Serial Only|Read| 
 +^0x08|08|Diagnostics|Internal|Read| 
 +^0x0B|11|Get Comm Event Counter|Serial Only|Read| 
 +^0x0C|12|Get Comm Event Log|Serial Only|Read| 
 +^0x0F|15|Write Multiple Coils|Bit (0x)|Write| 
 +^0x10|16|Write Multiple Registers|16-bit (4x)|Write| 
 +^0x11|17|Report Server ID|Serial Only|Read| 
 +^0x14|20|Read File Record|File|Read| 
 +^0x15|21|Write File Record|File|Write| 
 +^0x16|22|Mask Write Register|16-bit (4x)|Write| 
 +^0x17|23|Read/Write Multiple Registers|16-bit (4x)|R/W| 
 +^0x18|24|Read FIFO Queue|16-bit|Read| 
 +^0x2B|43|Read Device Identification|Internal|Read| 
 + 
 +**Function Code Categories** 
 + 
 +  * **Public Function Codes (1–64, 73–99, 111–127):** These are standard codes established by the Modbus community.  
 +  * **User-Defined Codes (65–72, 100–110):** These are designated for custom implementations created by manufacturers.  
 +  * **Exception Codes (128–255):** These codes are reserved for error responses. When a server encounters an error, it responds by adding 0x80 to the original function code; for example, a failed Read 0x03 returns 0x83.
  
 ==== Modbus test programs, test methods ==== ==== Modbus test programs, test methods ====