简介：这份PDF面向工业自动化、嵌入式开发及现场调试人员，系统梳理Modbus协议的功能码体系与报文实例，帮助读者解决设备通信中功能码选用、报文构造与解析的实际问题。资源共1个PDF文件，压缩包约10KB，篇幅精炼，便于随查随用。内容以功能码为主线，逐一说明01至17号常用功能码的作用，涵盖读取线圈状态、读取输入状态、读取保持寄存器、读取输入寄存器、强置单线圈、预置单寄存器、强置多线圈、预置多寄存器及报告从机标识等，并给出读线圈、写线圈、读保持寄存器等典型场景的完整命令与响应报文示例，逐字段解释设备地址、起始地址、寄存器数量与CRC校验的取值含义。已有2330人学习，适合需要快速对照功能码定义、理解请求响应格式并排查通信问题的工程师作为案头参考。

1. 功能码不是命令表：Modbus 报文里真正决定成败的那一个字节

很多人第一次调 Modbus，都会以为功能码就是一张"命令对照表"——01 读线圈、03 读寄存器、05 写线圈，背下来就能通。真到现场就翻车：明明按表发了 03，从机一声不吭；或者读回来的数值总是差一位、错半截。问题往往不在功能码本身，而在它背后那套"地址空间 + 字节序 + 异常应答"的约定。功能码只是报文第二个字节，可它同时决定了后面跟几个字节、数据怎么解释、出错时从机怎么回话。搞懂这一层，你才会明白为什么 05 写线圈的数据只能是 FF00 或 0000，为什么 03 读 3 个寄存器要返回 6 个数据字节，为什么 CRC 的高低字节顺序和别处相反。这份资料把 01 到 21 号功能码逐个拆开，配了完整报文实例，正好拿来把"为什么这么设计"讲透。

2. 报文骨架：功能码为什么必须和字节数绑死

2.1 一个字节承载三种语义

Modbus 的报文结构极其朴素：设备地址、功能码、数据区、CRC。看起来功能码只是"我要干什么"，实际上它同时承担了三件事。第一是操作类型，读还是写、读线圈还是读寄存器；第二是数据区布局，功能码一变，后面跟的字段个数和含义全变；第三是应答形态，正常应答和异常应答走的是两条不同的解析路径。

这种"一个字段管三件事"的设计，是 Modbus 能在 1979 年的串行链路上跑起来的关键。那个年代带宽和算力都紧张，报文越短越好，没有余量去放类型标识、长度字段、版本号。于是协议把"怎么解析"这件事编码进了功能码本身：接收方读到第二个字节是 03，就知道后面必然是"起始地址 2 字节 + 寄存器数量 2 字节"，应答必然是"字节数 1 字节 + N 个数据字节"。解析器不需要任何额外元信息，一个 switch 就能分发。

代价是扩展性差。功能码一旦定死，数据区布局就不能改，所以协议里留了 22～64 作扩展、65～72 给用户自定义、73～119 判为非法、128～255 留给异常应答。这份资料里那张功能码全表，本质就是一张"字节语义分配表"，而不是简单的命令清单。

2.2 地址、数量、字节数：三个容易混淆的计数

新手最容易在三个"数"上栽跟头。以 03 读保持寄存器为例，请求里是"起始地址 + 寄存器数量"，应答里却是"字节数 + 数据"。这三个量的关系是：

• 起始地址：从 0 开始编号，占 2 字节，高字节在前；
• 寄存器数量：要读多少个寄存器，占 2 字节；
• 应答字节数 = 寄存器数量 × 2，因为一个寄存器是 16 位。

资料里的例子很典型：请求[11][03][00][6B][00][03]，起始地址 0x006B 即 107，读 3 个寄存器；应答[11][03][06][02][2B][00][00][00][64]，字节数 06 正好是 3×2，三个值分别是 0x022B=555、0x0000=0、0x0064=100。如果你把"寄存器数量"误当成"字节数"去解析，读 3 个寄存器却只取 3 个字节，后半个寄存器的值就丢了，表现出来就是"数值总是对不上"。

提示：调试时先数应答里的字节数字段，它必须等于请求寄存器数 ×2，不等就说明要么从机实现有问题，要么你请求的数量超了从机上限。

2.3 大端在前，唯独 CRC 反过来

