简介《Modbus通讯功能码及实例.pdf》是一份面向工业自动化初学者、PLC与嵌入式通信开发者的速查手册聚焦Modbus功能码含义与报文构造这一常见难点。文档以表格化方式梳理01至19号等常用功能码说明读取线圈、输入状态、保持寄存器、输入寄存器以及强置单线圈、预置单寄存器、强置多线圈、预置多寄存器等操作并补充异常状态、回送诊断、报告从机标识等辅助功能同时配合读写数字量、模拟量的命令与响应实例逐项拆解设备地址、起始地址、寄存器数量、数据字节及CRC高低字节顺序帮助读者理解主从站交互过程与报文解析思路。压缩包仅含1个PDF文件约10KB篇幅精炼便于打印或随查随用。目前已有2332人学习适合需要快速核对功能码、排查通信报文或准备课程实验的读者参考。1. 从一条超时的读寄存器请求说起柜子上的通信灯还在闪上位机发出去的读保持寄存器请求一条条超时抓回来的报文里功能码是0x83——从站明确说这条请求它不认。刚接 485 现场的人基本都撞过这堵墙报文看着没毛病可设备就是不回。这份《Modbus 通讯功能码及实例》PDF 解决的就是这个卡点它把 Modbus 功能码从 01 到 21 号逐个列清楚再用 01、02、03、04、05、06 六个高频功能码给出完整的请求帧和响应帧每个字节代表什么、取值范围多少、什么时候置零都跟着报文一起标注。它适合三类人照着报文调柜子的电气工程师、自己组帧写采集程序的上位机开发者、被地址偏移和功能码选型绕晕的设备对接人员。读完至少能判断一条帧该多长、回来的数据哪一位对应哪个开关。2. 功能码全景选型01 到 21 哪些能上手哪些是历史包袱市面上讲 Modbus 的资料多数只列 01 到 06 六个功能码就收尾剩下十几个要么一笔带过要么干脆不提。真到现场对点表的时候你会碰到只实现 04 不实现 03 的仪表也会碰到用 15 号功能码批量写线圈的控制器这时候靠猜是不行的。这份文档的价值在于它把 21 个功能码全部摊开包括那些只在老一代控制器上出现、现代设备根本不会实现的条目让你在拿到一份陌生点表时能快速判断这个功能码属于常规读写属于诊断类还是属于早就没人维护的历史包袱。选型这件事的本质是先搞清楚你要操作的是哪张数据表再决定用哪个功能码。功能码不是随便挑的它和 Modbus 的四张数据表严格绑定选错表的后果不是数据错而是从站直接甩一个异常码回来。2.1 四张数据表划定了功能码的边界Modbus 把从站的数据抽象成四张互相独立的表每张表有自己的地址空间互不重叠。线圈是可读写的位离散输入是只读的位输入寄存器是只读的 16 位字保持寄存器是可读写的 16 位字。落到功能码上01 读线圈、02 读离散输入、03 读保持寄存器、04 读输入寄存器、05 写单线圈、15 写多线圈、06 写单寄存器、16 写多寄存器。八个功能码四种操作类型两种数据宽度组合得干干净净。地址这块有个常见的认知差。设备手册里写的 40001、40002 这类编号是给人看的带区号前缀报文里传的起始地址是从 0 开始算的偏移量。所以手册上的 40001 对应报文里的0x000040011 对应0x000A。文档里给的实例是[11][03][00][6B][00][03]起始地址0x006B就是十进制 107如果设备手册上标的是 40108那正好对上。这一步换算要是搞反了你会稳定地读到隔壁寄存器的值而且看起来还挺合理属于最难查的那类问题。四张表的只读/可写属性也是硬约束。02 和 04 只能读你拿 05 去写离散输入从站一定回异常。反过来很多设备的保持寄存器区会被厂商塞进大量只读的状态量虽然协议上允许写但设备固件不认写进去不报错、值也不变这种就得靠点表提前确认。2.2 六个高频功能码怎么选文档里明确说 1、2、3、4、5、6 号功能码使用最频繁用它们就能完成对下位机数字量和模拟量的读写。这句话在现场基本成立绝大多数温控表、变频器、电表、IO 模块用这六个功能码就能把数据全采上来。功能码名称操作对象数据宽度请求帧长响应帧长01读线圈状态可读写位位8 字节5 N 字节02读输入状态只读位位8 字节5 N 字节03读保持寄存器可读写字16 位8 字节5 2N 字节04读输入寄存器只读字16 位8 字节5 2N 字节05强置单线圈可读写位位8 字节8 字节回显06预置单寄存器可读写字16 位8 字节8 字节回显15强置多线圈可读写位位9 N 字节8 字节16预置多寄存器可读写字16 位9 2N 字节8 字节N 在 01/02 里是ceil(数量 / 8)即数据字节数在 03/04 里是寄存器个数。这张表看着简单但排错时极其有用你发出去 8 个字节回来的帧长是 5 还是 52N一眼就能判断响应是不是被截断了。串口读超时设得太短返回的帧少了一两个字节CRC 必错很多人第一反应是波特率不对实际是读长度没算对。写操作为什么要分单个和多个因为 05/06 的响应是从站把请求原样回显主站只要逐字节比对就知道写没写成不需要额外的回读。而 15/16 的响应只回地址、功能码、起始地址和数量不携带数据写完到底生效没有得靠再读一次确认。这是两条完全不同的确认路径选型时要想清楚你的设备支不支持回读。2.3 07 到 21 号诊断类与老机型专属07 号读异常状态取的是 8 个内部线圈的通断状态这 8 个线圈的地址由控制器自己决定不在标准地址空间里所以换个厂家的设备这 8 位的含义就全变了。08 号回送诊断校验把诊断报文送给从站做通信处理评估这条功能码带子功能码常用来做链路自检。11 号读事件计数、12 号读通信事件记录用途是检索从站的事务处理日志通信出错时能拿到记录。13、14、18、19 这几条要特别注意。文档里标注了它们分别用于 484、184/384/484/584、884 和 MICRO 84 这类机型编号指的是早期某一代可编程控制器的系列代号。09 和 10 号同样是这批老设备上的编程和探询功能原文写得很直白09 号让主机模拟编程器去改从机逻辑10 号用来探询正在执行长程序的从机是否完成而且 10 号必须在含 09 号的报文发出之后才能发。这种强顺序依赖在现代设备上基本见不到你要是按现代协议的思路去理解很容易以为 10 号是个独立的查询命令。20 和 21 号读写通用参数针对的是扩展存储器文件也是特定机型的功能。17 号报告从机标识倒是通用性稍好一些响应里带从站类型和运行指示灯状态做设备自动识别时能用上但不少设备对这个功能码返回异常实现率并不高。2.4 保留段与异常响应怎么读22 到 64 是留给扩展功能的65 到 72 留给用户自定义73 到 119 是非法功能码120 到 127 内部保留128 到 255 用于异常应答。异常应答的规则是把请求功能码的最高位置 1也就是加上0x80。请求 03 出异常回来就是0x83请求 01 出异常回来是0x81。这个设计很省事主站收到响应先看功能码最高位就知道是正常数据还是错误报告。异常帧的长度固定 5 字节从站地址、功能码加 0x80、异常码、CRC 低、CRC 高。异常码里 01 表示非法功能02 表示非法数据地址03 表示非法数据值04 表示从站故障05 表示确认06 表示从站忙08 表示存储奇偶错0A 表示网关路径不可用0B 表示网关目标设备无响应。现场遇到最多的是 02 和 0302 基本是地址或数量越界03 往往是写入的值超出设备允许范围比如给一个量程 0 到 600 的温度寄存器写了 1000。提示异常响应不带数据域长度和正常响应完全不同。如果你的读函数按固定长度取帧异常帧会因为少读了后面的字节而一直阻塞到超时最后报出来的错误是超时而不是异常码排错方向直接被带偏。3. 报文逐字节拆解把[11][01][00][13][00][25]还原成 37 个开关量看懂功能码表格只是第一步真正要动手的时候你得知道每个字节该填什么。这份文档后半部分的价值就在这里它没有停留在01 号用于读线圈这种描述上而是把请求帧和响应帧完整列出来连CRC 校验在命令中的高低字节顺序和其他的相反这种细节都点了出来。这一句能省掉新手至少半天时间。3.1 请求帧与响应帧的字段骨架以 01 号读线圈为例请求帧是 8 个字节设备地址 1 字节、功能码 1 字节、起始地址高 8 位、起始地址低 8 位、读取数量高 8 位、读取数量低 8 位、CRC 低 8 位、CRC 高 8 位。文档给的例子是[11][01][00][13][00][25][CRC低][CRC高]拆开看设备地址0x11是十进制 17说明这条命令发给 17 号从站功能码0x01起始地址0x0013是十进制 19读取数量0x0025是十进制 37。所以这条命令的意思是17 号从站从第 19 号开关开始读 37 个开关量。响应帧的结构不同设备地址、功能码、返回的字节个数、数据 1 到数据 n、CRC 低、CRC 高。例子是[11][01][05][CD][6B][B2][0E][1B][CRC低][CRC高]字节个数0x05表示后面跟着 5 个数据字节。37 个开关量需要ceil(37/8) 5个字节对得上。这个字节个数字段是校验响应完整性的第一道关你请求 37 个位回来的字节数不是 5直接可以判定帧有问题不用等 CRC 算完。03 号读保持寄存器的骨架和 01 几乎一样区别在响应。请求[11][03][00][6B][00][03][CRC低][CRC高]起始地址 107读 3 个寄存器。响应是[11][03][06][02][2B][00][00][00][64][CRC低][CRC高]字节个数0x06因为一个模拟量占两个字节3 个寄存器就是 6 个字节。数据段按高字节在前排列[02][2B]是第一个寄存器的值 555[00][00]是 0[00][64]是 100。这里的高字节在前指的是寄存器内部的字节顺序和 CRC 的低字节在前不是一回事两套规则同时存在于一帧里是初学时最容易混淆的地方。3.2 位打包规则与最后一字节的高位补零读线圈的响应数据是按位打包的每个字节装 8 个开关量字节内的最低位对应起始地址。文档里写得很清楚每一位为 0 表示对应的开关断开为 1 表示闭合。拿0xCD这个字节验算一下二进制是1100 1101按最低位对应起始地址 19 展开第 0 位是 1地址 19 闭合第 1 位是 0地址 20 断开第 2 位是 1地址 21 闭合第 3 位是 1地址 22 闭合第 4 位是 0地址 23 断开第 5 位是 0地址 24 断开第 6 位是 1地址 25 闭合第 7 位是 1地址 26 闭合。这和文档里20 号开关闭合21 号断开22 闭合23 闭合24 断开25 断开26 闭合27 闭合的描述完全一致只是文档用的是从 1 开始的编号。最后一字节的处理是个细节坑。37 个位只占 5 个字节的前 37 位第 5 个字节0x1B只有低 5 位有意义高 3 位必须置 0。文档明确写了如果询问的开关量不是 8 的整倍数那么最后一个字节的高位部分无意义置为 0。解析的时候不能把这 3 位也当数据用否则你会凭空多出三个开关状态。反过来写测试用例时如果构造的响应里最后一字节高位不为 0严格实现的主站可能会判帧非法。def unpack_bits(payload: bytes, start_addr: int, count: int): 把 01/02 响应中的数据字节展开成 (地址, 状态) 列表 result [] for i in range(count): byte_index, bit_index divmod(i, 8) # 第几个字节、字节内第几位 bit (payload[byte_index] bit_index) 0x01 # 低位对应起始地址 result.append((start_addr i, bit)) return result # 用文档中的实例验证起始 19读 37 个 data bytes.fromhex(CD6BB20E1B) for addr, val in unpack_bits(data, 19, 37)[:8]: print(addr, val)这段代码的关键在divmod(i, 8)i是从起始地址算起的第几个开关除以 8 得字节下标余数是字节内的位下标。 bit_index 0x01用的是最低位优先的取法和 Modbus 的位打包顺序一致。参数start_addr是报文里的起始地址count是请求的数量两者必须和请求帧保持同步否则展开出来的地址会整体偏移。3.3 CRC-16/MODBUS 的算法与高低字节顺序CRC 校验覆盖从设备地址到数据末尾的全部字节不包括 CRC 本身。算法参数是初值0xFFFF、多项式0xA001这是0x8005的反向表示、输入输出都不反转、不做最终异或。算完之后直接取低字节先发、高字节后发。文档里那句CRC 校验在命令中的高低字节的顺序和其他的相反说的就是这件事。报文里的地址、寄存器值都是高字节在前唯独 CRC 是低字节在前。很多 CRC 计算工具默认输出高字节在前直接贴进报文就错而且错得很隐蔽CRC 数值本身是对的只是两字节顺序颠倒校验方算出来的值和你发出去的值不一样报错却指向校验失败看不出是顺序问题。def crc16_modbus(data: bytes) - bytes: 计算 Modbus RTU 的 CRC16返回低字节在前的两字节 crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 # 右移后异或反向多项式 else: crc 1 return bytes([crc 0xFF, (crc 8) 0xFF]) # 低字节在前 frame bytes.fromhex(110100130025) print(crc16_modbus(frame).hex()) # 直接拼到 frame 后面就是完整请求帧函数返回的是bytes而不是整数这是故意的只有在返回时就固定好低字节在前调用方拼接报文时才不会再次搞反。第 4 章的收发函数都复用这个实现校验响应时用同样的函数算resp[:-2]再和resp[-2:]逐字节比对顺序自然就对上了。3.4 三条实例报文的验算路径文档给了 01、03、05、06 四类实例手工验算时按固定顺序走一遍就行。先数长度01 请求 8 字节、响应 5 加数据字节数03 请求 8 字节、响应 5 加两倍寄存器数05 和 06 的请求和响应都是 8 字节且完全对称。长度不对后面的都不用算。再看功能码最高位。响应帧的第二个字节如果大于0x80说明是异常帧只有 5 字节直接跳到异常码解析不要按正常响应的长度去读。然后看字节数字段01 响应的第三个字节应该等于ceil(数量/8)03 响应的第三个字节应该等于寄存器数乘 2不一致就是帧被截断或者从站实现有问题。最后才校验 CRC。以 05 号写单线圈[11][05][00][AC][FF][00][CRC低][CRC高]为例地址0x00AC是十进制 172数据域0xFF00表示闭合。文档特别强调这里只可以是[FF][00]表示闭合、[00][00]表示断开其他数值非法。这一条要记死第 5 章会专门讲写成[00][01]的后果。写成功时从站把这条命令原样返回八个字节一模一样写失败或者地址越界从站要么不响应要么回异常帧不会回一个部分成功。4. 手搓一个最小主站01/03/05/06 四类读写的可复现脚本拿一份现成的 Modbus 库当然快但库把组帧和解析都封在黑匣子里一旦现场出问题你很难判断是库的问题还是设备的问题。我一般建议至少自己手写一遍最小主站把组帧、发送、收帧、校验四步走通之后再换库也就是换个调用方式的事。这一章用pyserial做串口收发不依赖任何 Modbus 专用库代码量很小但每一步都能对上文档里的报文结构。pip install pyserial装完之后先确认端口能打开。Windows 下是COM3这种名字Linux 下是/dev/ttyUSB0。用 USB 转 485 的时候注意驱动装没装设备管理器里能看到端口号才算通。4.1 串口参数与半双工时序Modbus RTU 最常见的参数是 9600 波特率、8 数据位、无校验、1 停止位也就是常说的 8N1。也有设备用 19200 或 115200还有用偶校验的具体看设备手册参数不匹配的表现是一个字节都收不到或者全是乱码。半双工是 485 的物理特性同一时刻只能有一个方向在发。USB 转 485 模块一般自带方向控制主站只管写数据就行。真正要注意的是帧间隔Modbus RTU 规定帧内字符间隔不超过 1.5 个字符时间帧与帧之间至少静默 3.5 个字符时间。9600 波特率下一个字符 11 位3.5 个字符约 4 毫秒。主站连续发两条命令时如果中间不等待从站可能把两条粘成一帧解析出来的结果是彻底乱的。import serial import struct import time def open_port(port: str, baud: int 9600) - serial.Serial: return serial.Serial( portport, baudratebaud, bytesize8, parityserial.PARITY_NONE, stopbits1, timeout0.5, # 读超时要大于从站最大响应时间 ) def transact(ser: serial.Serial, req: bytes, expect_len: int) - bytes: ser.reset_input_buffer() # 清掉上一帧残留避免错位 ser.write(req) ser.flush() time.sleep(0.005) # 9600 下 3.5 字符约 4ms留一点余量 resp ser.read(expect_len) if len(resp) 5: raise TimeoutError(f响应不足 5 字节: {resp.hex() or 空}) if crc16_modbus(resp[:-2]) ! resp[-2:]: raise ValueError(fCRC 校验失败: {resp.hex()}) return resptimeout0.5这个值决定了单次读取最多等多久。设太短从站还没处理完就返回读到半截帧设太长一个掉线的从站会让整个轮询周期卡住。常见做法是按设备手册给的最大响应时间再加 50% 余量。reset_input_buffer()不能省尤其是上一轮超时之后缓冲区里可能还留着半帧垃圾数据不清掉的话下一帧读出来就是从中间开始的CRC 必错。expect_len由调用方按功能码算好传进来这是第四章后面几节的核心。4.2 读类请求01 和 03 的构造与响应长度推算03 号读保持寄存器是最常用的功能码先把这条走通其他都是变体。请求帧 8 字节响应长度是 5 加两倍寄存器数。注意struct.pack(HH, start, count)里的表示大端也就是高字节在前这正好对上 Modbus 报文的字节序约定。def read_holding(ser, slave: int, start: int, count: int) - list: req bytes([slave, 0x03]) struct.pack(HH, start, count) req crc16_modbus(req) expect 5 count * 2 # 地址功能码字节数数据CRC resp transact(ser, req, expect) if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) n resp[2] # 从站返回的字节数 return list(struct.unpack(f{n // 2}H, resp[3:3 n]))slave是从站地址取值 1 到 2470 是广播地址广播只写不读所以读操作永远不要用 0。start是从 0 开始的寄存器偏移不是手册上的 40001 编号。count是寄存器个数1 到 125 之间超过 125 从站一般回异常 03。响应里的resp[2]是字节数而不是寄存器数struct.unpack之前要先除以 2这个换算忘了的话 unpack 出来的长度对不上会直接抛异常。01 号读线圈的构造逻辑一样只是响应长度按位算而且返回的是原始字节需要再展开成位。def read_coils(ser, slave: int, start: int, count: int) - list: req bytes([slave, 0x01]) struct.pack(HH, start, count) req crc16_modbus(req) expect 5 (count 7) // 8 # 向上取整得到数据字节数 resp transact(ser, req, expect) if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) data resp[3:3 resp[2]] return unpack_bits(data, start, count) # 复用第 3 章的展开函数(count 7) // 8是向上取整的经典写法比math.ceil少一次函数调用读 37 个位算出来是 5和文档实例完全一致。这里面还有个隐含前提从站返回的字节数必须等于请求推算的长度如果不相等transact里的 CRC 校验会失败因为帧被截断或者多读了后续帧的字节。4.3 写类请求05 的 FF00 与 06 的回显校验写单线圈只认两个值0xFF00表示闭合0x0000表示断开。文档里那句只可以是[FF][00]表示闭合、[00][00]表示断开其他数值非法是针对 05 号的硬规定写成0x0001有些设备会回异常 03有些设备干脆不响应。写单寄存器 06 没有这个限制数据域就是目标值的 16 位表示。这两个功能码的响应都是请求原样回显所以校验方式很直接收到的 8 个字节和发出去的 8 个字节逐字节比对一致就算成功。这比读操作简单但也要注意异常响应的情况回显校验之前先看功能码最高位。def write_coil(ser, slave: int, addr: int, on: bool) - bool: value 0xFF00 if on else 0x0000 # 05 号只认这两个值 req bytes([slave, 0x05]) struct.pack(HH, addr, value) req crc16_modbus(req) resp transact(ser, req, 8) if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) return resp req # 原样回显才算成功 def write_register(ser, slave: int, addr: int, value: int) - bool: req bytes([slave, 0x06]) struct.pack(HH, addr, value 0xFFFF) req crc16_modbus(req) resp transact(ser, req, 8) if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) return resp reqreq bytes([slave, 0x05]) ...这种拼法看起来土但好处是每一段都能和文档里的字节位置对上调不通的时候打印req.hex()就能逐字节核对。value 0xFFFF是防御性写法负数或者超过 65535 的值会在这里被截断不过更稳妥的做法是在调用前就做范围检查因为静默截断会让写入的值和预期不符。4.4 异常响应与超时的区分处理异常响应和超时是两个完全不同的失败排错方向也完全不同所以代码里必须分开处理。异常响应说明从站收到了请求、解析了、拒绝了问题在请求内容上超时说明从站压根没回问题在物理层、地址、波特率或者从站根本没实现这个功能码。transact里读到少于 5 个字节就抛TimeoutError这是超时分支。读到完整帧但功能码最高位为 1这是异常分支resp[2]直接给出异常码。剩下的分支才是正常数据。三个分支分清楚现场排错时看异常类型就能定位到大概方向不用从头猜。还有一类情况要单独提从站回了一个长度正确、CRC 正确、功能码也正常的帧但数据明显不对比如读温度读出来 32767。这不是通信问题是数据解析问题多半是数据格式没对上可能是定点数的小数位没除也可能是 32 位数据跨了两个寄存器而字序搞反了。这类问题在通信层查不出来得回到设备的点表去看。5. 避坑与排查五条从现场抄回来的翻车记录协议文档给的是规范现场踩的坑往往在规范的边缘。文档里已经点出了几个关键细节比如 CRC 高低字节相反、05 号只认 FF00 和 0000但真正吃过亏之后才会记住。这一章把最常见的五类问题按现象、原因、解决三段拆开都是照着这份功能码表能直接对上号的。5.1 CRC 永远校验不过但报文肉眼看着没问题现象主站发出去的帧从站一律不响应或者从站回了帧但本地校验报 CRC 错。把报文贴到在线 CRC 工具里算算出来的值和报文里带的对不上。原因CRC 数值算对了但发出去的时候字节顺序反了。很多 CRC 工具默认输出高字节在前而 Modbus RTU 要求低字节在前。文档里那句CRC 校验在命令中的高低字节的顺序和其他的相反说的就是这件事但第一次看很容易略过去。解决把 CRC 计算函数固定成返回低字节在前的bytes拼接和校验都走同一个函数不要在两处各写一遍。已经发出去的帧可以用抓包工具截下来单独对前 N-2 个字节重算一次 CRC比对两个字节的顺序反了就是这个问题。5.2 地址对不上读出来的值稳但不准现象读保持寄存器起始地址按手册上的 40001 填成 40001从站回异常 02改成 0 之后能读了但读出来的数值明显是隔壁参数的。原因手册编号和报文偏移差 1而且不同厂家对 4 区起始编号的定义还有差异有的从 40001 开始算有的从 40000 开始算。文档里的实例[11][03][00][6B][00][03]起始地址0x006B是十进制 107如果设备手册上标的是 40108说明这个厂家的 4 区是从 40001 对应偏移 0。解决拿到点表先做一次单点校验挑一个已知值的寄存器读出来比对确认偏移基准之后再批量采。别一上来就按偏移量铺开几百个点错了之后改起来是灾难。5.3 写线圈命令回显正常但继电器不动现象05 号功能码发出去从站原样回显回显校验通过代码认为写成功了可现场设备一点反应没有。原因数据域写成了0x0001而不是0xFF00。有些从站对非法值不报异常只是忽略回显照做于是主站收到成功实际什么都没发生。解决写线圈的值只有两种闭合0xFF00、断开0x0000用布尔值映射而不是直接传 1 和 0。写完如果设备还是不动用 01 号功能码回读一次线圈状态确认从站内部的状态到底变没变这一步能区分是写没进去还是写进去了但执行机构有问题。5.4 偶发超时重发一次就好现象轮询几十个从站每隔几分钟就有一两条超时重发立刻成功日志里 CRC 错误和超时交替出现。原因帧间隔不够主站上一帧刚发完就发下一帧从站还在处理上一条或者 485 总线上的方向切换有延时第一个字节被吃掉也可能是总线上有多个主站或者干扰导致某帧损坏。解决在transact里加固定静默9600 波特率下至少 4 毫秒把读超时从 0.1 秒放宽到 0.5 秒给重试次数设上限通常 2 到 3 次超过就记一条错误日志跳过这个从站别让一条坏链路拖垮整个轮询周期。5.5 读上来的数值是负数或者翻了几倍现象03 号读两个寄存器拼一个 32 位浮点读出来的值有时候是对的有时候符号反了有时候数量级差 256 倍。原因32 位数据跨两个寄存器时字序和字节序有四种组合设备端定义的是哪一种点表里不一定写清楚。常见的有高字在前低字在后、低字在前高字在后字节内部还可能再颠倒一次。另外定点数的小数位没除也会表现为数值翻倍。解决拿一个已知物理量做基准比如当前室温和设备显示对比把四种字序组合都试一遍能对上的就是正确配置。定点数的话先按整数读确认原始值之后再确定小数点位置别一上来就用浮点解析。6. 从单点读写到批量下发用 03 加 16 做一次写入闭环单个寄存器用 06 写就够了但要一次下发一组工艺参数06 就得发很多帧中间任何一帧失败都会留下半套参数设备状态处于新旧混合的尴尬位置。16 号预置多寄存器能一次写一串连续的保持寄存器配合 03 号回读就能做出一个完整的写入闭环先读原值备份再批量写再回读比对不一致就重试一次还不行就用备份值回滚。这个套路我在参数下发场景里用过很多次比单点写靠谱得多。关键在于把写成功的定义从从站回显正确改成回读值和目标值一致。16 号的响应只有 8 个字节告诉你的只是从站收到了、地址和数量没越界不代表寄存器里的值真的变了。def write_registers(ser, slave: int, start: int, values: list) - bool: body bytes([slave, 0x10]) struct.pack(HHB, start, len(values), len(values) * 2) body struct.pack(f{len(values)}H, *values) req body crc16_modbus(body) resp transact(ser, req, 8) # 16 号响应固定 8 字节 if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) return resp[2:6] req[2:6] # 比对起始地址和数量0x10是 16 号的十六进制表示请求里的第 7 个字节是字节数等于寄存器个数乘 2这个字段写错从站会直接回异常 03。响应的 8 个字节里第 2 到第 5 字节是起始地址和寄存器数量和请求一致就算接受。整个闭环大概是这样步骤操作判定条件103 读目标区保存原值读到长度等于寄存器数216 写新值响应地址和数量与请求一致303 回读同一区域逐寄存器比对目标值4不一致则重写一次第二次仍不一致则回滚5回滚用 16 写回原值回滚后同样回读确认第 3 步比对时要注意数据类型。设备把浮点拆成两个寄存器存的时候回读的两个 16 位整数和你要写的浮点不能直接比得先按设备的字序拼回浮点再比允许一个很小的误差。定点数就简单整数相等即可。注意回滚本身也可能失败。回滚失败时不要静默吞掉要把当前寄存器的实际值记进日志让现场知道设备处于什么状态。从那以后我每次做参数下发都强制走一遍读、写、回读这个闭环宁可多花两个轮询周期也不接受从站回显了就算成功这种判断。这套流程配合手边这份功能码速查表基本能覆盖 485 现场八成以上的读写场景剩下的两成交给点表和设备手册。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 9:13:25 · 阅读 1.2k Modbus功能码与报文实例解析：从01到21及CRC避坑
简介《Modbus通讯功能码及实例.pdf》是一份面向工业自动化初学者、PLC与嵌入式通信开发者的速查手册聚焦Modbus功能码含义与报文构造这一常见难点。文档以表格化方式梳理01至19号等常用功能码说明读取线圈、输入状态、保持寄存器、输入寄存器以及强置单线圈、预置单寄存器、强置多线圈、预置多寄存器等操作并补充异常状态、回送诊断、报告从机标识等辅助功能同时配合读写数字量、模拟量的命令与响应实例逐项拆解设备地址、起始地址、寄存器数量、数据字节及CRC高低字节顺序帮助读者理解主从站交互过程与报文解析思路。压缩包仅含1个PDF文件约10KB篇幅精炼便于打印或随查随用。目前已有2332人学习适合需要快速核对功能码、排查通信报文或准备课程实验的读者参考。1. 从一条超时的读寄存器请求说起柜子上的通信灯还在闪上位机发出去的读保持寄存器请求一条条超时抓回来的报文里功能码是0x83——从站明确说这条请求它不认。刚接 485 现场的人基本都撞过这堵墙报文看着没毛病可设备就是不回。这份《Modbus 通讯功能码及实例》PDF 解决的就是这个卡点它把 Modbus 功能码从 01 到 21 号逐个列清楚再用 01、02、03、04、05、06 六个高频功能码给出完整的请求帧和响应帧每个字节代表什么、取值范围多少、什么时候置零都跟着报文一起标注。它适合三类人照着报文调柜子的电气工程师、自己组帧写采集程序的上位机开发者、被地址偏移和功能码选型绕晕的设备对接人员。读完至少能判断一条帧该多长、回来的数据哪一位对应哪个开关。2. 功能码全景选型01 到 21 哪些能上手哪些是历史包袱市面上讲 Modbus 的资料多数只列 01 到 06 六个功能码就收尾剩下十几个要么一笔带过要么干脆不提。真到现场对点表的时候你会碰到只实现 04 不实现 03 的仪表也会碰到用 15 号功能码批量写线圈的控制器这时候靠猜是不行的。这份文档的价值在于它把 21 个功能码全部摊开包括那些只在老一代控制器上出现、现代设备根本不会实现的条目让你在拿到一份陌生点表时能快速判断这个功能码属于常规读写属于诊断类还是属于早就没人维护的历史包袱。选型这件事的本质是先搞清楚你要操作的是哪张数据表再决定用哪个功能码。功能码不是随便挑的它和 Modbus 的四张数据表严格绑定选错表的后果不是数据错而是从站直接甩一个异常码回来。2.1 四张数据表划定了功能码的边界Modbus 把从站的数据抽象成四张互相独立的表每张表有自己的地址空间互不重叠。线圈是可读写的位离散输入是只读的位输入寄存器是只读的 16 位字保持寄存器是可读写的 16 位字。落到功能码上01 读线圈、02 读离散输入、03 读保持寄存器、04 读输入寄存器、05 写单线圈、15 写多线圈、06 写单寄存器、16 写多寄存器。八个功能码四种操作类型两种数据宽度组合得干干净净。地址这块有个常见的认知差。设备手册里写的 40001、40002 这类编号是给人看的带区号前缀报文里传的起始地址是从 0 开始算的偏移量。所以手册上的 40001 对应报文里的0x000040011 对应0x000A。文档里给的实例是[11][03][00][6B][00][03]起始地址0x006B就是十进制 107如果设备手册上标的是 40108那正好对上。这一步换算要是搞反了你会稳定地读到隔壁寄存器的值而且看起来还挺合理属于最难查的那类问题。四张表的只读/可写属性也是硬约束。02 和 04 只能读你拿 05 去写离散输入从站一定回异常。反过来很多设备的保持寄存器区会被厂商塞进大量只读的状态量虽然协议上允许写但设备固件不认写进去不报错、值也不变这种就得靠点表提前确认。2.2 六个高频功能码怎么选文档里明确说 1、2、3、4、5、6 号功能码使用最频繁用它们就能完成对下位机数字量和模拟量的读写。这句话在现场基本成立绝大多数温控表、变频器、电表、IO 模块用这六个功能码就能把数据全采上来。功能码名称操作对象数据宽度请求帧长响应帧长01读线圈状态可读写位位8 字节5 N 字节02读输入状态只读位位8 字节5 N 字节03读保持寄存器可读写字16 位8 字节5 2N 字节04读输入寄存器只读字16 位8 字节5 2N 字节05强置单线圈可读写位位8 字节8 字节回显06预置单寄存器可读写字16 位8 字节8 字节回显15强置多线圈可读写位位9 N 字节8 字节16预置多寄存器可读写字16 位9 2N 字节8 字节N 在 01/02 里是ceil(数量 / 8)即数据字节数在 03/04 里是寄存器个数。这张表看着简单但排错时极其有用你发出去 8 个字节回来的帧长是 5 还是 52N一眼就能判断响应是不是被截断了。串口读超时设得太短返回的帧少了一两个字节CRC 必错很多人第一反应是波特率不对实际是读长度没算对。写操作为什么要分单个和多个因为 05/06 的响应是从站把请求原样回显主站只要逐字节比对就知道写没写成不需要额外的回读。而 15/16 的响应只回地址、功能码、起始地址和数量不携带数据写完到底生效没有得靠再读一次确认。这是两条完全不同的确认路径选型时要想清楚你的设备支不支持回读。2.3 07 到 21 号诊断类与老机型专属07 号读异常状态取的是 8 个内部线圈的通断状态这 8 个线圈的地址由控制器自己决定不在标准地址空间里所以换个厂家的设备这 8 位的含义就全变了。08 号回送诊断校验把诊断报文送给从站做通信处理评估这条功能码带子功能码常用来做链路自检。11 号读事件计数、12 号读通信事件记录用途是检索从站的事务处理日志通信出错时能拿到记录。13、14、18、19 这几条要特别注意。文档里标注了它们分别用于 484、184/384/484/584、884 和 MICRO 84 这类机型编号指的是早期某一代可编程控制器的系列代号。09 和 10 号同样是这批老设备上的编程和探询功能原文写得很直白09 号让主机模拟编程器去改从机逻辑10 号用来探询正在执行长程序的从机是否完成而且 10 号必须在含 09 号的报文发出之后才能发。这种强顺序依赖在现代设备上基本见不到你要是按现代协议的思路去理解很容易以为 10 号是个独立的查询命令。20 和 21 号读写通用参数针对的是扩展存储器文件也是特定机型的功能。17 号报告从机标识倒是通用性稍好一些响应里带从站类型和运行指示灯状态做设备自动识别时能用上但不少设备对这个功能码返回异常实现率并不高。2.4 保留段与异常响应怎么读22 到 64 是留给扩展功能的65 到 72 留给用户自定义73 到 119 是非法功能码120 到 127 内部保留128 到 255 用于异常应答。异常应答的规则是把请求功能码的最高位置 1也就是加上0x80。请求 03 出异常回来就是0x83请求 01 出异常回来是0x81。这个设计很省事主站收到响应先看功能码最高位就知道是正常数据还是错误报告。异常帧的长度固定 5 字节从站地址、功能码加 0x80、异常码、CRC 低、CRC 高。异常码里 01 表示非法功能02 表示非法数据地址03 表示非法数据值04 表示从站故障05 表示确认06 表示从站忙08 表示存储奇偶错0A 表示网关路径不可用0B 表示网关目标设备无响应。现场遇到最多的是 02 和 0302 基本是地址或数量越界03 往往是写入的值超出设备允许范围比如给一个量程 0 到 600 的温度寄存器写了 1000。提示异常响应不带数据域长度和正常响应完全不同。如果你的读函数按固定长度取帧异常帧会因为少读了后面的字节而一直阻塞到超时最后报出来的错误是超时而不是异常码排错方向直接被带偏。3. 报文逐字节拆解把[11][01][00][13][00][25]还原成 37 个开关量看懂功能码表格只是第一步真正要动手的时候你得知道每个字节该填什么。这份文档后半部分的价值就在这里它没有停留在01 号用于读线圈这种描述上而是把请求帧和响应帧完整列出来连CRC 校验在命令中的高低字节顺序和其他的相反这种细节都点了出来。这一句能省掉新手至少半天时间。3.1 请求帧与响应帧的字段骨架以 01 号读线圈为例请求帧是 8 个字节设备地址 1 字节、功能码 1 字节、起始地址高 8 位、起始地址低 8 位、读取数量高 8 位、读取数量低 8 位、CRC 低 8 位、CRC 高 8 位。文档给的例子是[11][01][00][13][00][25][CRC低][CRC高]拆开看设备地址0x11是十进制 17说明这条命令发给 17 号从站功能码0x01起始地址0x0013是十进制 19读取数量0x0025是十进制 37。所以这条命令的意思是17 号从站从第 19 号开关开始读 37 个开关量。响应帧的结构不同设备地址、功能码、返回的字节个数、数据 1 到数据 n、CRC 低、CRC 高。例子是[11][01][05][CD][6B][B2][0E][1B][CRC低][CRC高]字节个数0x05表示后面跟着 5 个数据字节。37 个开关量需要ceil(37/8) 5个字节对得上。这个字节个数字段是校验响应完整性的第一道关你请求 37 个位回来的字节数不是 5直接可以判定帧有问题不用等 CRC 算完。03 号读保持寄存器的骨架和 01 几乎一样区别在响应。请求[11][03][00][6B][00][03][CRC低][CRC高]起始地址 107读 3 个寄存器。响应是[11][03][06][02][2B][00][00][00][64][CRC低][CRC高]字节个数0x06因为一个模拟量占两个字节3 个寄存器就是 6 个字节。数据段按高字节在前排列[02][2B]是第一个寄存器的值 555[00][00]是 0[00][64]是 100。这里的高字节在前指的是寄存器内部的字节顺序和 CRC 的低字节在前不是一回事两套规则同时存在于一帧里是初学时最容易混淆的地方。3.2 位打包规则与最后一字节的高位补零读线圈的响应数据是按位打包的每个字节装 8 个开关量字节内的最低位对应起始地址。文档里写得很清楚每一位为 0 表示对应的开关断开为 1 表示闭合。拿0xCD这个字节验算一下二进制是1100 1101按最低位对应起始地址 19 展开第 0 位是 1地址 19 闭合第 1 位是 0地址 20 断开第 2 位是 1地址 21 闭合第 3 位是 1地址 22 闭合第 4 位是 0地址 23 断开第 5 位是 0地址 24 断开第 6 位是 1地址 25 闭合第 7 位是 1地址 26 闭合。这和文档里20 号开关闭合21 号断开22 闭合23 闭合24 断开25 断开26 闭合27 闭合的描述完全一致只是文档用的是从 1 开始的编号。最后一字节的处理是个细节坑。37 个位只占 5 个字节的前 37 位第 5 个字节0x1B只有低 5 位有意义高 3 位必须置 0。文档明确写了如果询问的开关量不是 8 的整倍数那么最后一个字节的高位部分无意义置为 0。解析的时候不能把这 3 位也当数据用否则你会凭空多出三个开关状态。反过来写测试用例时如果构造的响应里最后一字节高位不为 0严格实现的主站可能会判帧非法。def unpack_bits(payload: bytes, start_addr: int, count: int): 把 01/02 响应中的数据字节展开成 (地址, 状态) 列表 result [] for i in range(count): byte_index, bit_index divmod(i, 8) # 第几个字节、字节内第几位 bit (payload[byte_index] bit_index) 0x01 # 低位对应起始地址 result.append((start_addr i, bit)) return result # 用文档中的实例验证起始 19读 37 个 data bytes.fromhex(CD6BB20E1B) for addr, val in unpack_bits(data, 19, 37)[:8]: print(addr, val)这段代码的关键在divmod(i, 8)i是从起始地址算起的第几个开关除以 8 得字节下标余数是字节内的位下标。 bit_index 0x01用的是最低位优先的取法和 Modbus 的位打包顺序一致。参数start_addr是报文里的起始地址count是请求的数量两者必须和请求帧保持同步否则展开出来的地址会整体偏移。3.3 CRC-16/MODBUS 的算法与高低字节顺序CRC 校验覆盖从设备地址到数据末尾的全部字节不包括 CRC 本身。算法参数是初值0xFFFF、多项式0xA001这是0x8005的反向表示、输入输出都不反转、不做最终异或。算完之后直接取低字节先发、高字节后发。文档里那句CRC 校验在命令中的高低字节的顺序和其他的相反说的就是这件事。报文里的地址、寄存器值都是高字节在前唯独 CRC 是低字节在前。很多 CRC 计算工具默认输出高字节在前直接贴进报文就错而且错得很隐蔽CRC 数值本身是对的只是两字节顺序颠倒校验方算出来的值和你发出去的值不一样报错却指向校验失败看不出是顺序问题。def crc16_modbus(data: bytes) - bytes: 计算 Modbus RTU 的 CRC16返回低字节在前的两字节 crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 # 右移后异或反向多项式 else: crc 1 return bytes([crc 0xFF, (crc 8) 0xFF]) # 低字节在前 frame bytes.fromhex(110100130025) print(crc16_modbus(frame).hex()) # 直接拼到 frame 后面就是完整请求帧函数返回的是bytes而不是整数这是故意的只有在返回时就固定好低字节在前调用方拼接报文时才不会再次搞反。第 4 章的收发函数都复用这个实现校验响应时用同样的函数算resp[:-2]再和resp[-2:]逐字节比对顺序自然就对上了。3.4 三条实例报文的验算路径文档给了 01、03、05、06 四类实例手工验算时按固定顺序走一遍就行。先数长度01 请求 8 字节、响应 5 加数据字节数03 请求 8 字节、响应 5 加两倍寄存器数05 和 06 的请求和响应都是 8 字节且完全对称。长度不对后面的都不用算。再看功能码最高位。响应帧的第二个字节如果大于0x80说明是异常帧只有 5 字节直接跳到异常码解析不要按正常响应的长度去读。然后看字节数字段01 响应的第三个字节应该等于ceil(数量/8)03 响应的第三个字节应该等于寄存器数乘 2不一致就是帧被截断或者从站实现有问题。最后才校验 CRC。以 05 号写单线圈[11][05][00][AC][FF][00][CRC低][CRC高]为例地址0x00AC是十进制 172数据域0xFF00表示闭合。文档特别强调这里只可以是[FF][00]表示闭合、[00][00]表示断开其他数值非法。这一条要记死第 5 章会专门讲写成[00][01]的后果。写成功时从站把这条命令原样返回八个字节一模一样写失败或者地址越界从站要么不响应要么回异常帧不会回一个部分成功。4. 手搓一个最小主站01/03/05/06 四类读写的可复现脚本拿一份现成的 Modbus 库当然快但库把组帧和解析都封在黑匣子里一旦现场出问题你很难判断是库的问题还是设备的问题。我一般建议至少自己手写一遍最小主站把组帧、发送、收帧、校验四步走通之后再换库也就是换个调用方式的事。这一章用pyserial做串口收发不依赖任何 Modbus 专用库代码量很小但每一步都能对上文档里的报文结构。pip install pyserial装完之后先确认端口能打开。Windows 下是COM3这种名字Linux 下是/dev/ttyUSB0。用 USB 转 485 的时候注意驱动装没装设备管理器里能看到端口号才算通。4.1 串口参数与半双工时序Modbus RTU 最常见的参数是 9600 波特率、8 数据位、无校验、1 停止位也就是常说的 8N1。也有设备用 19200 或 115200还有用偶校验的具体看设备手册参数不匹配的表现是一个字节都收不到或者全是乱码。半双工是 485 的物理特性同一时刻只能有一个方向在发。USB 转 485 模块一般自带方向控制主站只管写数据就行。真正要注意的是帧间隔Modbus RTU 规定帧内字符间隔不超过 1.5 个字符时间帧与帧之间至少静默 3.5 个字符时间。9600 波特率下一个字符 11 位3.5 个字符约 4 毫秒。主站连续发两条命令时如果中间不等待从站可能把两条粘成一帧解析出来的结果是彻底乱的。import serial import struct import time def open_port(port: str, baud: int 9600) - serial.Serial: return serial.Serial( portport, baudratebaud, bytesize8, parityserial.PARITY_NONE, stopbits1, timeout0.5, # 读超时要大于从站最大响应时间 ) def transact(ser: serial.Serial, req: bytes, expect_len: int) - bytes: ser.reset_input_buffer() # 清掉上一帧残留避免错位 ser.write(req) ser.flush() time.sleep(0.005) # 9600 下 3.5 字符约 4ms留一点余量 resp ser.read(expect_len) if len(resp) 5: raise TimeoutError(f响应不足 5 字节: {resp.hex() or 空}) if crc16_modbus(resp[:-2]) ! resp[-2:]: raise ValueError(fCRC 校验失败: {resp.hex()}) return resptimeout0.5这个值决定了单次读取最多等多久。设太短从站还没处理完就返回读到半截帧设太长一个掉线的从站会让整个轮询周期卡住。常见做法是按设备手册给的最大响应时间再加 50% 余量。reset_input_buffer()不能省尤其是上一轮超时之后缓冲区里可能还留着半帧垃圾数据不清掉的话下一帧读出来就是从中间开始的CRC 必错。expect_len由调用方按功能码算好传进来这是第四章后面几节的核心。4.2 读类请求01 和 03 的构造与响应长度推算03 号读保持寄存器是最常用的功能码先把这条走通其他都是变体。请求帧 8 字节响应长度是 5 加两倍寄存器数。注意struct.pack(HH, start, count)里的表示大端也就是高字节在前这正好对上 Modbus 报文的字节序约定。def read_holding(ser, slave: int, start: int, count: int) - list: req bytes([slave, 0x03]) struct.pack(HH, start, count) req crc16_modbus(req) expect 5 count * 2 # 地址功能码字节数数据CRC resp transact(ser, req, expect) if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) n resp[2] # 从站返回的字节数 return list(struct.unpack(f{n // 2}H, resp[3:3 n]))slave是从站地址取值 1 到 2470 是广播地址广播只写不读所以读操作永远不要用 0。start是从 0 开始的寄存器偏移不是手册上的 40001 编号。count是寄存器个数1 到 125 之间超过 125 从站一般回异常 03。响应里的resp[2]是字节数而不是寄存器数struct.unpack之前要先除以 2这个换算忘了的话 unpack 出来的长度对不上会直接抛异常。01 号读线圈的构造逻辑一样只是响应长度按位算而且返回的是原始字节需要再展开成位。def read_coils(ser, slave: int, start: int, count: int) - list: req bytes([slave, 0x01]) struct.pack(HH, start, count) req crc16_modbus(req) expect 5 (count 7) // 8 # 向上取整得到数据字节数 resp transact(ser, req, expect) if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) data resp[3:3 resp[2]] return unpack_bits(data, start, count) # 复用第 3 章的展开函数(count 7) // 8是向上取整的经典写法比math.ceil少一次函数调用读 37 个位算出来是 5和文档实例完全一致。这里面还有个隐含前提从站返回的字节数必须等于请求推算的长度如果不相等transact里的 CRC 校验会失败因为帧被截断或者多读了后续帧的字节。4.3 写类请求05 的 FF00 与 06 的回显校验写单线圈只认两个值0xFF00表示闭合0x0000表示断开。文档里那句只可以是[FF][00]表示闭合、[00][00]表示断开其他数值非法是针对 05 号的硬规定写成0x0001有些设备会回异常 03有些设备干脆不响应。写单寄存器 06 没有这个限制数据域就是目标值的 16 位表示。这两个功能码的响应都是请求原样回显所以校验方式很直接收到的 8 个字节和发出去的 8 个字节逐字节比对一致就算成功。这比读操作简单但也要注意异常响应的情况回显校验之前先看功能码最高位。def write_coil(ser, slave: int, addr: int, on: bool) - bool: value 0xFF00 if on else 0x0000 # 05 号只认这两个值 req bytes([slave, 0x05]) struct.pack(HH, addr, value) req crc16_modbus(req) resp transact(ser, req, 8) if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) return resp req # 原样回显才算成功 def write_register(ser, slave: int, addr: int, value: int) - bool: req bytes([slave, 0x06]) struct.pack(HH, addr, value 0xFFFF) req crc16_modbus(req) resp transact(ser, req, 8) if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) return resp reqreq bytes([slave, 0x05]) ...这种拼法看起来土但好处是每一段都能和文档里的字节位置对上调不通的时候打印req.hex()就能逐字节核对。value 0xFFFF是防御性写法负数或者超过 65535 的值会在这里被截断不过更稳妥的做法是在调用前就做范围检查因为静默截断会让写入的值和预期不符。4.4 异常响应与超时的区分处理异常响应和超时是两个完全不同的失败排错方向也完全不同所以代码里必须分开处理。异常响应说明从站收到了请求、解析了、拒绝了问题在请求内容上超时说明从站压根没回问题在物理层、地址、波特率或者从站根本没实现这个功能码。transact里读到少于 5 个字节就抛TimeoutError这是超时分支。读到完整帧但功能码最高位为 1这是异常分支resp[2]直接给出异常码。剩下的分支才是正常数据。三个分支分清楚现场排错时看异常类型就能定位到大概方向不用从头猜。还有一类情况要单独提从站回了一个长度正确、CRC 正确、功能码也正常的帧但数据明显不对比如读温度读出来 32767。这不是通信问题是数据解析问题多半是数据格式没对上可能是定点数的小数位没除也可能是 32 位数据跨了两个寄存器而字序搞反了。这类问题在通信层查不出来得回到设备的点表去看。5. 避坑与排查五条从现场抄回来的翻车记录协议文档给的是规范现场踩的坑往往在规范的边缘。文档里已经点出了几个关键细节比如 CRC 高低字节相反、05 号只认 FF00 和 0000但真正吃过亏之后才会记住。这一章把最常见的五类问题按现象、原因、解决三段拆开都是照着这份功能码表能直接对上号的。5.1 CRC 永远校验不过但报文肉眼看着没问题现象主站发出去的帧从站一律不响应或者从站回了帧但本地校验报 CRC 错。把报文贴到在线 CRC 工具里算算出来的值和报文里带的对不上。原因CRC 数值算对了但发出去的时候字节顺序反了。很多 CRC 工具默认输出高字节在前而 Modbus RTU 要求低字节在前。文档里那句CRC 校验在命令中的高低字节的顺序和其他的相反说的就是这件事但第一次看很容易略过去。解决把 CRC 计算函数固定成返回低字节在前的bytes拼接和校验都走同一个函数不要在两处各写一遍。已经发出去的帧可以用抓包工具截下来单独对前 N-2 个字节重算一次 CRC比对两个字节的顺序反了就是这个问题。5.2 地址对不上读出来的值稳但不准现象读保持寄存器起始地址按手册上的 40001 填成 40001从站回异常 02改成 0 之后能读了但读出来的数值明显是隔壁参数的。原因手册编号和报文偏移差 1而且不同厂家对 4 区起始编号的定义还有差异有的从 40001 开始算有的从 40000 开始算。文档里的实例[11][03][00][6B][00][03]起始地址0x006B是十进制 107如果设备手册上标的是 40108说明这个厂家的 4 区是从 40001 对应偏移 0。解决拿到点表先做一次单点校验挑一个已知值的寄存器读出来比对确认偏移基准之后再批量采。别一上来就按偏移量铺开几百个点错了之后改起来是灾难。5.3 写线圈命令回显正常但继电器不动现象05 号功能码发出去从站原样回显回显校验通过代码认为写成功了可现场设备一点反应没有。原因数据域写成了0x0001而不是0xFF00。有些从站对非法值不报异常只是忽略回显照做于是主站收到成功实际什么都没发生。解决写线圈的值只有两种闭合0xFF00、断开0x0000用布尔值映射而不是直接传 1 和 0。写完如果设备还是不动用 01 号功能码回读一次线圈状态确认从站内部的状态到底变没变这一步能区分是写没进去还是写进去了但执行机构有问题。5.4 偶发超时重发一次就好现象轮询几十个从站每隔几分钟就有一两条超时重发立刻成功日志里 CRC 错误和超时交替出现。原因帧间隔不够主站上一帧刚发完就发下一帧从站还在处理上一条或者 485 总线上的方向切换有延时第一个字节被吃掉也可能是总线上有多个主站或者干扰导致某帧损坏。解决在transact里加固定静默9600 波特率下至少 4 毫秒把读超时从 0.1 秒放宽到 0.5 秒给重试次数设上限通常 2 到 3 次超过就记一条错误日志跳过这个从站别让一条坏链路拖垮整个轮询周期。5.5 读上来的数值是负数或者翻了几倍现象03 号读两个寄存器拼一个 32 位浮点读出来的值有时候是对的有时候符号反了有时候数量级差 256 倍。原因32 位数据跨两个寄存器时字序和字节序有四种组合设备端定义的是哪一种点表里不一定写清楚。常见的有高字在前低字在后、低字在前高字在后字节内部还可能再颠倒一次。另外定点数的小数位没除也会表现为数值翻倍。解决拿一个已知物理量做基准比如当前室温和设备显示对比把四种字序组合都试一遍能对上的就是正确配置。定点数的话先按整数读确认原始值之后再确定小数点位置别一上来就用浮点解析。6. 从单点读写到批量下发用 03 加 16 做一次写入闭环单个寄存器用 06 写就够了但要一次下发一组工艺参数06 就得发很多帧中间任何一帧失败都会留下半套参数设备状态处于新旧混合的尴尬位置。16 号预置多寄存器能一次写一串连续的保持寄存器配合 03 号回读就能做出一个完整的写入闭环先读原值备份再批量写再回读比对不一致就重试一次还不行就用备份值回滚。这个套路我在参数下发场景里用过很多次比单点写靠谱得多。关键在于把写成功的定义从从站回显正确改成回读值和目标值一致。16 号的响应只有 8 个字节告诉你的只是从站收到了、地址和数量没越界不代表寄存器里的值真的变了。def write_registers(ser, slave: int, start: int, values: list) - bool: body bytes([slave, 0x10]) struct.pack(HHB, start, len(values), len(values) * 2) body struct.pack(f{len(values)}H, *values) req body crc16_modbus(body) resp transact(ser, req, 8) # 16 号响应固定 8 字节 if resp[1] 0x80: raise IOError(f从站异常异常码 0x{resp[2]:02X}) return resp[2:6] req[2:6] # 比对起始地址和数量0x10是 16 号的十六进制表示请求里的第 7 个字节是字节数等于寄存器个数乘 2这个字段写错从站会直接回异常 03。响应的 8 个字节里第 2 到第 5 字节是起始地址和寄存器数量和请求一致就算接受。整个闭环大概是这样步骤操作判定条件103 读目标区保存原值读到长度等于寄存器数216 写新值响应地址和数量与请求一致303 回读同一区域逐寄存器比对目标值4不一致则重写一次第二次仍不一致则回滚5回滚用 16 写回原值回滚后同样回读确认第 3 步比对时要注意数据类型。设备把浮点拆成两个寄存器存的时候回读的两个 16 位整数和你要写的浮点不能直接比得先按设备的字序拼回浮点再比允许一个很小的误差。定点数就简单整数相等即可。注意回滚本身也可能失败。回滚失败时不要静默吞掉要把当前寄存器的实际值记进日志让现场知道设备处于什么状态。从那以后我每次做参数下发都强制走一遍读、写、回读这个闭环宁可多花两个轮询周期也不接受从站回显了就算成功这种判断。这套流程配合手边这份功能码速查表基本能覆盖 485 现场八成以上的读写场景剩下的两成交给点表和设备手册。希望帮到你。本文还有配套的精品资源点击获取