Modbus报文结构详解：从RTU到TCP，功能码与CRC校验一次讲清

1. 为什么干了这么多年工控，还得回头抠报文

先从一个很典型的场景说起。现场设备通信异常，PLC显示“通信超时”，触摸屏上数据跳成灰色。你用万用表量了线，没问题；换了个终端电阻，还是不行；把波特率从9600调到19200，情况更糟。折腾半天，最后用调试软件抓了一帧数据，发现从站返回的是异常码03。这时候你才意识到，设备其实一直在好好回话，只是咱们发的报文内容不对，或者是寄存器地址超出了它的范围。

这就是我想说的“报文”。Modbus作为工控圈里最老牌、最普及的通信协议，几乎所有PLC、仪表、变频器、传感器都带这个口。很多人用上位机组态软件或者触摸屏时，基本就是在界面上填几个寄存器地址，从来没仔细看过背后那串十六进制数据到底是什么。可真到了排查故障、对接第三方设备、自己写通信程序的时候，不懂报文结构就是两眼一抹黑。

这篇内容不打算从协议规范那种教科书角度讲，而是按照咱们现场工程师的理解方式，把Modbus报文拆开揉碎：RTU帧长什么样、TCP帧多了什么、功能码怎么选、CRC校验到底怎么算、以及真出问题时怎么用报文去定位。适合刚接触工控通信的小白，也适合调过不少设备但没系统捋过报文格式的工程师。看完你就能对着抓包工具或串口调试助手，自己把每一帧报文读明白。

2. 报文结构拆解：一帧数据其实就四段话

2.1 从串口助手里的十六进制看起

如果你用过串口调试助手，往串口里发过Modbus RTU指令，你看到的通常是这样的十六进制串：

01 03 00 00 00 02 C4 0B

这串数据表面上是一串十六进制数字，实际上是一帧完整的Modbus RTU报文。工控里的“报文”，本质上就是“一帧有格式、有校验的数据”。它就像两个人对话之前约定好的暗号，必须分毫不差。多一个字节、少一个字节，或者校验字不对，对方要么不搭理你，要么回一个异常帧。

这一帧数据按功能可以划分成四个部分：从站地址、功能码、数据区、校验码。最前面的“01”是你要找谁说话，第二个“03”是你让人家干什么，中间四个字节“00 00 00 02”是干这件事的具体参数，最后两个字节“C4 0B”是整帧数据的校验信息，用来防止通信过程中数据被干扰改错。理解了这个大框架，后面所有的细节都是往里填东西。

2.2 从站地址段：不是门牌号那么简单

第一个字节是从站地址，范围是1到247。0这个地址比较特殊，它代表广播地址，意思是对总线上所有从站说话。在Modbus RTU的串行通信里，主站发广播帧时，从站要执行但不回复，这一点在实际调试中特别容易踩坑：你往地址0发了写指令，设备动作了，但是你看不到任何响应，怀疑通信是不是断了。其实设备早就执行完了。

从站地址并不是随便填的。在一条485总线上，所有从站并联在同一对线上，报文发出去以后每个从站都会收到这帧数据，只不过每个从站会先看地址字段是不是自己，不是自己的就丢弃。所以从站地址必须唯一，重复地址会造成两个设备同时响应，总线立刻冲突，主站收回来的是乱码。我自己调过一台项目，有两台仪表拨码都拨成了5，主站一读数据，返回的数据时对时错，查了很久才发现是站号冲突。

对于串口通信，从站地址还有一个隐藏作用：区分设备类型。有些工程师喜欢把不同种类的设备划分不同的地址段，比如1到10是PLC，11到20是仪表，21到30是变频器。这样上位机程序里判断地址段就知道在跟谁通信，日志也好看。这不是协议要求，但现场维护时确实方便。

2.3 功能码段：你要对方做什么

第二个字节是功能码，决定了这次通信的操作类型。最常用的就那么几个：