Modbus 所有多字节字段都是高字节在前（大端），地址、数量、寄存器值无一例外。但 CRC 是个例外：计算出来的 CRC 是 16 位，放到报文末尾时低字节在前、高字节在后。资料里反复强调"CRC 校验在命令中的高低字节的顺序和其他的相反"，这不是笔误，而是历史实现留下的约定。

常见的实现思路是：CRC 按多项式逐位算出一个 16 位值，发送时先发低 8 位再发高 8 位；接收方收到后同样按低前高后拼回 16 位再比对。很多自研代码在这里翻车——值算对了，拼装顺序反了，从机直接丢帧不响应，你还以为是地址错了。下面这段是常见的 CRC 计算与拼装写法：

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 # 多项式 0xA001，低位在前 else: crc >>= 1 return crc frame = bytes([0x11, 0x03, 0x00, 0x6B, 0x00, 0x03]) crc = crc16_modbus(frame) # 注意：低字节先入帧，高字节后入帧 frame += bytes([crc & 0xFF, (crc >> 8) & 0xFF])

crc16_modbus对除 CRC 外的所有字节做异或移位，初值 0xFFFF、多项式 0xA001 是 Modbus 的固定参数，不能换。最后两行是重点：crc & 0xFF是低字节，先拼；crc >> 8是高字节，后拼。把这两行写反，帧就废了，而且从机通常静默丢弃，不给你任何错误提示，排查起来非常费劲。

3. 读写四件套：01/02/03/04 的位与字之争

3.1 线圈和寄存器是两套地址空间

01 读线圈、02 读输入状态、03 读保持寄存器、04 读输入寄存器，这四个是最常用的读功能码。它们的区别不只是"读什么"，而是两套完全不同的数据模型。

线圈（Coil）和离散输入（Discrete Input）是位级的，一个地址对应一个开关量，ON/OFF。保持寄存器（Holding Register）和输入寄存器（Input Register）是字级的，一个地址对应一个 16 位整数。这两套空间各自独立编号，地址 0 在线圈空间和寄存器空间里是两个完全不同的东西。资料里 01 的例子起始地址 19、读 37 个开关量，返回 5 个字节（37 位需要 5 字节，最后一字节高位补 0），这就是位打包的典型形态。

为什么这么分？因为工业现场的信号本来就分两类：继电器、限位开关、指示灯这类是开关量，传感器测量值、设定参数这类是模拟量。协议用两套地址空间把语义隔开，主站读的时候功能码一选，就知道该按位解析还是按字解析，不用额外标注类型。

3.2 位打包：一个字节装 8 个开关

01 和 02 的应答里，数据是按字节打包的，每个字节的每一位对应一个线圈，低位对应低地址。资料里说得很清楚：返回[CD]，二进制 1100 1101，表示 20 号闭合、21 号断开、22 闭合、23 闭合、24 断开、25 断开、26 闭合、27 闭合。这里有个细节：如果请求的开关量不是 8 的整数倍，最后一个字节的高位无意义，置 0。

这个"低位在前"的位序，和字节的大端序是两回事，很多人会混。字节层面是高字节在前，但字节内部的位是低位对应小地址。解析时常见的写法是：

def unpack_bits(payload: bytes, count: int) -> list: bits = [] for byte in payload: for i in range(8): if len(bits) >= count: break bits.append((byte >> i) & 0x01) # 低位对应小地址 return bits

byte >> i & 0x01从最低位开始取，正好对应地址从小到大。如果反过来从最高位取，读出来的开关状态会整体错位，现场表现就是"灯亮灭和实际对不上"，这种玄学问题查半天往往就是位序写反了。

3.3 05 和 06：写单个为什么数据格式这么怪

05 强置单线圈，数据区是"地址 2 字节 + 数据 2 字节"，但数据只允许两个值：FF00表示闭合，0000表示断开，其他值非法。资料里特别强调"此处只可以是 [FF][00] 表示闭合 [00][00] 表示断开，其他数值非法"。为什么不用 0001 表示闭合？因为这样设计让写单线圈和写单寄存器在报文长度上完全一致，都是 8 字节，从机可以用同一套长度校验逻辑处理 05 和 06，减少实现分支。这是典型的"用冗余编码换实现简单"的取舍。

