1. 从站地址与寄存器映射最容易翻车的两个地方1.1 从站地址不是随便设一个就行Modbus RTU 的从站地址Slave ID看起来是最简单的参数填个 1 到 247 之间的数字就完事了。但我见过太多现场问题恰恰出在这个最简单的地方。先说一个真实场景。某次调试一条产线主站是汇川 PLC从站是一台变频器和一台温控仪表。变频器地址设的是 1温控仪表出厂默认也是 1。上电之后PLC 读温控仪表的温度值读回来的却是变频器的输出频率。查了半天接线、波特率、校验位最后才发现是地址冲突。Modbus RTU 是总线型主从结构同一时刻总线上只能有一个从站响应主站的请求。两个从站地址相同它们会同时驱动 485 芯片的发送使能总线上的数据直接打架主站收到的报文要么 CRC 校验失败要么就是两个从站数据的混合体。所以第一条铁律上电前先列一张地址分配表。把总线上所有从站的地址、型号、寄存器映射范围全部写清楚贴在电柜门内侧。这不是形式主义是给自己和后来接手的人省时间。地址范围也有讲究。标准 Modbus 协议规定从站地址有效范围是 1 到 2470 是广播地址248 到 255 保留。有些国产仪表出厂默认地址是 1有些是 2还有些是 0。如果你拿到一台新设备第一件事就是查手册确认默认地址然后改成你规划好的地址。改地址通常通过面板按键或者专用配置软件完成改完之后一定要断电重启再验证。还有一个隐蔽的坑部分设备的地址设置是通过拨码开关实现的但拨码开关的二进制顺序和你想的可能不一样。比如某品牌温控仪拨码开关标注的是 1、2、4、8、16、32、64但实际读法是反的——最左边是低位。我遇到过一位同行把拨码拨成1000000以为地址是 64实际设备识别成 1。这种问题看手册能解决但手册往往写得含糊最稳妥的办法是改完地址后用主站发一帧读保持寄存器的报文看从站是否响应响应了再继续。1.2 寄存器地址的偏移量陷阱寄存器地址是 Modbus RTU 里另一个高频翻车点。核心问题在于协议文档里的地址、PLC 编程软件里的地址、实际报文里的地址三者可能不是同一个数。Modbus 协议定义了四种数据区数据区对象类型访问方式地址范围常见称呼线圈位读写00001-09999Coil、DO离散输入位只读10001-19999Discrete Input、DI输入寄存器16位字只读30001-39999Input Register、AI保持寄存器16位字读写40001-49999Holding Register、AO问题出在报文里传输的地址是从 0 开始的而文档里写的地址往往是从 1 开始的。比如你要读 40001 寄存器报文里的地址字段是 0x0000读 40002报文里是 0x0001。这个减一操作很多新手不知道导致读回来的数据总是差一个寄存器。更麻烦的是不同厂家对地址的表述方式还不一样。有的手册写40001有的写0x0000有的写寄存器 0有的写地址 1。我整理了一个对照表遇到新设备先按这个表换算手册写法实际报文地址十六进制说明400010x0000标准 Modbus 文档写法减一后转十六进制400020x0001同上0x00000x0000直接就是报文地址寄存器 00x0000直接就是报文地址地址 10x0000减一地址 00x0000直接就是报文地址提示遇到读回来的数据明显不对比如温度值读成了 65535 或者 0先检查地址偏移再检查数据类型。很多温控仪表温度值是 16 位有符号整数但小数点位数是单独的寄存器控制的读回来 253 可能代表 25.3 度。还有一个进阶坑32 位数据的寄存器顺序。有些设备的一个物理量比如累计流量、电能是 32 位浮点数或长整数占用两个连续的保持寄存器。但这两个寄存器的顺序可能是高字在前、低字在后也可能是反过来。更坑的是有些设备支持字交换配置你可以在设备菜单里改。我建议的做法是先用主站读两个寄存器把原始值记下来然后对照设备手册里的数据格式说明手动拼一次确认无误后再写进 PLC 程序。2. CRC 校验报文正确性的最后一道防线2.1 CRC 到底在算什么CRC循环冗余校验是 Modbus RTU 报文末尾的两个字节用来验证整帧数据在传输过程中有没有出错。它的计算对象是从站地址到数据域的最后一个字节不包括 CRC 本身。很多同行对 CRC 的态度是反正协议栈会自动算不用管。这话在大部分时候没错但一旦出问题不懂 CRC 就会让你多花好几个小时。我经历过一次现场干扰导致的偶发通讯失败主站日志里全是 CRC 错误但换线、换终端电阻、降低波特率都试过了问题依旧。最后用示波器抓波形才发现是变频器启停时产生的尖峰干扰耦合到了 485 总线上把某几个位翻转了。如果当时懂 CRC 的计算原理就能从错误报文的 CRC 值反推出是哪几个位出了问题定位干扰源会快很多。CRC-16/Modbus 的计算规则如下初始值0xFFFF多项式0xA001这是 0x8005 的反转表示处理方式每个字节先与 CRC 低字节异或然后右移 8 次每次移出位为 1 就异或多项式最终结果低字节在前高字节在后用 Python 实现一个 CRC 计算函数方便调试时验证def crc16_modbus(data: bytes) - bytes: crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 # Modbus RTU 要求低字节在前 return bytes([crc 0xFF, (crc 8) 0xFF]) # 测试读从站1的保持寄存器0x0000读1个寄存器 frame bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x01]) print(crc16_modbus(frame).hex()) # 输出应该是 840a这段代码可以直接复制到你的调试脚本里。当你怀疑主站发出的报文有问题时把报文抓出来手动算一遍 CRC和报文末尾的两个字节对比就能确认是主站的问题还是从站的问题。2.2 CRC 错误的排查链路CRC 错误是 Modbus RTU 现场调试中最常见的故障现象。主站报CRC 校验失败或者响应超时背后可能的原因有一长串。我按排查优先级列一个清单第一步确认波特率和校验位。这是最容易被忽略的。主站设 9600、8、N、1从站设 9600、8、E、1报文结构就不一样CRC 必然错。有些设备支持自动波特率识别但识别需要时间上电后前几帧可能失败这是正常的。第二步检查接线。RS485 是差分信号A 接 A、B 接 B。但有些厂家标的是 D、D-或者 485、485-对应关系是 A 接 D、B 接 D-。如果接反了数据能通但误码率极高表现为偶发 CRC 错误。另外屏蔽层要单端接地两端都接地会形成地环流反而引入干扰。第三步终端电阻。RS485 总线两端各需要一个 120 欧姆的终端电阻中间节点不需要。如果总线很短比如小于 10 米不加终端电阻也能凑合但如果总线超过 50 米或者波特率高于 19200不加终端电阻就会出现信号反射导致 CRC 错误。我见过一个案例总线长度 80 米波特率 38400没加终端电阻通讯成功率只有 60%加上之后立刻稳定。第四步共地问题。RS485 是差分信号理论上不需要共地但实际上如果两个设备的参考地电位差太大会超出 485 芯片的共模输入范围导致误码。解决办法是用一根单独的线把两个设备的 GND 连起来或者使用带隔离的 485 转换器。第五步干扰源排查。变频器、伺服驱动器、大功率接触器都是常见的干扰源。如果 CRC 错误只在特定设备启动时出现基本可以锁定干扰源。解决办法包括485 线远离动力线、使用双绞屏蔽线、在干扰源侧加装滤波器、降低波特率。注意有些 USB 转 485 转换器质量很差芯片用的是廉价方案在 115200 以上波特率时误码率很高。如果你用的是这种转换器先把波特率降到 9600 试试如果 9600 稳定而 115200 不稳定基本就是转换器的问题。3. RS485 硬件层那些教科书不会告诉你的细节3.1 自收发电路的延时问题很多嵌入式项目里RS485 收发切换是用 MCU 的一个 GPIO 控制 485 芯片的 DE/RE 引脚。发送时拉高 DE发送完拉低 DE 切换到接收。这个发送完的时机判断就是一个大坑。如果你用的是 UART 的发送完成中断那没问题硬件会等最后一个字节的停止位发完再触发中断。但如果你用的是发送空中断TXE那就有问题了——TXE 只表示发送数据寄存器空了但移位寄存器里可能还有数据没发完。这时候你拉低 DE最后一个字节就会被截断从站收到的报文 CRC 必然错。正确的做法是用发送完成中断TC来切换 DE或者在 TXE 中断里加一个延时延时时间大于一个字节的传输时间。以 9600 波特率为例一个字节 10 位1 起始位 8 数据位 1 停止位传输时间是 10/9600 ≈ 1.04 毫秒。保险起见延时 1.5 到 2 个字节时间。还有一个更隐蔽的问题DE 拉低之后485 芯片的接收使能需要时间。有些芯片的 RE 和 DE 是同一个引脚控制的DE 拉低的同时 RE 有效但芯片内部从发送模式切换到接收模式需要几百纳秒到几微秒。如果从站响应非常快主站可能还没切换好就收到了从站的应答导致丢失第一个字节。解决办法是在 DE 拉低后加一个小延时再开始接收或者选用 DE/RE 独立控制的芯片。3.2 高波特率下的硬件要求230400 波特率在 Modbus RTU 里算是比较高的。这个速率下一个字节的传输时间只有约 43 微秒对硬件的要求比 9600 高得多。首先是线缆。9600 波特率下普通的平行线甚至排线都能凑合但 230400 下必须用双绞线而且特性阻抗要接近 120 欧姆。我实测过用普通的杜邦线在 230400 下通讯超过 1 米就开始出现 CRC 错误换成双绞屏蔽线后 10 米内稳定。其次是终端电阻。高波特率下信号反射的影响更大终端电阻必须加而且阻值要准确。120 欧姆是标准值但实际线缆的特性阻抗可能在 100 到 150 欧姆之间如果通讯距离长可以用示波器看波形调整终端电阻阻值让反射最小。第三是485 芯片的压摆率。有些 485 芯片的压摆率是固定的适合中低波特率高波特率下需要选用压摆率更高的型号或者选用支持速率可配置的芯片。如果芯片压摆率不够波形上升沿变缓眼图闭合误码率就会上升。第四是隔离。如果总线上有变频器等干扰源或者两个设备的地电位差较大建议使用隔离型 485 芯片或外置隔离器。隔离器会增加一点传输延时但在 230400 下隔离器的延时通常在纳秒级影响可以忽略。3.3 总线拓扑与分支长度RS485 标准推荐的是手拉手菊花链拓扑不支持星型或树型。但实际现场往往做不到比如电柜里接线端子排的位置导致必须分出几路。分支长度是有限制的。经验值是分支长度不超过总线总长度的 1/10且绝对长度不超过 5 米。如果分支太长分支末端会产生反射影响整个总线的信号质量。我见过一个典型的错误案例一条总线主干 100 米中间用 T 型接头分出了 3 路每路 10 米。结果通讯极不稳定波特率降到 4800 才能勉强通讯。后来把 T 型接头改成菊花链分支缩短到 1 米以内9600 波特率下通讯立刻稳定。如果现场确实无法做菊花链可以考虑使用 485 集线器或中继器把星型拓扑转换成多个菊花链段。集线器每个端口都是独立的驱动不会互相干扰。4. 报文层面的实战解析4.1 03 功能码报文详解03 功能码是 Modbus RTU 里最常用的用来读保持寄存器。我拿一个实际报文来拆解主站请求读从站 1 的 40001 和 40002 两个寄存器01 03 00 00 00 02 C4 0B字节含义说明01从站地址目标从站地址为 103功能码读保持寄存器00 00起始地址40001 对应报文地址 0x000000 02寄存器数量读 2 个寄存器C4 0BCRC 校验低字节 C4 在前高字节 0B 在后从站正常响应01 03 04 00 64 00 C8 3A 7E字节含义说明01从站地址回显主站请求的地址03功能码回显功能码04字节数2 个寄存器 × 2 字节 4 字节00 64寄存器 1 数据十进制 10000 C8寄存器 2 数据十进制 2003A 7ECRC 校验对前面所有字节计算从站异常响应01 83 02 C0 F1字节含义说明01从站地址回显地址83功能码03 的最高位置 1表示异常02异常码02 表示非法数据地址C0 F1CRC 校验异常码的含义需要记一下异常码含义常见原因01非法功能从站不支持该功能码02非法数据地址寄存器地址超出从站支持范围03非法数据值写入的数据超出允许范围04从站设备故障从站内部错误05确认从站已接受请求正在处理06从站设备忙从站暂时无法处理稍后重试提示如果主站收到异常响应先看异常码。02 通常是地址偏移算错了03 通常是写入值超范围06 通常是主站轮询太快从站来不及处理加长轮询间隔即可。4.2 报文间隔与 3.5 字符时间Modbus RTU 规定一帧报文结束的标志是至少 3.5 个字符时间的静默间隔。在 9600 波特率下一个字符时间约 1.04 毫秒3.5 个字符时间约 3.65 毫秒。如果两帧之间的间隔小于 3.5 个字符时间从站会认为它们属于同一帧导致解析错误。这个规则在低速下容易满足但在高波特率下就需要注意了。230400 波特率下3.5 个字符时间只有约 152 微秒。如果主站程序轮询太快或者操作系统调度导致发送间隔不稳定就可能违反这个规则。我在 Linux 系统上用 C 语言写 Modbus 主站时遇到过这个问题。Linux 不是实时系统write()调用返回后数据可能还在内核缓冲区里实际发送时间不确定。如果连续调用两次write()中间间隔可能小于 3.5 个字符时间。解决办法是在两次发送之间加一个usleep()延时时间设为 4 个字符时间以上。更稳妥的做法是用tcdrain()等待数据真正发送完毕再加延时。还有一个相关的问题从站的响应超时时间。主站发出请求后需要等待从站响应。如果从站没响应主站不能无限等待要设置一个超时时间。标准建议是超时时间 从站最大响应时间 传输时间。实际工程中我一般设 300 到 500 毫秒。如果从站响应慢比如某些仪表内部处理需要时间可以适当加长。4.3 广播与特殊功能码Modbus RTU 支持广播从站地址为 0 时所有从站都会接收报文但不响应。广播通常用于写操作比如同时启动所有从站的某个功能。但广播有个坑从站不响应主站无法确认广播是否成功。如果某个从站没收到广播主站也不知道。所以广播只适合对可靠性要求不高的场景或者配合后续的读操作来验证。另外有些设备支持自定义功能码比如 0x41、0x42 等。这些功能码不在标准 Modbus 协议里需要查设备手册。遇到不认识的设备先用标准功能码试如果返回异常码 01非法功能再查手册看是否支持自定义功能码。5. 调试工具与实战技巧5.1 必备的调试工具清单调试 Modbus RTU光靠 PLC 的编程软件不够还需要一些辅助工具。我列一下我常用的工具用途推荐型号/软件USB 转 485 转换器连接 PC 和 485 总线选用带隔离的工业级产品串口调试助手手动收发报文SSCOM、ComAssistantModbus 主站模拟软件模拟主站轮询Modbus PollModbus 从站模拟软件模拟从站响应Modbus Slave示波器抓波形分析信号质量带宽 100MHz 以上万用表测电压、通断带真有效值功能终端电阻总线匹配120 欧姆1/4 瓦其中Modbus Poll 和 Modbus Slave 是最值得花时间掌握的。Modbus Poll 可以模拟主站自定义报文、轮询间隔、超时时间还能记录通讯日志。当你怀疑 PLC 程序有问题时用 Modbus Poll 直接连从站如果通讯正常说明问题在 PLC 程序如果也不正常说明问题在硬件或从站配置。5.2 用示波器抓 485 波形示波器是排查 485 硬件问题的利器。把探头接到 485 的 A、B 线上可以看到差分波形。正常的 485 波形应该是干净的方波上升沿和下降沿陡峭没有明显的过冲和振铃。如果波形出现过冲或振铃说明终端电阻不匹配或者分支太长。如果波形上升沿变缓说明线缆电容太大或者 485 芯片驱动能力不足。如果波形上有毛刺说明有干扰源。抓波形时建议用单次触发模式触发条件设为某个特定字节的起始位。这样可以抓到完整的报文波形方便分析。另外用双通道示波器同时抓 A 线和 B 线可以看到差分信号的真实形态。5.3 轮询策略与性能优化Modbus RTU 是轮询式通讯主站依次询问每个从站。轮询策略直接影响通讯效率。轮询间隔从站响应后主站需要等待 3.5 个字符时间才能发下一帧。实际工程中我一般设 10 到 50 毫秒的间隔。间隔太短会违反协议太长会降低刷新率。轮询顺序把响应快的从站排在前面响应慢的排在后面。如果某个从站经常超时把它单独放在一个轮询周期里避免拖慢其他从站。数据合并如果从站支持尽量一次读取多个连续寄存器减少报文数量。比如需要读 40001 到 40010 十个寄存器一次读十个比读十次一次要快得多。超时重试从站超时后不要立即重试先等一个轮询周期。如果连续多次超时再判断从站离线。重试次数一般设 2 到 3 次。优先级如果有紧急数据需要读取可以在轮询队列里插入高优先级请求。但要注意不要打乱正常的轮询节奏否则可能导致从站响应混乱。6. 那些年我踩过的坑6.1 地址偏移导致的数据错位有一次调试一台温控仪表手册上写温度值寄存器地址 0x0000我直接在 PLC 里读 40001。读回来的值是 253但实际温度是 25.3 度。我以为小数点位数没设对查了半天仪表参数最后发现是地址偏移问题——手册写的 0x0000 是报文地址对应 PLC 里的 40001这个没错。但温度值确实是 253需要除以 10 才是实际温度。问题出在我把小数点位数和地址偏移搞混了。这个坑的教训是读回来的数据不对先确认三件事——地址对不对、数据类型对不对、缩放系数对不对。这三件事按顺序排查能解决 90% 的数据异常问题。6.2 终端电阻引发的偶发通讯失败另一个印象深刻的案例是一条 200 米长的总线波特率 19200通讯成功率大概 95%偶尔丢一帧。因为丢帧不频繁现场人员没太在意但数据记录仪上会出现数据缺口。我到现场后先测了终端电阻发现只有一端有 120 欧姆另一端没有。加上终端电阻后通讯成功率提升到 99.9%。但还有偶发失败继续查发现是总线中间有一段和动力线平行走了 5 米虽然用的是屏蔽线但屏蔽层两端都接地了形成了地环流。把屏蔽层改成单端接地后通讯完全稳定。这个案例说明偶发故障往往不是单一原因而是多个小问题叠加。排查时要一个一个解决每解决一个就观察一段时间确认效果后再继续。6.3 高波特率下的隐形丢包230400 波特率下我遇到过一种很奇怪的现象主站发送的报文从站有时候响应有时候不响应但用示波器看波形完全正常。后来用串口分析仪抓数据发现主站发送的报文里偶尔会多出一个字节或者少一个字节。原因是主站程序在发送报文时没有等上一帧完全发送完毕就修改了发送缓冲区。在低波特率下发送一帧需要几十毫秒程序有足够时间处理但在 230400 下发送一帧只需要几毫秒程序还没来得及处理下一帧就开始了。解决办法是发送和接收用独立的缓冲区发送完成后再处理接收数据。或者用 DMA 发送发送完成中断里再切换缓冲区。这个坑在低波特率下不会出现一旦提高波特率就暴露出来很有代表性。6.4 从站响应超时设置的经验值从站响应超时时间设多少合适手册上一般会给一个值但实际工程中需要根据情况调整。我的一般原则是超时时间 从站最大处理时间 报文传输时间 × 2 余量。从站最大处理时间查手册报文传输时间按波特率算余量取 50 到 100 毫秒。比如一个从站手册写响应时间小于 50 毫秒波特率 9600报文长度 8 字节传输时间约 8.3 毫秒。那么超时时间 50 8.3 × 2 50 ≈ 117 毫秒取整设 150 毫秒。如果超时时间设得太短从站还没处理完主站就超时了会误判从站离线。设得太长从站真离线时主站要等很久才发现影响系统响应速度。7. 从站模拟与程序验证7.1 用 Modbus Slave 验证主站程序写完 PLC 或上位机的主站程序后不要急着连真实从站先用 Modbus Slave 模拟一个从站验证主站程序是否正确。Modbus Slave 可以设置从站地址、寄存器初始值、响应延时等参数。把主站程序连到 Modbus Slave观察读写是否正常。如果 Modbus Slave 能正常响应说明主站程序没问题再去连真实从站。这个步骤能帮你排除主站程序的问题把排查范围缩小到硬件和从站配置。我见过很多同行跳过这一步直接连真实设备结果主站程序和从站配置都有问题排查起来非常痛苦。7.2 用脚本批量测试寄存器如果需要验证大量寄存器的读写手动一个个测太慢。可以写一个 Python 脚本用pymodbus库批量测试。from pymodbus.client import ModbusSerialClient import time client ModbusSerialClient( port/dev/ttyUSB0, baudrate9600, parityN, stopbits1, bytesize8, timeout0.5 ) client.connect() # 批量读取 0 到 99 号保持寄存器 for addr in range(0, 100): try: result client.read_holding_registers(addr, 1, slave1) if not result.isError(): print(f寄存器 {addr}: {result.registers[0]}) else: print(f寄存器 {addr}: 异常 {result}) except Exception as e: print(f寄存器 {addr}: 超时或错误 {e}) time.sleep(0.05) client.close()这个脚本能快速摸清从站支持哪些寄存器、哪些地址会返回异常。对于不熟悉的设备先用这个脚本扫一遍能省很多查手册的时间。7.3 日志记录与问题回溯调试完成后建议在主站程序里加一个通讯日志功能记录每次请求的报文、响应报文、时间戳、耗时。正常运行时日志可以关掉或者只记录异常但调试阶段一定要开。日志的价值在于当现场出现偶发故障时你可以回溯日志看故障发生前后的通讯情况。比如某个从站超时前是否有 CRC 错误是否有异常响应这些信息能帮你快速定位问题。日志格式建议用 CSV 或 JSON方便后续用脚本分析。字段包括时间戳、从站地址、功能码、请求报文、响应报文、耗时、状态。8. 跨品牌设备混用的注意事项8.1 不同品牌对协议的理解差异Modbus 是标准协议但不同厂家对标准的理解有差异。我遇到过几种典型情况寄存器地址基数不同。有的厂家从 0 开始编号有的从 1 开始。手册上写寄存器 1实际报文地址可能是 0x0000 也可能是 0x0001。这个只能试或者查手册的详细说明。数据类型不同。同样是温度值有的用 16 位有符号整数有的用 16 位无符号整数有的用 32 位浮点数。读回来数据不对先确认数据类型。字节序不同。32 位数据的高字和低字顺序不同厂家可能不同。有的还支持字交换配置。这个需要查手册或者用已知值反推。异常响应不同。标准规定异常响应的功能码是原功能码加 0x80但有些设备不遵守直接返回原功能码加错误数据。遇到这种情况只能靠 CRC 和超时来判断。8.2 混用时的兼容性测试跨品牌混用时建议做一轮兼容性测试用 Modbus Poll 分别连每个从站确认单独通讯正常。把所有从站接到同一总线用 Modbus Poll 依次轮询确认无冲突。把主站程序接入观察通讯是否稳定。模拟现场干扰比如启停变频器观察通讯是否受影响。长时间运行至少 24 小时记录通讯成功率。这个测试流程能发现大部分兼容性问题。如果测试中发现某个从站响应异常先单独测试该从站确认是设备本身的问题还是总线的问题。8.3 地址规划与文档管理跨品牌混用时地址规划尤为重要。我建议做一个地址分配表包含以下字段从站地址设备型号寄存器地址数据含义数据类型缩放系数备注1温控仪表40001温度值int160.1单位摄氏度1温控仪表40002设定值int160.1读写2变频器40001输出频率uint160.01单位 Hz2变频器40002输出电流uint160.01单位 A这张表要随着项目更新每次增加或修改从站都要更新。项目交接时这张表比程序本身还重要。9. 写在最后的一些个人体会Modbus RTU 这个协议入门很容易但要用好、用稳需要踩不少坑。我这些年最大的体会是协议本身不复杂复杂的是现场环境。同样的程序在实验室跑得好好的到了现场就可能出各种问题。线缆、干扰、接地、终端电阻、从站兼容性每一个环节都可能成为瓶颈。另一个体会是调试工具要舍得投入。一个好的 USB 转 485 转换器、一个带隔离的示波器、一套 Modbus Poll/Slave 软件能帮你省下大量排查时间。我见过太多同行用几十块钱的转换器出了问题就怀疑程序最后发现是转换器本身不稳定。还有一点文档和日志要养成习惯。地址分配表、通讯日志、调试记录这些东西在项目顺利时看不出价值一旦出问题就是救命稻草。我现在每个项目都会维护一份通讯文档记录所有从站的地址、寄存器映射、特殊配置以及调试过程中遇到的问题和解决办法。这份文档不仅帮自己也帮接手的人。最后分享一个小技巧如果你不确定某个从站支持哪些功能码和寄存器可以用 Modbus Poll 的扫描功能或者自己写脚本遍历。先发一个读请求看从站是否响应如果响应异常码 01说明不支持该功能码如果响应异常码 02说明地址不对。通过这种方式能快速摸清从站的能力边界比翻手册快得多。