• 01：读线圈状态，也就是读DO（数字量输出）
• 02：读离散输入，也就是读DI（数字量输入）
• 03：读保持寄存器，读的是可读可写的寄存器，比如设定值、运行参数
• 04：读输入寄存器，读的是只读的寄存器，比如采集到的温度、压力
• 05：写单个线圈，把某个DO置ON或OFF
• 06：写单个保持寄存器，写一个16位的数据
• 0F：写多个线圈，一次写多个DO
• 10：写多个保持寄存器，一次写多个参数，注意这是十六进制10，不是十进制10

功能码的选择直接决定你对设备的操作能不能成功。比如你想读仪表采集的温度值，温度通常存在输入寄存器里，应该用04；如果你用03去读，很多仪表会返回异常码02“非法数据地址”。你感觉莫名其妙，明明文档里写了地址是30001，怎么就不对呢？其实是你把地址类型和功能码搞拧了：30001开头是输入寄存器，对应功能码04，不是03。

还要注意，每个设备厂商支持的寄存器类型不一样。有的仪表为了兼容，把输入寄存器里的值也镜像到保持寄存器里，这样你用03也能读。但这不是协议强制的，所以对接新设备时先看手册里的寄存器映射表，而不是凭经验硬试。

2.4 数据段：看你要读什么、写什么

数据段是报文里最灵活的部分，具体内容由功能码决定。以最常用的03功能码为例，一帧完整的读保持寄存器请求报文是：

01 03 00 00 00 02 C4 0B

数据段是“00 00 00 02”，可以拆成两部分：

• 00 00：起始寄存器地址，表示从地址0的寄存器开始读
• 00 02：读取的寄存器数量，表示连续读2个寄存器

注意，这里说的寄存器地址和你在组态软件里填的地址经常差个1。Modbus协议中寄存器地址是“零基址”的，也就是说寄存器编号从0开始。而很多设备手册、组态软件里习惯用“一基址”的表示方式，地址从1开始，这就是为什么你在触摸屏上填40001，实际报文里对应的是地址0000。我见过太多新手在这儿栽跟头：填了个40001去读，报文发出去总是被回异常码，改成0000就正常了。记住这个规律，可以省掉大半调试时间。

写单个寄存器的报文也类似。比如要把1号从站的保持寄存器地址0000写入一个值1234（十六进制04D2），发送的报文就是：

01 06 00 00 04 D2 C8 8F

数据段里“00 00”是寄存器地址，“04 D2”是要写入的数据。这里面还涉及一个字节序问题，后面专门说。

2.5 校验段：CRC16是怎么出现的

RTU报文最后两个字节是校验收。Modbus RTU用的是CRC16校验，也叫CRC-16/Modbus，多项式是0x8005，但计算时有一些特殊处理。简单理解就是把整帧数据（从站地址到数据段末尾）经过一系列异或和移位运算，得出一个16位的校验值。

这个校验值在报文里是“低字节在前、高字节在后”排列的。比如之前那个例子算出来的CRC是0x0BC4，发送时写的是C4 0B，正好低字节（C4）在前，高字节（0B）在后。很多刚开始手写报文的人容易把这个顺序搞反，发出去的帧CRC校验过不去，从站直接给你回一个异常码03“非法数据值”。这一条要刻在脑子里：CRC在报文中低位在前，高位在后。

校验的作用在工业现场非常关键。485总线是半双工的，现场电机启停、变频器干扰都可能让数据线出现毛刺，一帧数据里某一位被翻转是常有的事。没有校验，主站会把错误数据当真，后果可能是误动作；有了CRC，接收方用同样的算法算一遍，发现跟帧尾的校验字对不上，就丢弃这一帧，确保只处理可靠数据。

3. Modbus TCP报文：跟RTU看着像，但也有明显不同

3.1 MBAP头里的门道

如果你用的是以太网方式的Modbus TCP，报文结构跟RTU差别不小。TCP报文去掉了CRC校验，增加了一个7字节的MBAP头（Modbus Application Protocol Header），结构是：

