pymodbus：Python 的 Modbus 库，BSD 许可证商用没负担

先把话说在前面：如果你只是想连上一台 Modbus 设备，读几个寄存器看看值对不对，pymodbus 不是你要的东西。

它是一个库，不是软件。装完之后不会多出一个可以双击的程序，桌面上不会出现图标，也没有让你填串口号和从站地址的界面（具体的安装方式以官方仓库说明为准）。它给你的是一组可以在 Python 代码里调用的接口——具体的类名、方法名、参数以官方文档为准，本文不复述，因为这类 API 会随大版本调整，写死在文章里反而害人。

想手动点通一遍的，去看 QModMaster 或者 MThings，商业软件那一档是 Modbus Poll。这些工具打开就能连，十分钟能验证完一台设备。

那 pymodbus 的价值在哪？在于你可以把 Modbus 读写写进程序里，让它自己跑。

它真正省事的地方是脚本化

图形工具的天花板很明确：所有操作都要人点。这在验证单台设备时是优势，在下面这几种场景里就变成了瓶颈。

批量测试用例。 一台设备有几十上百个寄存器，你要逐个确认地址、数据类型、读写权限、量程是否符合手册。用图形工具就是几百次填地址、点读取、肉眼对值。用脚本，把手册上的寄存器表整理成一张数据结构，循环跑一遍，不一致的自动打出来。第一次写脚本的时间可能比手点还长，但第二次就是免费的。

回归测试。 设备固件改了一版，你要确认原来能用的功能没被改坏。这件事的本质是"同一批操作再跑一遍并比对结果"，天生适合脚本，不适合人手。硬件项目里固件迭代十几二十版是常事，回归脚本的收益是随版本数线性累加的。

造边界值和异常场景。 手册说某寄存器的合法范围是 0–1000，那写 1001 会怎样？设备应该返回异常码，但很多设备实际上是照单全收然后行为怪异。再比如超长的读取数量、非法的功能码、故意错位的地址。这类"故意写错"的测试用图形工具很难系统地覆盖，用脚本可以把用例列成表格一次跑完。

无人值守采集。 现场设备每分钟采一次，连采一周，中间断线要能自动重连，数据要落盘。这是典型的服务型任务，只能用代码写。

接进已有的 Python 数据栈。 这一条常常被低估。如果你的数据分析、报表、可视化、告警本来就在 Python 里，那 Modbus 数据用 Python 取回来是最短路径——不用中间文件，不用格式转换，取到就能直接进后续处理。反过来，如果为了取一段数据先用图形工具导出 CSV、再手工搬进分析脚本，中间那一步既费时又容易出错。

Modbus 本身的几个坑，脚本一样躲不掉

换成写代码不代表协议层的坑就没有了，只是暴露方式变了。

RTU 和 TCP 的帧不一样。 RTU 帧末尾带 CRC 校验，TCP 帧前面是 MBAP 头、不带 CRC（TCP 自己保证完整性）。这意味着同一条业务逻辑在两种链路下的底层帧结构是不同的。想手工验算 CRC，用站内的 CRC / Modbus 校验计算器。

寄存器编号和报文地址常常差 1。 手册上写 40001，报文里要填 0。这个偏移在图形工具里靠人试，在脚本里靠人一次性写对——写错了就是整批数据集体偏移一格，而且看起来"每个值都有"，很有迷惑性。

32 位量有四种字序。 一个 32 位浮点数拆成两个寄存器存，高低字和高低字节的排列有四种组合，各家厂商都有在用。数值稳定但离谱，先怀疑字序，不要怀疑通信。

超时和重试是轮询逻辑里最容易写错的一段。 一台从站不回，是等 200 毫秒还是 2 秒？超时之后重试几次？重试期间要不要继续轮询后面的设备？这几个参数决定了整条采集链路在设备掉线时是"跳过一台继续跑"还是"整体卡死"。图形工具替你做了默认选择，写代码时这个选择变成你的。别用默认值直接上生产，先想清楚一台设备失联时你希望发生什么。

物理层的事情不会因为换了语言而消失，多机总线的收发方向控制和终端电阻见 RS-485 差分总线，帧在线上的样子见 UART 串口原理。

BSD-3-Clause 到底要求你做什么

这是本页最值得看的一段，因为它直接关系到你能不能把这个库放进要卖的产品里。

pymodbus 的许可证是 BSD-3-Clause，也就是三条款 BSD。实读 LICENSE 原文，三条款分别是：

