PySerial本身不提供工业协议解析能力，直接用serial.write()发原始字节只能对接裸串口设备；多数工业设备需遵循Modbus RTU等特定协议，必须手动组包、CRC校验、超时重试，否则90%情况下设备无响应或返回乱码。
PySerial 本身不提供工业协议解析能力，直接用 serial.write() 发原始字节只能对接裸串口设备；多数工业设备（如PLC、传感器、电表）需要遵循特定协议（Modbus RTU、ASCII、自定义帧格式），必须手动组包、校验、超时重试——跳过协议层直接发数据，90% 情况下设备无响应或返回乱码。
确认设备通信协议和物理层参数
工业设备手册里写的 “RS485” 不等于“能通”，必须逐项核对：
-
baudrate：常见有 9600、19200、115200，但某些老式 PLC 只支持 4800，设错会导致serial.read()返回空或乱码 -
bytesize、parity、stopbits：Modbus RTU 通常为8-N-1（即bytesize=8,parity='N',stopbits=1），而某些仪表用7-E-2，配错会丢字节 - 地址/站号（slave ID）：Modbus 设备必须带有效地址，发包时第一个字节就是它；没填或填错，设备静默忽略
- 接线方式：RS485 半双工需注意 DE/RE 使能控制，USB转RS485模块若无自动流控，可能需额外 GPIO 控制方向
用 PySerial 发送 Modbus RTU 请求并解析响应
不要依赖第三方 Modbus 库（如 pymodbus）——它们抽象层太厚，出问题时难以定位是协议错还是串口错。先用原生 PySerial 手动构造请求：
例如读保持寄存器（功能码 0x03），起始地址 0x0000，读 2 个寄存器：
立即学习“Python免费学习笔记（深入）”；
import serial
ser = serial.Serial('/dev/ttyUSB0', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=1)
# 构造 Modbus RTU 请求：[slave_id][func][addr_hi][addr_lo][reg_hi][reg_lo][crc_lo][crc_hi]
req = bytes([1, 0x03, 0x00, 0x00, 0x00, 0x02]) # slave=1, func=3, addr=0, count=2
req += calc_crc16(req) # 自实现 CRC-16-MODBUS 校验
ser.write(req)
resp = ser.read(12) # 正常响应：[1][3][4][data][crc]
if len(resp) >= 5 and resp[0] == 1 and resp[1] == 0x03:
data = resp[3:5]
关键点：
-
timeout必须设（建议 0.5–2 秒），工业设备响应慢，阻塞等待易卡死 - CRC 计算必须严格按 Modbus RTU 规范，网上很多 Python CRC 示例用错多项式（应为 0xA001，非 0x8005）
- 响应长度不固定，不能只读固定字节数；需先读头 2 字节判断功能码，再按规则算后续长度
处理常见串口异常与硬件抖动
工业现场电磁干扰强，serial.read() 经常返回不完整数据或 SerialException：
- 每次
write()后加ser.flush()，避免内核缓冲区残留旧数据 - 捕获
serial.SerialTimeoutException和OSError（Linux 下 USB 断连常抛此异常），而非只 catchException - 对同一设备连续操作时，在两次请求间加
time.sleep(0.02)（Modbus RTU 要求帧间隔 ≥3.5 字符时间） - 避免在循环中反复
open/close串口——热插拔 USB 转接器易导致/dev/ttyUSB*编号变动，应复用连接对象
真正难的不是发几个字节，而是把协议细节（比如某个温度变送器要求命令后必须等 120ms 再读、某 PLC 的写指令需两次握手）和现场电气噪声一起驯服；协议文档写得模糊时，用逻辑分析仪抓真实波形比查 PySerial 文档有用得多。