06 预置单寄存器则直接写 16 位值，比如[11][06][00][01][00][03]把 1 号寄存器设为 3。05 和 06 的应答都是原样回显请求，成功就回一模一样的 8 字节，失败则不响应或回异常帧。这种"回显即确认"的机制很省事，主站只要比对发出去的帧和收到的帧是否一致，就知道写成功没有。

注意：05/06 成功时从机回显原请求，所以主站不能靠"收到应答"判断写成功，必须逐字节比对。有些从机在地址越界时会回异常帧（功能码最高位置 1），这时功能码变成 0x85 或 0x86，要和正常回显区分开。

3.4 15 和 16：批量写的字节数从哪来

15 强置多线圈、16 预置多寄存器是 05/06 的批量版。它们的请求里多了一个"字节数"字段，因为要写的数据长度不固定。16 的请求结构是"起始地址 2 + 寄存器数量 2 + 字节数 1 + 数据 N + CRC 2"，字节数必须等于寄存器数量 ×2。15 则是"起始地址 2 + 线圈数量 2 + 字节数 1 + 数据 N + CRC 2"，字节数等于 (线圈数量+7)/8 向上取整。

这里有个血泪经验：字节数字段是从机校验的第一道关。如果字节数和数量对不上，合格的从机会直接回异常码 03（非法数据值）。但市面上不少廉价从机不做这个校验，直接按自己的理解截取数据，结果就是写进去的值莫名其妙。所以主站侧最好自己先算一遍字节数，别指望从机帮你兜底。

4. 异常应答与诊断功能码：出错时协议怎么说话

4.1 功能码最高位置 1 就是异常

Modbus 的错误处理极其克制：正常功能码是 01～127，异常应答时把功能码最高位置 1，也就是加 0x80，然后在数据区放一个异常码。比如 03 出错回 0x83，01 出错回 0x81。异常码常见的有 01 非法功能、02 非法数据地址、03 非法数据值、04 从机设备故障。

这个设计的好处是解析路径极短：接收方读到功能码 ≥0x80，立刻知道这是异常帧，数据区第一个字节就是异常码，不用再猜。资料里 128～255 保留用于异常应答，正是这个机制的地址空间划分。很多自研主站只处理正常帧，遇到 0x83 还按正常 03 去解析字节数，结果越界读或解析出垃圾值，然后怀疑从机坏了——其实是从机在明确告诉你"地址非法"。

4.2 08 回送诊断和 11 读事件计数

08 回送诊断校验、11 读取事件计数、12 读取通信事件记录，这三个是诊断类功能码，日常读写用不到，但排查通信问题时很有价值。08 让从机把诊断报文原样送回，用来评估链路质量；11 让主站查询从机记录的操作成功/失败次数；12 则能检索通信事件日志，定位是哪次事务出了错。

这类功能码的存在说明 Modbus 的设计者早就意识到：串行链路的故障是常态，协议必须自带"体检"手段。485 总线上挂十几个设备，某台偶尔丢帧，光看读写结果很难定位是线路、地址冲突还是从机忙。用 08 做回环测试、用 11 看错误计数，能把问题范围缩小到具体环节。不过要注意，这些功能码不是所有从机都实现，资料里 09/10 标注"只用于 484"、13/14 标注"184/384/484/584"、18 标注"884 和 MICRO 84"，说明功能码的支持范围跟设备型号强相关，用之前得查从机手册。

4.3 19 重置通信链路：最后的后悔药

19 重置通信链路的作用是：发生不可修改错误后，让从机复位到已知状态。这相当于给链路一个"后悔药"——当从机因为干扰、帧错位进入异常状态，正常读写都不响应时，发一条 19 让它重新初始化通信状态机，往往能救回来。

常见的实现思路是：主站检测到连续 N 次超时或 CRC 错，先发 19 重置，再重试读写；如果重置也失败，才判定设备离线。这个策略比一上来就报"设备故障"务实得多，因为工业现场的电磁干扰导致的偶发帧错，重置一下就好了，没必要惊动运维。

5. 避坑与排查：那些让报文"看起来对却不工作"的细节

5.1 现象：从机完全不响应，连异常帧都没有

