Modbus communication protocol and explain the differences between the Modbus TCP protocol

Modbus communication protocol (Schneider has now mergers and acquisitions, as its sub-brand's) by the company in 1979 Modicon invention, is the world's first bus Statute for industrial field. Due to its free public offering, using the protocol of the manufacturer without paying any fee, Modbus communication protocol uses a master-slave communication mode (i.e., Master / Slave communication mode), which application is extremely broad in dispersion control, so that the Modbus protocol worldwide It has been widely used.

Modbus communication protocol has multiple variants, with support serial (RS-485 bus mainly), multiple Ethernet versions, most notably the Modbus RTU, Modbus ASCII and Modbus TCP three. Which are Modbus ASCII and Modbus RTU supports RS-485 bus protocol, wherein the Modbus RTU binary representation because of its use and a compact data structure, higher communication efficiency, used widely. Due to ASCII and Modbus ASCII code transmission, and the use of special characters as a start and end byte identification, which is much lower than the transmission efficiency of the Modbus RTU protocol, generally only a small amount of communication data in the case where only consider using Modbus ASCII communication protocols, are generally used in the industrial field Modbus RTU protocol, in general, they say that the Modbus communication protocol based on serial communication refer to Modbus RTU communication protocol.

Here we focus on the Modbus RTU protocol and Modbus TCP protocol is a plus MBAP header on RTU protocol, since TCP is a reliable connection-based services, RTU protocol CRC check code is no longer needed, so modbus TCP protocol is no CRC check code, with a more popular words is: modbus TCP protocol is modbus RTU protocol and preceded by a five 0 6, and then remove the two bytes of CRC on OK. While this is, indeed, not particularly accurate, but basically the difference between the RTU and TCP little more clearly.

RTU protocol executed by the address code (one byte), function code (one byte), the start addresses (two bytes), data (N bytes), check code (two bytes) five parts, where the data and the data length (two bytes indicates the number of registers, content is assumed M) and text data (M is multiplied by 2 bytes), and 3.5 RTU protocol is a word Festival of free time as an instruction start and end, in general, only when the data is returned from the host machine or write operation, the data will have the body, while other times, such as when the host read command, no data is text, only the length of the data to. (Discussed in this chapter relate only to read and write registers, to read and write other such coil we do not involve instructions). Here we pass two instructions (0x03H: Read multiple register instructions and 0x10H: Write multiple register instructions) to explain the Modbus RTU protocol. The RTU equipment we are using the National Science Albert Shenzhen Communication Technology Co. of ND-1084 Type 485 I / O modules .

485 ND-1084 type I / O modules using RS-485 communications bus, supports four digital outputs and eight switch inputs, we only read about the state of the switching output and the output of switch control by the write command. Wherein the register stores four binary output states are: 0x18E, 0x18F, 0x190,0x191. Here we assume that as the default address of the module 0x01, when we go to the state of the four register outputs corresponding read switching time, our hexadecimal command is issued: "01 03 01 8E 00 04 25 DE ", where" 01 "is a module address code," 03 "is function code, i.e., the read register" 01 8E "register address, i.e., start reading data from the register address," 0004 "indicates read four registers, and "25 DE", compared with the previous "01 03 01 8E 00 04" of the CRC, the value calculated by CRC16 checksum algorithm, we will explain in other articles. Interpretation of this instruction is complete, the address code is "01" in the module, from the "01 8E" start register, the read data registers 4 is returned to the host. Here, we can see that there is nothing to read instructions and data in the text, because it only reads the corresponding number of registers, the body does not need the data, and write operations on the contrary, we will talk about later.

Command module returns: "01 03 08 00 01 00 01 00 01 00 01 28 D7", the instruction content returned interpretation is: "01" indicates the address code module, "03" indicates that the instruction is an instruction read operation to return "08" indicates the data length, this indicates that the text data of 8 bytes (i.e. four registers that each two bytes), "0,001,000,100,010,001" is text data showing four status register, "28 D7" is CRC16 checksum.

Also when we perform the write operation is the first example we write switch output, i.e., the register "0x18E", issued by the host instruction: "01 10 01 8e 00 01 02 00 00 A8 7E", the instruction Interpretation is: "01" indicates the address of the module, "10" indicates that the instruction is a write register, "01 8E" starts from the register address write operation instruction "0001" indicates how many registers to write, here to write 1 registers, "02" indicates the data length indicating a data length of two bytes, "0000" indicates a write data register, this indicates communication, "A8 7E" is the CRC. Similar return instruction to return the command module and read registers.

Previously described, Modbus TCP protocol is added in front of MBAP RTU protocol packet header, a total length of seven bytes, the meaning respectively: 1 transmission symbol, two byte length flag Modbus transmission inquiry / response, usually the default is 00 00.2. agreement flag, two byte length, 0 is Modbus, 1 represents a UNI-TE protocol, a default is generally 00 00.3. subsequent byte count, two-byte length, the actual significance is the byte length of the latter, specific conditions detailed below. 4. unit flag, a byte length, typically default to 00, corresponding to the unit flag Modbus RTU protocol address code, when the protocol conversion between TCP and the RTU, Modbus Gateway especially when converting protocols in TCP protocol, the data corresponding to the address code is RTU protocol, see below circumstances.

Through the above description we can understand almost Modbus RTU protocol, we say that the Modbus TCP protocol, it has been said in front of the TCP protocol is to remove the check code on the basis of RTU protocol and five plus 0 and a 6, when it is read the relevant register when the claim is not wrong, such as the above "01 03 01 8E 00 04 25 DE" reading instruction, use the TCP protocol to express it, the command is "0,000,000,000,060,003 01 8E 00 04 ", because TCP is based on the so-called TCP connection address code does not exist, it is generally 06 after" 00 "(which is mounted when a plurality of devices as Modbus RTU gateway server, a value of from 01- the FF). i.e. "00 03 01 8E 00 04" corresponds to an instruction to remove the RTU check code, and in front of it is a five 0 6. Where 6 represents the data length, i.e., "00 03 01 8E 00 04" has a length of 6 bytes. And when the operation instruction is a write, the instruction is "00 00 00 00 00 09 01 10 01 8e 00 01 02 00 00", in which "0009" indicates that the following nine bytes.

Modbus TCP and Modbus RTU read instruction Comparative

 
MBAP header
address code
function code
Register Address
The number of registers
CRC check
Modbus RTU
no
01
03
01 8E
00 04
25 OF
Modbus TCP
00 00 00 00 00 06 00
no
03
01 8E
00 04
no

Meaning instruction: code from address 01 (TCP protocol unit 00 as flag) module 0x18E (01 8E) starts reading address register (03) four (0004) register.

Modbus RTU and Modbus TCP contrast write instruction

 
MBAP header
address code
function code
Register Address
The number of registers
Data length
text
CRC check
RTU
01
10
01 8E
00 01
02
00 00
A8 7E
TCP
00 00 00 00 00 09 00
10
01 8E
00 01
02
00 00

指令的涵义:从地址码为01(TCP协议单元标志为00)的模块0x18E(01 8E)寄存器地址开始写(10)一个(00 01)寄存器,具体数据长度为2个字节(02),数据正文内容为00 00(00 00)。

Guess you like

Origin blog.csdn.net/luoyajingfeng2/article/details/80249085