工业现场总线不靠“猜”，靠pymodbus——一个老工程师的Modbus实战手记
上周在某汽车零部件厂调试一条新产线，PLC用的是汇川H3U，电表是威胜DTZ-341，温控器是欧姆龙E5CC。三台设备都支持Modbus，但一个走RS-485（RTU），一个走以太网（TCP），还有一个出厂固件只认ASCII模式……现场没有组态软件，客户只给了两小时窗口，让我“把数据捞出来，能看就行”。
没翻手册，没装驱动，没配虚拟串口——我掏出笔记本，pip install pymodbus，十分钟写完脚本，连上、读寄存器、转成JSON、推到本地Grafana，全程没重启一次PLC。
这不是炫技。这是pymodbus在真实工业现场给出的答案：它不教你怎么背功能码，而是帮你绕过90%的通信陷阱，把注意力拉回业务逻辑本身。
为什么Modbus还在被反复“踩坑”？先说清三个常被忽略的事实
很多工程师第一次用pymodbus，不是卡在代码，而是栽在对Modbus底层逻辑的“想当然”里。这里不讲协议标准文档，只说三条血泪经验：
Modbus没有“自动识别”这回事
client.read_holding_registers(0, 10)看似简单，但它背后隐含了至少5个必须对齐的参数：从站地址（slave）、起始地址（address）、寄存器数量（count）、字节序（endianness）、数据类型（uint16/int32/float32）。少对一个，读出来的就是乱码。比如西门子S7-1200默认用大端序，而某些国产PLC用小端+寄存器交叉排列——你得自己拆包验证。RTU和TCP不是“换端口就能通”
TCP模式下，slave=1只是报文里的一个字节；RTU模式下，slave=1却直接决定物理总线上哪个设备响应。更关键的是：RTU依赖严格的串口时序（T1.5/T3.5间隔），而Linux默认串口驱动会吃掉这些微秒级空闲时间。不用pymodbus的framer=ModbusRtuFramer显式接管帧边界，99%的“连得上但读不出”问题就出在这儿。异常不是Bug，是Modbus的“正常呼吸”
ModbusIOException不代表程序崩了，它可能只是PLC刚断电重启、或某次CRC校验失败、或寄存器地址超出了硬件范围（比如向只读输入寄存器写入）。把这些异常当错误处理，不如当状态信号来用——比如连续3次ConnectionException，就该触发本地缓存+告警，而不是让整个采集服务挂起。
明白了这些，pymodbus才真正从“能用”变成“敢用”。
pymodbus不是“库”，是你的Modbus协作者
别把它当成一个调用函数的工具包。pymodbus的设计哲学，是把你从“拼报文”的苦力中解放出来，让你专注定义“我要什么”，而把“怎么要”交给它。
它的四层结构不是教科书摆设，而是每一层都在替你挡子弹：
传输层（Transport）：你只管说“我要连
/dev/ttyUSB0”，它自动选serial.Serial；你说“连192.168.1.100:502”，它默默启socket.create_connection。连不上？它给你抛ConnectionException，而不是让你去查