事务处理标识符（2字节） + 协议标识符（2字节） + 长度（2字节） + 单元标识符（1字节） + 功能码 + 数据区

事务处理标识符是用来匹配请求和响应的。因为TCP连接是全双工的，同一时间可能发出多帧请求，每一帧带一个互不重复的序号，响应回来时带着相同的序号，主站就知道这帧响应对应的是哪一次请求。我自己在写多线程采集程序时就遇到过这个坑：如果每帧都用同一个事务标识符，在网络稍微拥堵的情况下，响应可能错配，读到的数据驴唇不对马嘴。最简单做法是每发一帧就把这个值加1，范围是0到65535，循环使用。

协议标识符在标准Modbus TCP里固定是00 00。如果收到非零值，说明这不是标准的Modbus应用数据，可能是厂商自定义的扩展。一般我们不用管，保持00 00就行。

长度字段很有意思，它表示的是“从单元标识符开始，到报文末尾”的长度。怎么理解？计算方式是后面的字节总数，也就是 单元标识符（1字节）+ 功能码（1字节）+ 数据区的字节数。因为这个字段已经包含了单元标识符的1个字节，所以有人会误以为长度是整个报文的长度，调试的时候长度算错，导致协议解析错位。

3.2 从站地址变成了单元标识符

TCP报文里没有专用的从站地址字段，取而代之的是单元标识符，占用MBAP头的最后一个字节。它的作用类似RTU里的从站地址，但有一个关键区别：在TCP网络中，这个标识符更多是逻辑上的设备编号，而不是物理地址。尤其是在用网关把Modbus TCP转成Modbus RTU的场合，单元标识符会被网关提取出来，放到RTU报文的地址段里，再通过串口发给对应的从站。

举个实操例子：你有一台网关，网口接PLC，串口接485总线上两台仪表，站号分别是1和2。PLC通过Modbus TCP访问时，往单元标识符填1或2，网关收到后会解析这个字节，把它转成RTU报文第一个字节（从站地址），所以从PLC的角度看，两台仪表就是两个不同的“单元”。你在配置网关时会看到一张映射表，把TCP单元标识符和串口从站地址一一对应起来，有的网关还允许把它们配成不同值，灵活归灵活，但调试时容易混乱，配置前一定画好映射关系。

3.3 RTU与TCP转换时要注意的细节

用网关做协议转换，是工控现场最常见的应用。转换过程中，RTU报文的CRC会被网关去掉，因为TCP帧里不再需要校验；RTU报文的从站地址会被挪到TCP帧的单元标识符位置；而MBAP头里的长度值，要按新帧结构重新计算。很多现成网关模块出厂自带转换功能，我们不需要自己实现这些步骤，但理解这个过程对排查问题特别有帮助。

有一次我用某款网关对接一台上位机软件，上位机一直报“从站无响应”。抓包发现网关根本没把请求转发到串口。查了一晚上，最后发现是网关的串口参数没配对：波特率设成19200，仪表实际是9600。因为报文格式本身转换没问题，但物理层波特率不一致，网关往总线上发数据，仪表根本“听不见”，自然没有响应。这类问题不看报文层级，光看应用层日志很难定位。排查协议转换类故障，正确思路是逐层确认：先看TCP报文到没到网关，再看RTU报文从网关发没发出去，最后看设备有没有回复。

4. 功能码分类与实际报文案例

4.1 01/02：读写开关量的报文长这样

读线圈用功能码01，读离散输入用功能码02。这两种报文格式几乎一样，唯一的区别是功能码不同。以读1号从站，从线圈地址0000开始读8个线圈为例：

请求：01 01 00 00 00 08 3D C6 响应：01 01 01 05 41 CC

响应报文里，后面的数据区是“01 05 41 CC”吗？不是，要仔细拆：功能码01之后，第一个字节01是“返回数据的字节数”，表示后面有几个字节的位状态数据；然后是“05”？不对，因为我说了读8个线圈，数据只占1个字节，所以响应应该是“01 01 01 05 C8 8F”？再检查一下。