原因通常有三类。一是CRC 字节序反了，帧在物理层就被从机丢弃，不会有任何回话；二是设备地址错，资料里例子用 0x11 即十进制 17，如果你按 1 号设备发，17 号不会理你；三是波特率/校验位不匹配，物理层就收不对。排查顺序建议：先用 08 诊断功能码做回环，确认链路通；再单独发一条 03 读 1 个寄存器，用示波器或串口助手看从机有没有回字节；最后核对 CRC 拼装顺序。

5.2 现象：读回来的数值总是差一位或错半截

多半是地址基准搞混。Modbus 协议里地址从 0 开始，但很多设备手册用 1 开始编号（叫"寄存器号"），两者差 1。资料里明确"起始地址为 0"，如果你照着手册的 40001 直接填 40001，实际访问的是协议地址 40000，读到的自然是隔壁寄存器的值。另一个常见原因是把寄存器数量当字节数，读 3 个寄存器只解析了 3 字节，后一个半寄存器丢了。

5.3 现象：写线圈成功但设备没动作

先确认写的是不是FF00/0000。05 功能码只认这两个值，写0001很多从机会当非法值丢弃，但因为 05 成功时是回显，有些实现连非法值也回显，主站以为成功了，设备却没动。其次确认线圈地址空间——线圈和寄存器是两套独立地址，写线圈地址 0 和写寄存器地址 0 是两回事。最后看设备是否需要"使能位"配合，有些执行器要求先写使能寄存器再写动作线圈。

5.4 现象：批量写 16 功能码，部分寄存器没更新

检查字节数字段是否等于寄存器数量 ×2。字节数算错，从机可能只解析前几个寄存器就停，后面的静默丢弃。另外注意单次写入的寄存器数量上限，协议理论上限是 123 个（受报文长度约束），但很多从机实现得更小，超了会回异常码 03。分批写时每批之间留一点间隔，避免从机处理不过来。

5.5 现象：偶发 CRC 错，重发就好

这是 485 总线的典型干扰问题，不是协议 bug。排查方向：终端电阻是否接、屏蔽层是否单点接地、总线是否走了强电旁边、波特率是否过高导致采样点偏移。软件侧可以加重试机制：连续 3 次 CRC 错就发 19 重置链路，再失败才报离线。别把偶发帧错当设备故障处理，那样只会让运维白跑。

6. 设计取舍：为什么 Modbus 用"笨"换来了四十年生命力

回头看这套功能码体系，它几乎在每个维度上都做了"反直觉"的选择：报文没有长度字段，靠功能码隐式决定布局；没有会话概念，一问一答、无状态；错误处理只有最高位一个标志；地址空间按数据类型硬切，不能动态扩展。用今天的眼光看，这些都是"设计缺陷"。但正是这些取舍，让它在工业现场活了四十多年。

用隐式布局换解析简单。没有长度字段意味着接收方必须靠功能码查表才知道读几个字节，扩展性确实差，但换来的是解析器可以做到极小——一个 8 位单片机的 ROM 就能装下。工业现场的从机往往是资源受限的嵌入式设备，这个取舍直接决定了协议能不能落地。

用无状态换实现可靠。Modbus 没有连接、没有握手、没有重传机制，主站发一帧、从机回一帧，事务结束。链路断了就超时，重发由应用层决定。这种"笨"设计让从机不需要维护会话状态，掉电重启后立刻可用，不会出现"连接卡死"这类玄学问题。

用固定地址空间换互操作性。线圈、离散输入、保持寄存器、输入寄存器四块地址空间是硬编码的，不同厂商的设备只要遵守这个划分，主站就能用同一套代码访问。代价是地址空间不能按设备定制，但换来的是"插上就能读"的通用性——这正是摘要里说的"不同厂商生产的控制设备能连成工业网络"的底层原因。

我一般会这么理解：Modbus 不是为性能或功能设计的，是为可预测性设计的。你知道发什么、收什么、错了怎么回，一切都在一张表里。这份资料把 21 个功能码和报文实例摊开，价值不在于让你背表，而在于让你看到每个字节为什么在那儿。从那以后我每次调新设备，都强制先用 03 读一个已知寄存器、用 08 做一次回环、再核对 CRC 拼装顺序，三步走完再动业务逻辑，能省掉大半排查时间。希望帮到你。

本文还有配套的精品资源，点击获取