Modbus功能码详解：报文结构、字节序与CRC校验实战指南

简介面向工业自动化初学者与现场调试人员的Modbus协议入门资料聚焦功能码含义与报文实例帮助读者理解主从设备间数字量、模拟量的读写流程解决通信报文构造与解析的常见困惑。包内共1个PDF文件约10KB篇幅精炼便于随查随用。内容以功能码为主线逐一说明01至17号功能码的作用重点展开最常用的01、02、03、04、05、06号并给出读线圈、读输入状态、写单线圈、读保持寄存器、写单寄存器等典型命令与响应的字节级示例标注设备地址、起始地址、寄存器数量与CRC校验的位置和注意事项同时附有功能码速查表。已有2330人学习适合作为调试串口与以太网通信时的对照手册也可用于快速回顾报文结构、排查地址与校验错误。1. 一份把 Modbus 功能码讲透的 PDF从报文到字节序的落地手册调试现场最常听到的一句话是“数据读上来了但不对”。RS485 线接好了串口助手也能收到回码可温度值显示 6553.5开关状态全是反的——问题往往不在硬件而在功能码选错、寄存器地址偏移没算、或者 CRC 高低字节放反了。这份《Modbus通讯功能码及实例.pdf》解决的正是这个环节它把 01 到 21 号功能码逐个列出作用并对最常用的 01、02、03、04、05、06 六个码给出了完整的请求帧和响应帧拆解连每个字节代表什么、地址从 0 还是从 1 开始、数据高低位怎么排都写清楚了。适合刚接手 485 总线设备对接的嵌入式工程师、做上位机采集的软件开发者以及需要快速核对报文格式的现场调试人员。它不是协议规范的替代品而是一份能放在手边对着串口日志逐字节比对的速查材料。2. 六个核心功能码的报文结构请求帧怎么拼、响应帧怎么拆2.1 为什么 01/02/03/04/05/06 覆盖了八成现场需求工业现场的设备类型看着杂落到数据模型上其实只有四类可读写的开关量线圈、只读的开关量输入状态、可读写的模拟量保持寄存器、只读的模拟量输入寄存器。功能码 01 和 02 分别对应前两类开关量的读取03 和 04 对应后两类模拟量的读取05 和 06 负责单个线圈和单个寄存器的写入。把这六个码吃透绝大多数传感器、继电器板、变频器、温控表的对接都能走通。选型上有个容易混淆的点同样是读开关量01 读的是线圈可被 05 改写02 读的是输入状态物理上只读比如限位开关。有些设备厂商把两者映射到同一片物理输入上用 01 也能读到但这属于实现层面的宽容不能当成通用做法。同理03 读保持寄存器可被 06 改写04 读输入寄存器通常是采集值只读。对接新设备时先翻它的寄存器表看清楚某个地址标的是“保持”还是“输入”再决定用 03 还是 04这一步搞反了回码要么异常要么读出来是另一组数据。PDF 里对每个功能码都给了“计算机发送命令”和“设备响应”两段字节序列格式统一为方括号包住每个字节。这种写法看着朴素但对现场比对特别友好——串口助手抓到的原始字节直接按顺序对上去就行不用在脑子里做格式转换。2.2 读类功能码01/02/03/04 的请求与响应逐字节拆解读线圈01的请求帧结构是设备地址 1 字节、功能码 1 字节、起始地址高 8 位、起始地址低 8 位、读取数量高 8 位、读取数量低 8 位、CRC 低 8 位、CRC 高 8 位共 8 字节。PDF 给的例子是[11][01][00][13][00][25][CRC低][CRC高]含义是向 17 号设备读从地址 19 开始的 37 个线圈。响应帧则是设备地址、功能码、返回字节数、数据 1 到数据 n、CRC 低、CRC 高。例子[11][01][05][CD][6B][B2][0E][1B][CRC低][CRC高]里返回 5 个字节因为 37 个线圈需要 ceil(37/8)5 个字节来装。这里有个必须记住的细节每个数据字节的 8 个位对应 8 个连续线圈最低位对应起始地址那个线圈。PDF 明确写了“每一位为 0 表示对应的开关断开为 1 表示闭合”并且指出如果询问数量不是 8 的整倍数最后一个字节的高位部分无意义、置 0。实际解析时如果你按位从高到低读状态会整体错位这是新手最常见的翻车点之一。读保持寄存器03的请求结构和 01 完全一致只是功能码换成 03。响应帧的区别在于返回字节数是寄存器数量的两倍每个寄存器占两个字节高字节在前。PDF 的例子[11][03][06][02][2B][00][00][00][64][CRC低][CRC高]返回 6 个字节对应 3 个寄存器值分别是 0x022B555、0x00000、0x0064100。这个“一个模拟量返回两个字节、高字节在前”的规则是后面讲字节序问题的伏笔。读输入状态02和读输入寄存器04在报文结构上与 01、03 完全对称唯一变化是功能码。PDF 用一句话带过“和读取线圈状态类似只是第二个字节的命令号不再是 1 而是 2”这种写法在速查场景下够用但实际对接时仍要确认目标设备的寄存器表里该地址是否真的支持 02/04有些低成本模块只实现了 01/03发 02 过去直接超时。2.3 写类功能码05 和 06 的“原样返回”约定写单个线圈05的请求帧是设备地址、功能码 05、线圈地址高 8 位、低 8 位、数据高 8 位、低 8 位、CRC 低、CRC 高。PDF 特别强调数据域只允许两种取值[FF][00]表示闭合[00][00]表示断开其他数值非法。例子[11][05][00][AC][FF][00][CRC低][CRC高]就是把地址 0x00AC 的线圈置为闭合。写单个寄存器06的结构相同数据域换成要写入的 16 位值。例子[11][06][00][01][00][03][CRC低][CRC高]是把 1 号寄存器的值设为 3。这两个写功能码的响应有个共同约定成功时设备把请求帧原样返回失败时不响应或返回异常帧。PDF 写的是“如果成功把计算机发送的命令原样返回否则不响应”。这个“原样返回”在调试时非常好用——你发出去的帧和收回来的帧逐字节比对完全一致就说明写入成功不用再去解析响应内容。但要注意部分设备在写入失败时会返回带异常码的响应帧功能码最高位置 1比如 06 变成 0x86后跟异常码而不是真的“不响应”所以超时和异常帧两种失败形态都要处理。下面这段 Python 代码演示了如何用最小依赖拼出 03 功能码的请求帧并做 CRC 校验适合在没有第三方库的环境里快速验证import struct def crc16_modbus(data: bytes) - bytes: 标准 Modbus CRC16返回低字节在前、高字节在后的 2 字节 crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 # 注意协议要求 CRC 低字节先发所以这里返回 low, high return struct.pack(H, crc) def build_read_holding(dev_addr: int, start: int, count: int) - bytes: 构造 03 读保持寄存器请求帧 body struct.pack(BBHH, dev_addr, 0x03, start, count) return body crc16_modbus(body) def parse_read_holding_resp(resp: bytes): 解析 03 响应返回寄存器值列表 if len(resp) 5: raise ValueError(响应过短) if resp[1] 0x80: raise RuntimeError(f异常响应异常码{resp[2]}) byte_count resp[2] if len(resp) ! 3 byte_count 2: raise ValueError(长度与字节数不符) values [] for i in range(3, 3 byte_count, 2): # 高字节在前 values.append((resp[i] 8) | resp[i 1]) return values # 对应 PDF 例子17 号设备起始 107读 3 个 frame build_read_holding(0x11, 107, 3) print(frame.hex( ).upper())这段代码的关键点有三个。第一crc16_modbus里用struct.pack(H, crc)输出小端序正好满足“CRC 低字节先发”的要求如果写成大端现场表现就是设备完全不回码因为校验对不上。第二build_read_holding用BBHH大端打包地址和数量这是 Modbus 应用层的规定和 CRC 的字节序是两回事别混。第三解析响应时先判断resp[1] 0x80这是识别异常响应的通用手法功能码最高位为 1 就说明设备拒绝了请求后面那个字节是异常码比等超时快得多。参数上dev_addr取 1 到 2470 是广播地址写操作可用读操作不会有响应start是寄存器起始地址注意这里填的是协议地址不是设备手册上可能标注的“1 基地址”差 1 的问题后面单独说count对 03 来说最大 125因为响应帧的字节数字段只有 1 字节最多 255 字节数据留出余量后 125 是安全上限。3. 地址、字节序与 CRC三个让报文“看起来对但读不对”的坑3.1 寄存器地址的 0 基与 1 基差一位全盘错PDF 在讲 01 功能码时写了一句“起始地址为 0”例子中起始地址 19 对应“20 号开关”。这句话点出了 Modbus 协议层的地址是从 0 开始计数的。但大量设备手册在寄存器表里用的是 1 基编号比如标注“40001 对应温度值”。如果你直接把 40001 填进请求帧实际访问的是协议地址 40001而不是设备期望的 0。常见做法是看到 4xxxx 开头的保持寄存器编号先减 40001 得到协议地址看到 3xxxx 开头的输入寄存器减 300010xxxx 线圈减 11xxxx 输入状态减 1。但这不是铁律有些厂商的文档直接给的就是协议地址减了反而错。稳妥的验证方式是拿一个已知值的寄存器比如设备铭牌上的固件版本号或固定常量用两个相邻地址各读一次看哪个返回的值和文档对得上就能确定偏移方向。这个笨办法我每次对接新设备都会走一遍比猜快。3.2 字节序与字序0x022B 读成 0x2B02 是怎么回事PDF 的 03 功能码例子里返回[02][2B]表示 555明确是“高 8 位在前”。这是 Modbus 应用层的标准字节序也就是大端。但问题出在“字序”上一个 32 位浮点数或 32 位整数要占两个连续寄存器先发哪个寄存器、每个寄存器内部又是什么字节序Modbus 规范没有强制规定完全由设备厂商决定。现场常见的四种组合是 ABCD、CDAB、BADC、DCBA其中 ABCD 是“高字在前、字内大端”CDAB 是“低字在前、字内大端”后两种是字节交换的变体。PDF 只覆盖了 16 位寄存器没涉及 32 位数据的字序问题这是它作为速查材料的边界。实际遇到浮点数时我的做法是先按 ABCD 解析如果数值明显离谱比如温度读出 1e38 或者 0.0001再依次试 CDAB、BADC、DCBA通常两三次就能对上。更靠谱的办法是让设备方提供一个已知值的调试寄存器比如固定写入 123.456然后四种组合各解一遍哪个等于 123.456 就锁定哪种。这个结论要写进项目对接文档换一批同型号设备直接复用。3.3 CRC 校验低字节在前且校验范围不含自身PDF 在 01 功能码的说明里写了一句很关键的话“CRC 校验在命令中的高低字节的顺序和其他的相反。”意思是地址、数量这些字段都是高字节在前唯独 CRC 是低字节在前。这个不对称设计是 Modbus RTU 的硬性规定也是手写组帧时最容易翻车的地方。校验范围是从帧头到 CRC 之前的全部字节不包括 CRC 自身。上面 2.3 节的代码里crc16_modbus(body)传入的就是不含 CRC 的body这一点如果搞错把 CRC 也算进去结果永远对不上。另外CRC 初值是 0xFFFF多项式是 0xA001反向的 0x8005这两个参数在实现时不能改改了就不是 Modbus CRC 了。排查 CRC 问题时一个高效手段是拿 PDF 里的例子做单元测试用[11][01][00][13][00][25]算出 CRC和文档里给的[CRC低][CRC高]比对。如果对不上说明你的 CRC 实现有问题先修算法再查其他。PDF 的例子虽然没直接写出 CRC 的具体数值但用同一套算法对多个例子交叉验证能快速定位是算法错还是字节序错。4. 避坑与排查五条来自现场的踩坑记录4.1 发 01 读线圈回码功能码变成 0x81现象请求帧发出去设备有回码但第二个字节是 0x81 而不是 0x01后面跟一个异常码。原因功能码最高位置 1 表示异常响应常见异常码 01 是“非法功能”、02 是“非法数据地址”。这说明设备不支持 01或者你请求的起始地址/数量超出了它的线圈范围。解决先确认设备手册里该型号是否实现了 01再核对地址范围如果设备只支持 03/04就改用寄存器读取别在线圈上死磕。4.2 03 读回来的值总是实际值的两倍或一半现象读温度寄存器显示 512 而实际是 25.6或者显示 12.8 而实际是 25.6。原因设备把数值做了缩放比如实际值乘以 10 或乘以 100 后存进寄存器而解析端没做对应除法也可能是把有符号数当无符号数读了负温度变成很大的正数。解决翻寄存器表里的“单位/缩放因子”一栏解析后除以对应倍数有符号数用struct.unpack(h, ...)而不是H。PDF 的例子给的是原始二进制值没涉及缩放这一步得靠设备文档补。4.3 写 05 成功但继电器不动现象05 请求帧发出去响应原样返回说明设备接受了但物理继电器没动作。原因数据域填了[00][01]而不是[FF][00]。PDF 明确写了只允许[FF][00]闭合、[00][00]断开其他数值非法。有些设备对非法值不报异常而是静默忽略响应照样原样返回造成“写成功但没生效”的假象。解决组帧时对 05 的数据域做硬编码校验只允许这两个值从源头堵住。4.4 多台设备挂在同一总线上只有一台能通现象单台设备调试正常挂上第二台后其中一台或两台都开始超时、CRC 错。原因设备地址冲突或者终端电阻没接、总线拓扑不是手拉手而是星形。Modbus RTU 要求每个从机地址唯一范围 1 到 247出厂默认常常都是 1。解决逐台单独上电改地址改完再挂下一台总线两端各接一个 120 欧终端电阻分支线尽量短。这类问题不是报文层面的但表现和报文错误一模一样排查时先排除物理层再怀疑协议。4.5 响应帧长度对但数据错位一个字节现象03 响应里字节数字段是 6但解析出来的三个寄存器值整体偏移第一个值像是把地址字段吃进去了。原因解析时起始索引算错把“设备地址、功能码、字节数”三个字节的头部长度记成了 2 或 4。解决固定用resp[3:3byte_count]取数据区并在解析前校验len(resp) 3 byte_count 2长度不符直接丢弃重发别硬解。这个校验加上之后错位问题基本绝迹。5. 从 PDF 例子到自动化校验把手工比对变成可回归的测试PDF 里的例子最大的价值不是让你背下来而是可以当成测试向量。我一般会把 01、03、05、06 四个例子的请求帧和响应帧抄进一个 JSON 文件写一个小脚本做两件事一是用组帧函数重新生成请求帧和文档例子逐字节比对二是把文档响应帧喂给解析函数看输出是否等于文档描述的值比如 03 例子应解析出 555、0、100。这样每次改动组帧或解析代码跑一遍就知道有没有回归。import json CASES [ {name: read_coils, req: 11 01 00 13 00 25, resp: 11 01 05 CD 6B B2 0E 1B}, {name: read_holding, req: 11 03 00 6B 00 03, resp: 11 03 06 02 2B 00 00 00 64}, ] def check_case(case): req bytes.fromhex(case[req].replace( , )) # 重新计算 CRC 并追加验证组帧逻辑 rebuilt req crc16_modbus(req) resp bytes.fromhex(case[resp].replace( , )) # 响应帧同样补 CRC 后走解析 full_resp resp crc16_modbus(resp) if case[name] read_holding: vals parse_read_holding_resp(full_resp) assert vals [555, 0, 100], f解析不符: {vals} return rebuilt.hex( ).upper() for c in CASES: print(c[name], check_case(c))这段脚本的用法是把 PDF 里每个功能码的例子按req和resp两栏录入req只填到 CRC 之前脚本自动补 CRC 并和原始例子比对resp同样补 CRC 后走解析断言解析结果等于文档描述。跑通之后这套用例就是你的“后悔药”——以后换设备、改代码先跑用例再上线比在现场拿串口助手一帧帧试快得多。一个具体技巧PDF 里 01 功能码的响应例子[CD][6B][B2][0E][1B]对应 37 个线圈最后一个字节0x1B只有低 5 位有效因为 37 4×8 5高位是补 0 的。解析时如果按 8 位全读会把补零位当成“断开”的线圈数量对不上。正确做法是按请求的线圈数量截断只取前 37 位。这个边界在批量读线圈时特别容易忽略尤其是数量不是 8 的整倍数的时候。从那以后我每次对接新设备都强制先把 PDF 里的例子跑成测试用例再拿真实设备回码往里填两套对上了才动业务代码。希望这份材料也能帮你少在字节序和地址偏移上耗时间。本文还有配套的精品资源点击获取