响应帧的正确拆解是：

• 01：从站地址
• 01：功能码
• 01：后续数据长度（1个字节）
• 05：位状态打包的数据
• CRC

05即二进制0000 0101，表示8个线圈的状态依次为：线圈0=1，线圈1=0，线圈2=1，线圈3到7=0。Modbus协议规定，位状态按“bit位”打包时，最低位对应起始地址。这一点很关键，不然你解析出的开关状态会全部错位。我调试过一台设备的状态反馈，读出来总是反的，后来才发现是自己在解析时把高低位搞反了。

如果要写单个线圈，用功能码05。数据区只有两个字节，但协议要求，线圈状态只有两种合法值：

• FF 00 表示置ON
• 00 00 表示置OFF

这个设计相当反直觉，很多人初次接触时会问为什么不能直接写01。协议里这么定义，是为了防止某些传输通道把0x01当作控制字符处理。所以你自己写上位机程序时，写DO的报文一定要用FF 00，不能图省事用00 01，否则有些设备会返回异常码03。

4.2 03/04：读寄存器的报文和返回

读保持寄存器和读输入寄存器，报文格式完全一致，功能码不同。以读1号从站，从寄存器地址0000开始读2个寄存器为例：

请求：01 03 00 00 00 02 C4 0B 响应：01 03 04 00 0B 00 32 67 E0

响应数据区“04”表示后面有4个字节，也就是2个寄存器，每个寄存器2个字节。后面是“00 0B”和“00 32”，分别代表寄存器1的值是11（十进制），寄存器2的值是50（十进制）。

这里需要特别强调寄存器值的“字节序”。Modbus协议规定，寄存器内的数据是“高字节在前”，也就是大端序。例如一个寄存器的值是0x1234，发送时先发12，再发34。绝大多数标准Modbus设备都遵循大端序，但总有一些非标设备或协议转换器会在里面做小端处理，导致上位机读到的值被拆成两个字节后高低位互换。如果遇到读出的数值明显异常（比如本该是50，变成了12800），优先怀疑字节序问题，尝试在配置里把“字节顺序”改成高字节在前或低字节在前。

读取数量也有讲究。许多从站设备有最大读取数量的限制，比如某些电能表一次最多允许读120个寄存器。如果你一次读125个，设备会回异常码03“非法数据值”。这时候不要觉得协议允许就硬刚，正确做法是分批读取，每次控制在设备允许的范围内。

4.3 05/06/0F/10：写操作报文

写单个寄存器用06，这个前面已经举例。写多个保持寄存器用功能码10，报文结构稍微复杂一点。例如要向1号从站地址0000开始写2个寄存器，值分别为0x0001和0x0002，报文如下：

请求：01 10 00 00 00 02 04 00 01 00 02 EA 5C

数据区拆解：

• 00 00：起始寄存器地址
• 00 02：寄存器数量
• 04：后续数据的字节数（寄存器数量 × 2）
• 00 01：第一个寄存器的值
• 00 02：第二个寄存器的值

跟读操作不同，写多个寄存器的响应不是把整个数据区回显，而是回显“从站地址 + 功能码 + 起始地址 + 寄存器数量 + CRC”。所以上面这帧的响应是：

01 10 00 00 00 02 41 CB

当然，不同厂商的设备在异常情况下可能不回标准响应，但正常情况下都是这个格式。我在调试中遇到过一种“伪成功”情况：上位机发送了写命令，收到了正常响应，但设备里的值根本没变。后来查出来是同一个寄存器被组态软件另一路周期任务反复改写了，两个任务打架。这类问题不纯粹是报文层面的，但也提醒我们，看到报文正常不一定代表逻辑正确，要结合整个系统的读写关系去判断。

4.4 异常响应报文怎么看

设备收到请求后，如果发现这条报文有问题，会回一帧异常响应。异常响应的特征非常明显：功能码的最高位置1。比如你发了03读寄存器，设备回的是83，这个83就是异常标志；接着一个字节是异常码，表示具体错误类型。

