Modbus Tcp设备接入

fastbee大约 5 分钟

一、Modbus Tcp协议

1、Modbus Tcp报文

Modbus TCP 报文由以下几个主要部分组成：

MBAP 报文头（Modbus Application Protocol Header）：
- 事务标识符（Transaction Identifier）：用于匹配请求和响应，通常由客户端生成。
- 协议标识符（Protocol Identifier）：固定为 0，表示 Modbus 协议。
- 长度（Length）：后续数据的字节长度，包括单元标识符和 PDU （Protocol Data Unit）。
- 单元标识符（Unit Identifier）：用于标识从站设备。
PDU（Protocol Data Unit）：
- 功能码（Function Code）：指示要执行的操作，如读取、写入等。
- 数据（Data）：根据功能码的不同，包含相应的操作数据。

读取保持寄存器的请求报文可能如下：

事务标识符：0x0001
协议标识符：0x0000
长度：0x0006
单元标识符：0x01
功能码：0x03
起始地址：0x0000
寄存器数量：0x0002

响应报文中，如果成功读取到数据

事务标识符：0x0001
协议标识符：0x0000
长度：0x0005
单元标识符：0x01
功能码：0x03
字节计数：0x04
数据：0x000A  0x000B

事务标识符：

范围值：0x0000 ~ 0xFFFF 即是 0-65535，如果超出范围，会从0开始计算

最重要作用：作为报文的流水号

客户端发送请求时会生成一个唯一的事务标识符，服务器在响应时使用相同的事务标识符。这使得客户端能够将收到的响应与之前发送的请求准确关联起来，确保数据的对应性和准确性。例如，客户端同时发送了多个不同的请求，如果没有事务标识符，客户端将难以区分每个响应对应的是哪个请求。

采用顺序递增的方式为每个对设备状态的读取请求分配事务标识符。

这里建议每个设备都记录一下自己的事务标识符，以便递增。

例如在redis中记录这个设备A轮询时的事务标识符，从0开始，想客户端下发一条报文(客户端应答后)，事务标识符自动+1

知道65535后，从0开始计算。客户端并不会识别事务标识符，如果重复了客户端也会有回复。

2、实现与配置

实现方式和ModbusRtu大体一致，只是报文不一样
配置方式：产品选择ModbusTcp协议，参考网关与子设备文档配置

请求：00 01 00 00 00 06 01 01 00 02 00 04（云端） 00 01：事务标识符 00 00：Modbus TCP协议 00 06：后面有00 06个字节数据 01：单元标识符 01：功能码（读线圈） 00 02：开始读的数据的地址。从00 02开始读数据。 00 04：注意这里不是读到00 04，而是从开始位置读00 04个数据。这段报文就是请求读从 00 00 开始的 00 08 个数据。

回应：00 01 00 00 00 04 01 01 01 0E（设备） 00 01：事务标识符 00 00：Modbus TCP协议 00 04：后面有00 04个字节数据 01：单元标识符 01：功能码 01：后面有01个字节的数据 0E：表示所读地址的线圈全是2的位置是0，其余是1 说明：线圈是只有00和01两种格式，所以图中从2的位置开始读到的4位数据是：1110（二进制），转化为十六进制就是0E

2. 0x03：读保持寄存器

请求：00 01 00 00 00 06 01 03 00 02 00 04（云端） 00 01：事务标识符 00 00：Modbus TCP协议 00 06：后面有00 06个字节数据 01：单元标识符 03：功能码（读保持寄存器） 00 02：开始读的数据的地址。从00 02开始读数据。 00 04：注意这里不是读到00 04，而是从开始位置读00 04个寄存器数据。 回应：00 01 00 00 00 0B 01 03 08 00 00 00 37 00 00 00 00（设备） 00 01：事务标识符 00 00：Modbus TCP协议 00 09：后面有00 09个字节数据 01：单元标识符 03：功能码 08：后面有08个字节的数据，后面的数据每两位表示一个寄存器数据。 00 00：第一个寄存器数据 00 37：第二个寄存器数据，图中我写入的数据是55（十进制），这里是十六进制数据 00 00：第三个寄存器数据 00 00：第四个寄存器数据