1. 项目概述这不是代码 bug也不是硬件故障而是工业现场的“幽灵断连”“代码没问题设备没坏但就是收不到 Modbus 数据”——这句话我听过的次数比调试用掉的串口线还多。它不是一句抱怨而是一道精准的诊断切口直指工业自动化现场最典型、也最容易被忽视的“非软非硬”故障域。Modbus 协议本身简单得像一张白纸主站发请求帧从站回响应帧校验、地址、功能码、数据区逻辑清晰。可一旦落到真实产线、配电柜、控制箱里这张纸就立刻被环境、接线、时序、配置、甚至空气湿度揉皱、浸湿、撕裂。你写的 FreeModbus 移植代码在 Keil 里单步跑得飞起STM32F103 的 UART 波形在示波器上干净利落CH340 转换芯片的驱动在 Windows 设备管理器里绿灯常亮但 Modbus Poll 就是固执地显示“Timeout”或者“Invalid Response”。问题不在编译器不在芯片手册而在你手里的万用表探针还没碰上那根 RS485 的 A/B 线或者你刚拔下来的 USB 转串口线插头正躺在积灰的接线端子排旁边。这个标题背后藏着一个完整的工业通信链路从主站PC 上的 Modbus Poll 或定制上位机出发经过 USB 转串口芯片CH340/FTDI再经由 RS485 收发器SP3485、MAX485穿过几十米长的双绞屏蔽线最终抵达从站PLC、智能电表、变频器或你自己的 STM32 板子。这中间任何一个环节的“微小偏差”都足以让整个 Modbus RTU 帧在物理层上无声湮灭。而这些偏差恰恰是教科书和芯片数据手册里绝不会写明的比如 RS485 终端电阻该不该加、加在哪一端比如 CH340 驱动安装后Windows 自动分配的 COM 口编号与你代码里硬编码的COM3是否一致比如 Modbus Poll 里那个不起眼的“RTU Mode”复选框如果误勾了“ASCII Mode”你看到的就不是乱码而是彻底的沉默。所以这篇内容不是教你如何写 Modbus 协议栈而是带你回到调试现场用一把螺丝刀、一块万用表、一个串口助手把那些藏在“代码没问题”和“设备没坏”之间的灰色地带一寸寸翻出来、照亮、踩实。它适合所有在产线、在配电室、在客户现场拧螺丝、接线、看波形、改参数的工程师无论你是刚毕业的新人还是干了十年的老兵——因为 Modbus 的坑从不因资历深浅而绕道。2. 整体设计思路为什么必须放弃“二分法”转向“全链路归因”2.1 拒绝“软件 or 硬件”的思维陷阱绝大多数初学者甚至不少有经验的工程师在面对“收不到数据”时第一反应是启动经典的二分法要么是代码写错了软件问题要么是设备烧了硬件问题。这种思路在纯数字电路或 PC 软件开发中非常高效但在工业现场它几乎必然导致数小时的无效排查。原因在于Modbus RTU 是一个典型的“跨层协议”它的可靠性高度依赖于物理层RS485、数据链路层Modbus 帧格式和应用层功能码、寄存器地址三者的严丝合缝。而物理层的“健康”又远不止“通电”和“有信号”这么简单。我见过太多案例代码逻辑完美无缺设备完好无损但因为现场电机启停产生的瞬态干扰耦合进了没有良好屏蔽的 RS485 线缆导致从站在接收帧时连续几个字节的奇偶校验失败于是直接丢弃整帧主站自然超时。这种问题既不能通过git diff发现也不能用万用表测出“开路”或“短路”。它是一种“亚健康”状态一种“间歇性失联”其根源在于电磁兼容EMC设计的缺失而非某个元器件的失效。因此本次调试的设计起点就是彻底抛弃“软件 or 硬件”的二分法代之以“全链路归因”的系统性思维。我们将整个通信路径拆解为五个不可跳过的检查域主站侧配置与工具链、USB-串口转换桥接、RS485 物理层、从站侧状态与配置、协议层参数一致性。这五个域不是并列关系而是存在严格的因果链条主站配置错误下游一切皆空谈USB-串口驱动异常物理层信号根本无法生成RS485 接线或终端匹配不当信号在传输途中就已畸变从站未上电或地址设置错误主站的请求石沉大海最后协议参数波特率、数据位、停止位、校验方式哪怕只有一项不匹配Modbus 帧也会在从站的 UART 接收缓冲区里被当作垃圾丢弃。这个思路的核心是把一个模糊的“收不到数据”问题转化为五个具体、可测量、可验证的子问题。每一个子问题的排查都有明确的输入你做什么操作、输出你期望看到什么现象和判定标准现象是否符合预期。这比在代码里加一百个printf或者反复重启设备要高效、可靠得多。2.2 工具链的选择为什么 Modbus Poll 和串口助手是黄金搭档在工业现场工具不是越多越好而是越“傻瓜”、越“透明”越好。复杂的上位机软件往往自带一层抽象会隐藏底层细节让你误判问题所在。因此我的首选组合永远是Modbus Poll主站模拟 串口助手原始数据窥探它们构成了一个完美的“协议层-物理层”双视角观测系统。Modbus Poll 的价值在于它是一个纯粹、标准、无任何业务逻辑的 Modbus 主站实现。它不关心你的数据要用来画曲线还是做报警它只忠实地按照 Modbus RTU 规范构造请求帧发送出去并等待、解析响应帧。当你在 Modbus Poll 里看到“Timeout”时它意味着主站发出了请求但没有收到任何符合 Modbus RTU 格式的响应当你看到“Invalid Response”时则意味着它收到了数据但这些数据无法通过 CRC16 校验或者帧结构如地址、功能码不符合规范。这是一个极其关键的区分点它直接将问题定位在了“有没有响应”和“响应对不对”这两个层面。而串口助手如 AccessPort、SSCOM、或者国产的“串口调试助手”的价值则在于它剥离了所有协议语义只做一件事原封不动地显示从串口COM 口上流过的每一个字节。它是你的眼睛直接看向物理层的“河流”。当 Modbus Poll 显示超时而串口助手里却能看到一串乱码比如FF 03 00 00 00 02 C4 0B这就立刻告诉你物理链路是通的信号是能传过去的问题极大概率出在从站的响应环节——可能是从站没运行、地址设错、或者寄存器地址不存在。反之如果串口助手里一片死寂Modbus Poll 也超时那问题就一定出在主站到从站的“路上”比如 USB 转串口驱动没装好、COM 口选错了、RS485 的 A/B 线接反了、或者终端电阻缺失导致信号反射严重。这个组合之所以是“黄金搭档”是因为它们提供了互补且不可替代的视角。Modbus Poll 告诉你“协议是否成立”串口助手告诉你“物理信号是否存在”。两者结合就能快速排除掉至少 70% 的常见误区。至于网上热传的“modbus poll 密钥”、“modbus slave 密钥”完全是本末倒置。一个合格的调试工程师永远不会依赖破解版软件来工作。Modbus Poll 的免费版功能已经完全足够用于现场诊断它的价值不在于“高级功能”而在于其“标准性”和“透明性”。把时间花在找密钥上不如花十分钟用万用表量一下 RS485 的 A/B 线电压。2.3 “最小化验证”原则从一根线开始逐步加码在现场调试中最危险的心态就是“一步到位”。你想着“反正最后都要接好不如现在就把所有线都接上所有参数都配齐然后一键运行。”结果失败了。你面对的是一个包含数十个变量的复杂系统根本无从下手。因此“最小化验证”Minimal Viable Verification是贯穿整个调试过程的铁律。它的核心思想是每次只引入一个变量确保它绝对可靠后再加入下一个。这就像搭积木每一块都必须稳稳地放在前一块之上。第一步永远是验证“主站到转换器”的 USB-串口链路。拔掉 RS485 线只留下 USB 线连接电脑和 CH340/FTDI 模块。打开串口助手选择正确的 COM 口注意务必在设备管理器里确认不要凭记忆设置一个简单的参数比如 9600, N, 8, 1然后发送任意字符如A。如果串口助手能立即回显A说明 USB-串口转换这一环是健康的。这是整个大厦的地基地基不牢后面全是空中楼阁。第二步在确认地基稳固后接入 RS485 转换器但此时先不接从站。将 RS485 的 A 和 B 线短接即 A-B 短路然后在串口助手中发送一个 Modbus RTU 请求帧例如读保持寄存器的请求01 03 00 00 00 02 C4 0B。由于 A-B 短路信号会原路返回你将在串口助手里看到自己发出的完整帧。这一步验证了 RS485 收发器的“自发自收”能力确认了它的方向控制逻辑DE/RE 引脚和驱动能力是正常的。第三步才接入真实的从站设备。此时你已经排除了主站、USB 转换器、RS485 收发器这三个环节的所有可能性问题必然聚焦在从站本身或其与 RS485 总线的连接上。你可以用万用表测量从站 RS485 接口的 A/B 线对地电压正常静态时应在 -7V 到 12V 之间且 A 线电压应略高于 B 线差分电压约 1.5V~5V。如果电压为 0 或接近 0那问题就出在从站的供电、RS485 收发器损坏或者总线被意外短路。这个“从一根线开始逐步加码”的过程看似繁琐实则是最快、最省力的路径。它避免了你在一团乱麻中反复试错把宝贵的时间全部用在了真正需要怀疑的地方。3. 核心细节解析与实操要点那些手册里不会写的“现场生存指南”3.1 主站侧Modbus Poll 的致命配置陷阱Modbus Poll 的界面简洁得近乎简陋但正是这种简洁埋下了无数个“一眼扫过就忽略”的致命陷阱。我把它称为“四座大山”每一座都足以让你的调试陷入僵局。第一座山模式Mode与传输Transmission的混淆。在 Modbus Poll 的Connection - Read/Write菜单下你会看到两个关键选项“Mode”和“Transmission”。新手极易将二者混为一谈。“Mode”指的是 Modbus 的协议类型必须严格选择RTU。而“Transmission”则指的是数据在物理线路上的表示方式它有两个选项RTU和ASCII。这里有一个巨大的认知误区很多人认为既然协议是 RTU那么 Transmission 也必须选 RTU。这是完全错误的。Transmission选项在这里其实是在告诉 Modbus Poll“请用哪种编码方式来显示我接收到的原始字节” 如果你选择了RTU它会尝试用十六进制显示如果选择了ASCII它会尝试用 ASCII 字符显示。但无论你选哪个Modbus Poll 发送和接收的永远是标准的 Modbus RTU 帧二进制字节流。所以正确的做法是将Mode固定为RTU而Transmission选项根据你的习惯选RTU推荐便于查看十六进制帧即可。如果你误将Mode设为ASCII那么 Modbus Poll 就会构造并发送 ASCII 格式的 Modbus 帧而你的从站假设是标准 RTU 设备根本无法识别结果必然是超时。第二座山串口参数Serial Port的“隐形”同步。Modbus Poll 的串口参数设置位于Connection - Serial Port。这里要求你手动输入波特率、数据位、停止位、校验位。但问题在于这些参数必须与你 USB-串口转换器CH340/FTDI的驱动设置、以及从站设备的 UART 设置三者完全一致。一个常见的“隐形”陷阱是CH340 的驱动在 Windows 下有时会默认启用“流控”Flow Control即 RTS/CTS 或 XON/XOFF。而 Modbus Poll 默认是关闭流控的。如果驱动开启了流控而 Modbus Poll 没有那么在数据量稍大时转换器可能会因为“没收到允许发送的信号”而暂停发送导致主站超时。解决方法在Serial Port设置窗口的底部找到Advanced按钮点击进入将Flow Control选项明确设置为None。同时在设备管理器里右键你的 CH340 设备 -Properties-Port Settings-Advanced同样将Flow Control设为None。确保三方在流控上达成“无协议”的共识。第三座山从站地址Unit ID的“零”与“一”之争。Modbus 协议规定从站地址范围是 1-247。然而在实际的 PLC 或仪表中地址的设置方式千差万别。有些设备的拨码开关0001 表示地址 1有些设备的 HMI 界面输入框里填0实际生效的却是地址 1。更麻烦的是某些国产设备的 Modbus 实现为了兼容旧系统会把地址0解释为广播地址或者干脆拒绝响应。因此当你第一次连接一个陌生的从站时不要想当然地认为地址是 1。务必查阅该设备的用户手册找到“Modbus Address”或“Slave ID”设置项。如果手册语焉不详最稳妥的办法是在 Modbus Poll 的Read/Write窗口中将Unit ID从 1 开始逐一尝试到 247。虽然耗时但这是唯一能覆盖所有可能性的方法。我曾在一个项目中为了一台进口电表从 1 试到 247最终发现它的地址被出厂设置为了 247而手册里只写了“默认地址为 1”这是一个彻头彻尾的误导。第四座山功能码Function Code与寄存器地址Address的“偏移”迷宫。Modbus 的功能码如 03 读保持寄存器06 写单个寄存器是明确的但寄存器地址的表示却充满了“偏移”陷阱。Modbus 协议本身定义的地址是 0-based从 0 开始。但绝大多数上位机软件包括 Modbus Poll和设备厂商的文档为了与人类习惯从 1 开始计数保持一致采用的是 1-based 地址。这意味着如果你的设备手册上写着“读取寄存器 40001”这个“40001”是一个功能码地址的混合标识4表示“保持寄存器”Holding Register0001表示第一个寄存器。在 Modbus Poll 中你需要在Read/Write窗口的Address栏里输入0因为协议是 0-based而不是1或40001。如果你输入了40001Modbus Poll 会把它当作一个巨大的十进制数然后转换成十六进制9C41再发送出去从站自然无法识别。记住这个万能公式Modbus Poll 中的Address (设备手册中的寄存器编号 - 1)。对于 40001就是 40001-140000但 40000 是十进制Modbus Poll 会自动处理你只需输入0即可。对于 40010就是 40010-140009输入9。这个“减一”的动作是每个 Modbus 工程师的肌肉记忆。提示在 Modbus Poll 的Read/Write窗口Address栏右侧有一个小按钮标着...。点击它会弹出一个寄存器地址计算器。你可以在这里直观地看到你输入的十进制地址会被转换成协议所需的十六进制地址以及对应的 Modbus 功能码。这是避免地址错误的终极保险。3.2 USB-串口转换CH340 驱动与 COM 口的“身份认同危机”USB-串口转换器是连接现代 PC 与古老工业设备的“翻译官”。而 CH340作为国产芯片的代表以其低廉的成本和广泛的兼容性占据了市场的大半壁江山。但它的“平易近人”恰恰掩盖了其最大的隐患驱动与 COM 口的“身份认同危机”。驱动安装不是“装上就行”而是“装对版本”。CH340 的驱动版本众多从最早的v2.1到最新的v3.5不同版本对 Windows 系统的支持度天差地别。我遇到过最离谱的情况是一台 Windows 10 21H2 的新电脑安装了官网下载的v3.5驱动设备管理器里 COM 口显示正常黄色感叹号都没有但 Modbus Poll 就是打不开端口报错Access is denied。折腾半天最后发现是v3.5驱动与该版本 Windows 的内核存在一个微妙的兼容性 Bug。解决方案降级到更稳定的v3.4驱动。因此我的建议是不要迷信“最新版”。对于 CH340v3.4是一个经过海量现场验证的“黄金稳定版”。下载时请务必认准官方渠道南京沁恒官网并仔细核对驱动包内的readme.txt里面通常会注明支持的 Windows 版本列表。安装完成后一定要重启电脑。很多驱动的“热加载”并不完全可靠只有冷启动才能确保所有内核模块被正确初始化。COM 口编号你的代码可能一直在“呼叫”一个不存在的号码。这是最隐蔽、也最致命的错误之一。Windows 系统为 USB 设备分配 COM 口编号的规则是按 USB 插入的物理顺序和历史记录。你昨天用 CH340 接在 USB 口 1系统给了它COM3今天你把它拔下来插到了 USB 口 2系统可能给它COM5。而你的上位机代码里可能还硬编码着Open(COM3)。结果就是程序启动串口打开失败你却还在代码里找Open函数的 bug。解决这个问题只有一个办法永远不要硬编码 COM 口。在上位机软件中提供一个下拉菜单让用户手动选择当前可用的 COM 口。在嵌入式开发中如 STM32 用 USB 虚拟串口做主站则需要在代码中枚举所有可用的串口设备并提供一个配置界面。此外在现场养成一个习惯每次接线前先打开设备管理器记下 CH340 当前的 COM 号然后在 Modbus Poll 或你的软件里精确地选择它。不要凭感觉不要靠记忆。硬件质量一根“假”CH340 线能毁掉你一整天。市面上充斥着大量廉价的、山寨的 CH340 模块。它们的 PCB 布线混乱电源滤波电容虚焊甚至芯片本身就是打磨过的假货。这些模块在实验室里可能表现正常但一旦放到工业现场面对电网波动和电磁干扰就会变得极其脆弱。典型症状是Modbus Poll 偶尔能收到一帧数据但大部分时间超时或者数据帧的 CRC 校验总是失败但用示波器看波形又似乎“差不多”。我的经验是对于关键项目务必采购带有完整金属屏蔽外壳、使用原装 CH340G 芯片、并且在板子上印有清晰厂家 LOGO 的模块。价格可能贵一倍但它能为你节省数倍的调试时间。一个简单的测试方法是将模块插入电脑用串口助手发送连续的0xFF字节流同时用万用表的交流电压档测量其 5V 输出引脚。如果电压纹波超过 100mV或者出现明显的周期性抖动那这块板子就不值得信任。3.3 RS485 物理层接线、终端、共模与“看不见的手”如果说 USB-串口转换是“翻译官”那么 RS485 就是“信使”而它的信使之路布满了看不见的陷阱。RS485 的原理很简单利用 A、B 两根线之间的电压差来传输数据。但正是这个“差分”概念让它的物理层设计变得异常精妙。接线图A 与 B 的“左右手”哲学。RS485 是一个半双工总线所有设备主站、从站都挂在同一对 A/B 线上。因此接线的首要原则是所有设备的 A 线必须连在一起所有设备的 B 线必须连在一起。这听起来很基础但现场最常见的错误就是“鸳鸯线”——主站的 A 接到了从站的 B主站的 B 接到了从站的 A。结果是主站发送的信号从站收到的是一对反相的信号自然无法解析。判断 A/B 是否接反有一个最简单、最可靠的方法用万用表的直流电压档测量 A 线对地GND和 B 线对地的电压。在没有任何通信发生时空闲态RS485 标准规定A 线电压应高于 B 线电压且差分电压应在 200mV 到 6V 之间。如果你测到 A 线是 -2VB 线是 2V那基本可以确定 A/B 接反了。此时只需将任意一端的 A/B 线对调即可。终端电阻不是“可有可无”而是“何时必须有”。RS485 总线的长度和速率共同决定了是否需要添加终端电阻。其物理本质是阻抗匹配目的是消除信号在总线末端的反射防止反射波与原始信号叠加造成接收端误判。一个粗略的经验法则是当总线长度米乘以通信波特率bps大于 10^7 时就必须加终端电阻。例如波特率为 9600 bps那么最大无终端电阻距离是 10^7 / 9600 ≈ 1041 米而如果波特率提高到 115200 bps这个距离就锐减到 10^7 / 115200 ≈ 86 米。在大多数工业现场几十米的布线配合 19200 或 38400 的波特率终端电阻几乎是标配。终端电阻的标准值是 120Ω必须只加在总线的物理两端最远的两个设备上中间的设备绝对不能加。加在中间会形成多个反射点效果适得其反。很多国产的 RS485 转换器模块会在板子上预留一个 120Ω 的焊盘或跳线帽这就是为终端电阻准备的。现场接线时务必确认这个跳线帽是处于“ON”接入状态。共模电压与接地工业现场的“地”不是同一个“地”。这是 RS485 调试中最玄学、也最致命的问题。RS485 的接收器其输入端有一个共模电压范围Common-Mode Voltage Range通常是 -7V 到 12V。这意味着A、B 线对“地”的电压只要在这个范围内接收器就能正常工作。但在工业现场“地”是一个非常模糊的概念。PLC 的 GND、变频器的 PE保护地、PC 的 USB 地、甚至车间的水泥地它们之间的电位差可能高达几伏甚至十几伏。当这个电位差超过了 RS485 接收器的共模范围接收器就会“罢工”表现为完全无响应或随机乱码。解决共模问题最有效、最经济的办法就是在总线的两端主站和最远的从站各加一个 120Ω 的终端电阻并且将其中一个终端电阻的一端通常是接 B 线的那一端通过一个 1kΩ 的电阻连接到本地的“大地”PE。这个 1kΩ 的电阻起到了限流和隔离的作用既能泄放共模电流又不会在 PE 线上形成大的环路电流。这是一个被无数现场验证过的“土办法”比购买昂贵的隔离型 RS485 转换器要来得更快、更直接。注意绝对禁止将 RS485 的 A/B 线直接接到 PE保护地上这会导致严重的短路风险可能烧毁设备。4. 实操过程与核心环节实现一次完整的“从绝望到希望”的现场复盘4.1 第一阶段主站与转换器的“握手”耗时15 分钟场景还原客户现场一台崭新的海康威视网络硬盘录像机NVR需要通过 Modbus RTU 读取一台第三方智能电表的电量数据。NVR 本身不带 RS485所以配了一个 USB 转 RS485 的 CH340 模块。我带着笔记本电脑、万用表、串口助手和 Modbus Poll 到达现场。第一步确认驱动。打开设备管理器发现 CH340 对应的 COM 口是COM4且没有黄色感叹号。但为了保险我还是右键 -Update driver-Browse my computer for drivers-Let me pick from a list手动选择了CH340 Serial Port (COM4)并强制重新安装了一遍v3.4驱动。重启电脑。第二步验证 USB-串口链路。拔掉 CH340 模块上的 RS485 线只保留 USB 线。打开串口助手选择COM4设置9600, N, 8, 1。点击“打开串口”成功。在发送区输入AT点击“发送”串口助手里没有任何回显。这很正常因为 CH340 本身不是一个 AT 指令设备。于是我切换到“HEX”发送模式输入01 03 00 00 00 01 84 0A这是一个读取地址 0 的保持寄存器的请求帧点击发送。串口助手里依然一片空白。这说明CH340 模块的 TX 引脚没有输出。问题来了。我拿出万用表黑表笔接 CH340 模块的 GND红表笔接其 TX 引脚通常是标着TXD或DO的焊盘。再次在串口助手里发送01 03 00 00 00 01 84 0A。万用表显示TX 引脚上出现了持续的、约 3.3V 的高电平但没有变化。这说明CH340 的 MCU 没有驱动 TX 引脚。问题出在 CH340 模块本身。我换了一个同型号的备用模块重复上述步骤这次万用表的读数随着发送而剧烈跳动串口助手里也看到了01 03 02 00 00 79 84一个模拟的响应帧。结论第一个模块是坏的。这个过程花了 10 分钟但它让我彻底排除了电脑、驱动、软件的所有可能性把问题精准地锁定在了硬件上。4.2 第二阶段RS485 总线的“脉搏”检测耗时25 分钟更换模块后我将 RS485 的 A/B 线接入 CH340 模块。此时电表还没有上电。我用万用表的直流电压档测量 CH340 模块 RS485 接口的 A 线对地电压读数为2.1VB 线对地电压为-2.1V。A-B 差分电压为4.2V符合标准。这说明CH340 的 RS485 收发器在空闲态下驱动能力是正常的。接下来我将电表的 RS485 A/B 线接入总线。电表已上电其面板显示正常。我再次测量电表 RS485 接口的 A/B 电压A 线1.8VB 线-1.8V差分3.6V。很好从站也在“呼吸”。然后我执行了最关键的“自发自收”测试将 CH340 模块的 A 线和 B 线在接线端子排上用一根短线短接。打开串口助手选择COM4设置9600, N, 8, 1HEX 发送模式。输入01 03 00 00 00 01 84 0A点击发送。串口助手里立刻回显了完全相同的01 03 00 00 00 01 84 0A。这证明从 CH340 的 UART到其内部的 RS485 收发器再到 A/B 线整个“发送路径”是畅通无阻的。最后我移除短路线恢复正常的 A-A、B-B 连接。再次发送同样的帧。这一次串口助手里什么也没有。这正是我期望的结果——因为电表没有响应。问题已经从“主站发不出去”变成了“主站发出去了但从站不回答”。战场正式转移到了从站一侧。4.3 第三阶段从站的“灵魂拷问”耗时40 分钟我查阅了电表的说明书找到了 Modbus 地址设置页。说明书上赫然写着“默认地址01”。我心中一喜立刻在 Modbus Poll 中设置Unit ID 1Function 03Address 0对应 40001Quantity 1。点击ReadModbus Poll 显示Timeout。我立刻警觉起来。地址 1 是最常见的默认值但也是最容易被“篡改”的值。我拿出电表的红外遥控器很多电表支持红外设置对着电表的红外窗口按说明书上的步骤进入了地址设置菜单。屏幕上显示的地址果然是01。地址没错。接着我检查了电表的波特率。说明书上写着“通讯波特率9600”。我回到 Modbus Poll确认串口参数是9600, N, 8, 1。也没问题。这时我决定祭出“终极武器”用另一个已知良好的 Modbus 主站设备一台手持式 Modbus 测试仪来交叉验证。我将测试仪接入同一根 RS485 总线设置相同的地址和参数。按下“Read”键测试仪的屏幕上立刻显示出了电表的实时电压值220.3V这证明电表本身、它的 RS485 接口、它的地址和波特率全部都是正确的。问题100% 出在了我的笔记本电脑和 CH340 模块这一侧。我立刻想到一个被忽略的细节共模电压。我的笔记本电脑是锂电池供电其 USB 地是“浮地”的而电表是市电供电其 RS485 地是接在 PE 上的。两者之间可能存在几伏的电位差。我拿出万用表黑表笔接电表的 PE 端子红表笔接 CH340 模块的 GND 引脚测得电压为3.2V。这个电压已经逼近