常见的异常码：

• 01：非法功能码。说明设备不支持你发的这个功能码。
• 02：非法数据地址。说明地址不存在或超出范围。
• 03：非法数据值。说明数据值不合法，比如写线圈时用了非法的数据、读取数量超出限制。
• 04：从站设备故障。说明设备本身出问题了，比如硬件故障、内部存储错误。

现场排查通信故障时，一定要先看有没有异常响应。很多“通信超时”其实是设备回了异常码，但程序里没做异常处理，直接当作超时。如果你能抓到异常帧，问题一下就缩小了：不是通信链路断了，而是请求报文内容不符合设备预期。这时候去查手册、改报文，比折腾线缆和波特率有效得多。

5. CRC16校验：手算和代码实现都给你捋清楚

5.1 校验原理与手算过程

CRC16/Modbus的计算过程可以概括为这几步：

1. 预置一个16位寄存器为0xFFFF。
2. 将报文第一个字节与16位寄存器的低8位异或，结果放回这个寄存器。
3. 把这个寄存器右移一位，最高位补0。检查移出的最低位，如果是1，就把寄存器与多项式0xA001异或；如果移出的是0，就继续下一次移位。
4. 重复第3步8次。
5. 处理完一个字节后，取报文下一个字节，重复第2到第4步。
6. 所有字节处理完后，得到的16位寄存器值就是CRC校验值。

注意这里用的多项式是0xA001，其实是0x8005的“反向多项式”。Modbus标准采用的就是这个反向算法，所以很多资料上写的多项式是0x8005，但代码实现里却是0xA001。如果你自己写算法时直接拿0x8005去算，算出来的结果肯定对不上。

拿“01 03 00 00 00 02”这段数据手推一遍，最终算出的CRC是0x0BC4，发送时按低字节在前变成C4 0B。这就是我前面反复强调的发送顺序问题。

5.2 查表法和位运算法代码

自己写程序的时候，CRC计算通常有两种实现：一种是位运算循环，简单直观，但速度稍慢，适合数据量小的场合；一种是查表法，速度极快，适合通信频率高的应用。下面这版是我常用的查表法C代码风格，可以直接移植到PLC、嵌入式控制器里：