1. 以源码形式再分发时，必须保留原有的版权声明、这份条款列表和免责声明；
2. 以二进制形式再分发时，必须在随附文档或其他材料中复现上述声明；
3. 未经事先书面许可，不得用原作者或贡献者的名义为衍生产品做背书或宣传。

三条都是"你要做什么"，没有一条是"你必须开放什么"。这就是宽松许可证和 copyleft 的分界线：BSD-3-Clause 允许闭源商用，允许静态链接，没有传染性——你把它用进自己的产品里，产品代码不因此需要开源，只需要在文档里带上那份声明、并且别拿原作者的名义做营销。

对照一下站内的 libmodbus，它是 LGPL-2.1，属于弱 copyleft。LGPL 的常见理解是：以动态链接方式调用，你自己的程序可以保持闭源；但一旦你修改了库本身，改动后的库仍然要以 LGPL 开放。BSD-3 没有这个要求，你改了它，改动可以不公开。

这个差别在实际项目里的体感是：用 BSD-3 的库，合规工作基本就是"把声明放进文档"；用 LGPL 的库，你得先搞清楚自己是不是动了库、以什么方式链接的，再决定要开放到什么程度。

本文不构成法律意见。 许可证条款的最终解释以 LICENSE 原文为准，涉及正式发行的商业产品时，请让你们的法务过一遍。

顺手说个真实的坑：GitHub 标的许可证不一定准

做合规审查的人很多是这么干的：打开仓库，看右侧边栏那一行许可证标签，抄下来，完事。

pymodbus 这个仓库正好能说明这么干为什么危险——GitHub 的 API 对它返回的是 NOASSERTION，也就是"未能识别"。是打开 LICENSE 文件逐条读原文，才确认它是标准的三条款 BSD。

GitHub 的许可证识别是自动匹配的：文件名不标准、正文加了额外段落、把两份许可证拼在一个文件里、或者措辞和标准模板有出入，都可能让它识别失败或者识别错。识别失败还算好的，至少会显示成"未识别"提醒你去看；更麻烦的是识别成了一个相近但条款不同的许可证，那你抄下来的结论是错的，而且看起来言之凿凿。

所以给做软件物料清单（SBOM）或者合规审查的人一条实用建议：侧边栏那一行只能当索引，不能当结论。真要落笔，打开 LICENSE 文件读原文。 有额外的 NOTICE、COPYING、或者第三方目录下的独立许可证文件，也一并看了。这件事花不了五分钟，但是把它跳过去的成本可能很高。

和 libmodbus 怎么选

这两个不是好坏之分，是场景之分。同一个人在不同项目里选不同的，很正常。

选 libmodbus 这类 C 库，如果： 你要把 Modbus 编进设备固件；目标环境上根本没有 Python 运行时；对内存占用和响应延迟有硬指标；或者你的整个工程本来就是 C/C++，引入一个语言运行时不划算。

选 pymodbus，如果： 你要写的是测试脚本、采集服务、上位机工具；开发效率的优先级高于运行效率；下游要接数据分析或者可视化；或者做这件事的人本来就是写 Python 的。

一个常见的组合是两边都用：设备端固件用 C 库实现从站，测试台和产线工装用 Python 脚本做主站去打它。这时候需要注意的是，测试脚本和被测固件不要互相当作"正确性的标准"——两边都是你写的，一起错了也发现不了。中间插一个第三方图形工具做交叉验证，比如用 MThings 或 Modbus Poll 独立读一遍同样的寄存器，是很便宜的保险。

上手前建议先做的两件事

第一，先用图形工具把链路点通。 串口号、波特率、从站地址、寄存器偏移这几项，用工具试出正确组合只要几分钟；在代码里试要慢得多，因为你还要分辨"是参数错了"还是"代码写错了"。链路通了再写脚本，等于把变量减半。串口层面本身有问题的话，先用 串口调试助手 或站内的串口调试工具确认口能开、能收发。

第二，把版本记下来。 当前最新版是 v3.15.0，发布于 2026-08-13。库的接口会随大版本演进，你在网上搜到的示例代码可能是好几个大版本之前的，直接抄容易对不上。写脚本时把依赖版本固定住，升级时对着官方的变更说明走——具体接口和迁移方式一律以官方文档为准。

其余的 Modbus 工具与嵌入式软件，见软件与工具库；在线小工具集中在工具箱。