static const unsigned char crc_hi_table[] = { 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, // 中间省略完整256项 }; static const unsigned char crc_lo_table[] = { 0x00, 0xC0, 0xC1, 0x01, 0xC3, 0x03, 0x02, 0xC2, 0xC6, 0x06, 0x07, 0xC7, 0x05, 0xC5, 0xC4, 0x04, // 中间省略完整256项 }; unsigned short crc16_modbus(unsigned char *buf, unsigned short len) { unsigned char crc_hi = 0xFF; unsigned char crc_lo = 0xFF; unsigned short crc; for (unsigned short i = 0; i < len; i++) { unsigned char index = crc_hi ^ buf[i]; crc_hi = crc_lo ^ crc_hi_table[index]; crc_lo = crc_lo_table[index]; } crc = (crc_hi << 8) | crc_lo; return crc; }

查表法的核心思想是预先把每种可能的多项式计算结果存在表里，运行时直接用当前字节查表替代繁重的异或移位循环。这里的高低位表是按Modbus反向算法预先算好的，实际项目里可以直接用现成表格。如果你用Python写调试脚本，也可以用下面的位运算版本，判断逻辑更直观：

def crc16_modbus(data: bytes) -> int: crc = 0xFFFF for b in data: crc ^= b for _ in range(8): if crc & 0x0001: crc = (crc >> 1) ^ 0xA001 else: crc >>= 1 return crc # 测试：01 03 00 00 00 02 应该得到 0x0BC4 data = bytes.fromhex("01 03 00 00 00 02") print(hex(crc16_modbus(data)))

如果输出结果是0x0bc4，说明算法没问题。发送时记得先把低字节发出去：crc & 0xFF，再发高字节：crc >> 8。这个顺序一错，整个帧就会被从站判为坏帧。

5.3 CRC校验中的常见坑

第一个坑就是字节顺序。很多工程师用自己的校验工具算出一个CRC值，比如算出来是0x0BC4，直接按这个顺序填到报文末尾，结果调试一直失败。解决办法是把低位和高的位置互换，变成C4 0B。这个坑我踩过不止一次。

第二个坑是计算范围。CRC只计算“从站地址 + 功能码 + 数据区”，不包含报文末尾的CRC本身，也不包含起始符和结束符（RTU模式下）。有些人在校验时把整帧都算进去，结果当然对不上。

第三个坑是计算前的初值。Modbus标准要求CRC寄存器初始化为0xFFFF，不是0x0000。如果你用的是网上找的通用CRC16算法，初始值、多项式、输入反转、输出反转这些参数都对应不上，算出来的结果必然错误。所以最好直接用“CRC-16/Modbus”这种名称明确标注的算法实现，而不是泛泛的CRC16。

另外提一句，RTU模式除了CRC校验之外，还有一个帧间隔要求：报文之间至少要留出3.5个字符时间的静默间隔。有些工程师压缩发送时间，把多帧报文连在一起发出去，从站无法正确识别帧边界，就会把所有数据当成一帧，导致解析完全乱套。

6. 报文排查实战：从抓到的一串数据定位故障

6.1 调试工具怎么选

排查Modbus报文，工具可以按场景分几档：

• 串口调试助手：适合手写报文、观察原始十六进制收发，最简单但功能有限。
• Modbus Poll / Modbus Slave：上位机模拟主站或从站，能配置参数、自动轮询，适合验证设备是不是正常回话。
• 串口监听工具：在PLC或触摸屏与设备之间串接，无感监听线上的真实流量，适合排查现网问题。
• Wireshark抓包：带过滤条件，直接看TCP层报文，定位Modbus TCP通信问题时最好用。
• 逻辑分析仪/示波器：排查物理层信号质量时用，可以看到波形畸变、反射、毛刺。

我的习惯是先用串口调试助手验证报文本身对不对，再用Modbus Poll验证连续通信稳定性。这两步能快速区分问题出在“报文内容”还是“链路质量”。如果报文内容完全正确，但用Poll轮询时周期性地丢帧，那就得检查线缆、接地、终端电阻这些现场因素了。

6.2 一帧“无响应”报文怎么查

假设主站发了一帧请求，从站没有任何响应。按照下面这个顺序排查，基本能把问题压缩到具体环节：

1. 确认物理链路：用万用表量A/B线电压，485空闲时A比B高2到6伏。如果电压不对，检查接线和终端电阻。
2. 确认参数一致：波特率、数据位、停止位、校验位必须一致。尤其校验位，有的设备设成无校验，有的设成偶校验，不一致时从站根本收不到完整帧。
3. 确认地址匹配：主站请求里的从站地址和设备拨码地址一致。
4. 确认功能码支持：查看手册，确认设备是否支持该功能码。
5. 确认地址范围：寄存器地址是不是越界了，或者寄存器类型对应错了。
6. 抓包看异常响应：很多设备收到错误请求时并不会沉默，而是回异常码。如果你把异常码当“无响应”，就永远找不到真正原因。

举个例子，我现场遇到过一台上位机读温控器，发的是“01 04 00 01 00 01”，温控器一直没动静。用串口监听一看，设备其实回了“81 02 C0 F1”这类异常帧，其中81表示功能码04异常，02表示非法数据地址。查手册才发现，这台温控器的输入寄存器地址是从0开始，不是1。把请求里的起始地址改成00 00，通信立刻恢复。这就是报文排查的价值。

6.3 通信时好时坏：不要光盯着报文

报文格式正确，但通信仍然时好时坏，这是现场最磨人的情况。此时往往不是报文内容的问题，而是物理层的几个典型因素：

• 接地问题：屏蔽层单端接地还是双端接地、有没有形成地环路，都可能引入干扰。
• 终端电阻缺失：485总线两端没接120欧终端电阻，信号在末端反射，长距离通信时会出现随机错帧。
• 线缆过长或拓扑不当：485要求手拉手菊花链，如果现场接了星型拓扑，反射严重。
• 波特率与距离不匹配：9600能跑很远，19200或更高就不一定了，距离长时按保守参数设置。
• 共模电压过高：收发器共模电压超出范围，可能导致芯片间歇性损坏或通信不稳定。

在这些因素里，CRC校验率是很好的判断指标。如果一帧帧抓下来，随机出现的CRC错误占比较高，基本可以判定是物理层问题而不是协议问题。很多工程师遇到这种情况反复调软件参数，搞到最后才发现接地没做好，白白浪费几天时间。

6.4 超时参数和重试策略

主站程序里跟报文直接相关的还有两个参数：超时时间和重试次数。超时时间太小，从站还没处理完，主站就放弃了；太大，故障时会拖慢整个轮询周期。一般建议根据从站响应速度设置，大多数设备响应时间在10到50毫秒左右，超时时间设500毫秒到1秒都算合理。

重试策略要谨慎。通信失败立即重试是很多程序的默认行为，但在现场，如果从站因为内部故障一直回异常码，重试只会加重总线负担，还会拖垮整条链路里其他设备的通信。我见过一套系统，主站每200毫秒轮询一次，某个从站故障后开始疯狂重试，结果其他设备全部跟着报超时。后来把重试次数限制为1次，失败后把该从站标记为离线，不再重试，整个系统立刻恢复了稳定。记住一个原则：报文协议解析是基础，但通信策略直接决定系统的健壮性。

6.5 抓包工具里看TCP报文实例

用Wireshark抓Modbus TCP包时，你会看到请求和响应帧成对出现。一帧请求的结构在软件里会解析成：

Modbus/TCP Transaction Id: 0x0001 Protocol Id: 0x0000 Length: 6 Unit Id: 1 Function Code: 3 (Read Holding Registers) Starting Address: 0x0000 Quantity of Registers: 0x0002

这里Length是6，怎么来的？从Unit Id开始，Unit Id占1字节，Function Code占1字节，加上Starting Address占2字节，Quantity占2字节，总共6，正确。如果你自己组帧时把这个Length算错，对端网关或从站可能直接丢弃，或者解析错位。看到这个解析界面时，你可以对照自己组装的十六进制报文，一个字段一个字段核对，很快就能发现是哪一段出了问题。

7. 写报文的一些个人经验总结

这些年在几个项目里调试了各种带Modbus接口的设备，从智能电表、温控器到变频器、称重仪表，碰过的坑加起来能写一屏。最后分享几个我从实际教训里总结出来的习惯。

对接新设备的第一件事，永远是查手册里的寄存器映射表，看地址是几进制的、寄存器类型是保持寄存器还是输入寄存器、数据是16位还是32位。很多仪表用十六进制表示地址，组态软件里填的是十进制，换算时差一点都会导致数据错位。尤其是32位浮点数，两个寄存器拼一个浮点，字节序和字序有四种排列方式，报文看着对，数字却是天文数字。我的经验是先读一个已知值，比如铭牌上的额定电压，倒推数据格式，比对着文档猜靠谱得多。

手写报文时养成用调试助手先验证的习惯，避免直接改PLC程序。先用串口调试助手把请求帧发出去，看返回帧是不是符合预期，CRC对不对。报文验证通了，再把这些参数填进程序里。这样能省去很多在程序里反复下载调试的时间。

最后一条，把每一次成功调通的报文记录下来，包括设备型号、功能码、寄存器地址、数据格式、CRC。现场设备那么多，你不可能记住每一台设备的参数，但有了存档，下次遇到同型号设备，直接调出来用，效率翻倍。我自己就建了个报文笔记，按设备型号分类，这么多年攒下来，已经成了调试时翻得最多的一本手账。