1. 为什么用 Python 通过 ModbusTCP 连接 PLC在工业自动化项目里总有那么一天你需要把现场设备的实时数据交出去给 MES、给工控看板系统、或者给一套自己写的质量分析工具。PLC 品牌五花八门通信协议也各有各的私有协议但好消息是绝大多数中高端 PLC 都支持 ModbusTCP 这个“通用语言”。Python 做上位机开发的优势在于生态成熟、快速验证、库也够用。我自己在好几个项目里都用同一套 Python 脚本对接过不同品牌的 PLC只要设备支持 ModbusTCP基本都能按同一套思路把数据读上来。这套方案适合哪些人你在做包装设备的数据采集乙方要把产线数据接到数字孪生系统或者你想在实验室里快速验证一台新 PLC 能不能通这些场景都适用。跟 OPC UA 方案比起来ModbusTCP 最大的好处是轻——不需要额外装 OPC 服务器不需要处理复杂的地址映射配置只需要知道 PLC 的 IP、端口和寄存器地址表Python 就能直接上手。我最早接触 ModbusTCP 是想把一台老款 PLC 的数据统一采集到中控系统当时 OPC 服务器授权费用不便宜而且配置过程非常繁琐。后来认真摸了一遍 ModbusTCP发现只要理清功能码、寄存器地址、字节序这几个核心概念整套链路串联起来并不复杂代码量也就几十行。这也是我写这篇文章的原因把我的真实使用经验整理出来帮你绕过那些坑。提示不同品牌的 PLC 对 Modbus 地址的映射方式差别很大后面我会专门用表格做对比。如果你只想知道最快能跑通的代码直接跳到第 3 小节。2. 整体方案设计与选型思路2.1 不同品牌 PLC 的 ModbusTCP 支持情况分析工业现场常见的 PLC 品牌在 ModbusTCP 支持上差别明显。我做过的几个典型项目可以参考品牌是否需要额外配置常用协议端口地址映射特点实际使用感受西门子 S7 系列带网口需在 PLC 侧做少量配置502与 DB 地址的映射关系需确认大多数情况通过工具映射后即可用三菱 FX5U / Q 系列部分型号需开启协议支持502地址直接对应 D、M、X、Y 软元件交互方式简单但需要熟悉厂家映射罗克韦尔 CompactLogix需特定配置和支持模块502地址映射方式较特别在公司环境实测兼容性良好需细查文档台达、汇川、信捷等国产品牌一般默认支持502基本按标准 Modbus 地址对应实测最容易跑通尤其是 FX 系、汇川 H5U基恩士、松下等日系品牌基本都支持502内部继电器地址需查手册地址表清晰结合说明书很容易对应这里需要注意端口默认都走 502但有些设备允许自定义端口如果遇到默认端口连不上先确认 PLC 的 ModbusTCP 服务是不是真的启用了再排查防火墙。2.2 为什么首选 ModbusTCP 而不是 OPC UA 或私有协议我在多个采集项目中对比过几种方案私有协议如串口指令、OPC UA、ModbusTCP。最终选择 ModbusTCP 的原因很实际开发成本很低私有协议要按厂家协议文档逐字节解析调试周期长ModbusTCP 的帧格式公开且简单用现成库就能解析。跨平台性好只要 PLC 有网口无论品牌型号都可以用同一套 TCP 链路去读取数据。实时性足够对于大多数制造执行系统、产线数据采集场景扫描周期在 100ms~1s 级别就够ModbusTCP 完全扛得住。调试手段丰富Modbus Poll、Simply Modbus、Python 脚本都能模拟主站排查链路问题很方便。不可否认如果你的现场要求高实时毫秒级同步或者需要在多台 PLC 之间做复杂联动OPC UA 可能是更稳健的选择。但就“用 Python 读取数据、写入控制指令”这个需求来看ModbusTCP 的性价比最高。2.3 Python 生态中几个主流 ModbusTCP 库的选型对比Python 里处理 ModbusTCP 的库常见的有这几个库名维护活跃度易用性性能和稳定性适用场景pymodbus活跃、持续更新高稳定社区用户多大多数情况的首选minimalmodbus活跃很高主要面向串口TCP 支持有限如果你只用串口或者想极简实现Modbus-Tk维护较少一般稳定性尚可老项目维护或学习参考自写 Socket 解析-低完全可控特殊需求比如自定义帧结构以我日常项目为例优先选择 pymodbus因为它在异步和同步模式下都能干活对工程师和开发者都够友好遇到问题也能轻易找到参考。这个库的 API 在不同版本间有些调整我记得 3.x 版本后类名和调用方式都有变化所以示例代码最好以实际安装的版本为准。3. ModbusTCP 核心概念拆解与协议解析3.1 功能码不只是数字读懂 1、2、3、4、5、6 的含义ModbusTCP 通信的本质是“主站问从站答”。主站Python 脚本发出一个请求帧PLC从站处理后返回数据。核心要素就是“要去哪里读”地址、“读多少”数量、“读什么类型的数据”功能码。常见的功能码010x01读线圈状态。对应 PLC 的 DO数字量输出例如继电器输出、阀门状态。020x02读离散输入。对应 PLC 的 DI数字量输入例如接近开关、按钮信号。030x03读保持寄存器。这是最常用的PLC 的模拟量输出、数据寄存器如三菱 D 区、西门子 DB 区都靠它读。040x04读输入寄存器。对应 PLC 的模拟量输入通道例如温度变送器、压力传感器的数值。050x05写单个线圈。例如远程控制某一路 DO 通断。060x06写单个寄存器。例如给设定值寄存器写入目标温度。150x0F写多个线圈。批量控制多路输出时用。160x10写多个寄存器。批量写入设备参数时用。我在实际项目中 90% 的情况只用到 03、04、06、16 这四个功能码。读实时数据是 03/04写设定值是 06/16。搞清楚这些你在看 PLC 手册的地址表时会省很多力气。3.2 数据类型与字节序最常见的坑Modbus 协议设计得很“原始”它只传输 16 位寄存器并不感知你业务数据的类型。所以同一个寄存器你可以把它当作整数、浮点数、甚至拆成两个字节来用。这就是很多人移植程序时数据对不上的原因。在 PLC 侧一个 32 位浮点数如温度、压力会占用两个连续寄存器。排列方式有两种Big-Endian高字节在前。也就是第一个寄存器存数据的高 16 位。Little-Endian低字节在前。第一个寄存器存数据的低 16 位。更让人头疼的是寄存器内部的字节顺序也有不同排列。有的 PLC 用“字顺序 字节顺序”双重倒置三菱和西门子的排列方式就不完全一样。用 Python 处理时必须手动指定或调整。举个真实例子我在读取一台温控器的 PV 值当前温度时按文档说明数据格式为 Float。直接读两个寄存器拼出来数值却完全不合理后来发现设备用的是“低字在前 字节交换”调整后数值立刻正常了。我的经验做法是先在 PLC 里写入一个已知的浮点数比如 25.5然后在 Python 里分别打印出寄存器原始值再把不同组合方式都试一遍就能确定正确的字节序。这个过程我在第 4 小节详细讲。3.3 从 TCP 地址到 PLC 软元件的映射逻辑这是跨品牌项目中最容易卡住的地方。每个 PLC 品牌都有自己的数据区命名比如西门子的 DB1.DBD0、三菱的 D100、罗克韦尔的 Tag你需要在 PLC 厂商的 Modbus 映射表中找到对应的 Modbus 地址。以三菱 FX5U 为例D100 在 Modbus 保持寄存器里的地址通常是 400101或协议地址 100M100 对应线圈地址 00100 这样的逻辑。看上去规律不大容易让人犯迷糊其实核心规律是大多数厂家给的地址都是“协议地址”而协议地址和 Modbus 报文里的地址差了 1因为协议地址从 0 开始编号但手册往往从 1 开始显示。所以我建议在写代码之前先在 PLC 侧查清楚两件事——数据类型占几个寄存器、对应 Modbus 地址是多少。这两个信息比代码本身更影响你能不能一次就把数据读对。4. 环境准备与手把手实操示例4.1 安装 Python 环境与核心依赖库建议使用 Python 3.8 及以上版本因为 pymodbus 的新特性依赖较新的语法。安装依赖命令pip install pymodbus如果你需要调试帧格式可以顺手装一个pymodbus[serial]或者用 Wireshark 做抓包验证。我调试时经常抓包看原始 TCP 报文很管用。安装完成后在 Python 里验证一下版本import pymodbus print(pymodbus.__version__)不同版本的调用方式细节差异很大如果你看到网上老教程里写from pymodbus.client.sync import ModbusTcpClient而你报错找不到模块大概率是版本差异。新版用pymodbus.client更加简洁。4.2 第一个可运行的读数据脚本读线圈 读寄存器以下脚本覆盖了 DI、DO、AI、AO 四类信号的读取也是我在项目中反复使用的基础模板from pymodbus.client import ModbusTcpClient PLC_IP 192.168.1.10 PLC_PORT 502 client ModbusTcpClient(PLC_IP, portPLC_PORT, timeout5) if not client.connect(): print(连接失败请检查 IP、端口和网络) raise SystemExit(1) # 读线圈DO从地址0开始读10个 rr client.read_coils(0, 10, slave1) print(线圈状态, rr.bits[:10]) # 读离散输入DI从地址0开始读8个 dr client.read_discrete_inputs(0, 8, slave1) print(离散输入, dr.bits[:8]) # 读保持寄存器AO/数据寄存器从地址0开始读10个 hr client.read_holding_registers(0, 10, slave1) print(保持寄存器原始值, hr.registers) # 读输入寄存器AI/模拟量输入从地址0开始读6个 ir client.read_input_registers(0, 6, slave1) print(输入寄存器原始值, ir.registers) client.close()这段代码里slave1是设备地址常规默认填 1。如果一台 PLC 挂多个从站或者网关下挂多台设备这个值就要按协议对应。timeout5表示超过 5 秒没响应就报超时实际使用时按现场网络状况调整。4.3 写数据实操写单个线圈、写单个寄存器、写多个寄存器远程控制是很多项目的刚需比如远程启停电机、远程调整温度设定值。下面这段是我常用的写入函数封装def write_coil(client, address, value): 写单个线圈value: True 或 False result client.write_coil(address, value, slave1) return not result.isError() def write_register(client, address, value): 写单个寄存器value: 整数比如 500 表示 50.0 result client.write_register(address, value, slave1) return not result.isError() def write_registers(client, address, values): 写多个寄存器values: 列表例如 [100, 200, 300] result client.write_registers(address, values, slave1) return not result.isError()返回值是不是isError()这个判断很重要很多新手容易忽略。有些异常不会抛出来而是藏在返回值里比如地址越界、功能码错误、写入超时如果不检查返回值你根本不知道这次写入失败。4.4 浮点数、32位整数和字符串的读取与解析读 PLC 里的浮点数如果把寄存器原始值直接打印你看到的是两个整数比如 16480 和 0。这就需要把两个寄存器拼成 32 位数据再进行浮点解释。以下是我封装的一个可靠解析函数import struct def read_float(client, start_address, slave1, byte_order, word_orderbig): byte_order: 大端模式 小端模式 word_order: big 高字在前little 低字在前 rr client.read_holding_registers(start_address, 2, slaveslave) if rr.isError(): return None raw rr.registers # 大端 / 小端模式在前面加字节序符号 if word_order little: raw raw[::-1] data struct.pack(byte_order HH, raw[0] 0xFFFF, raw[1] 0xFFFF) return struct.unpack(byte_order f, data)[0]给新手解释一下这里的手法struct.pack把两个 16 位整数按指定字节序打包成 4 个字节struct.unpack再把 4 个字节按单精度浮点数解析。如果按大端高字在前解析出来明显不合理就改成低字在前或者小端再试一次。快速迭代几次就能确定正确组合。32 位整数读取类似只是struct.unpack的格式从f改成i或I。但要注意有的 PLC 32 位整数的排列和浮点数不同所以同一台设备上浮点和长整数有时要用不同的字节序组合这也是我建议先以已知数值试通信的原因。如果你要读字符串通常是把多个寄存器当字符数组每个寄存器拆成高低字节来拼接。简单场景下每个寄存器取低 8 位字符即可def read_string(client, start_address, length, slave1): rr client.read_holding_registers(start_address, length, slaveslave) if rr.isError(): return None result for reg in rr.registers: result chr(reg 0xFF) result chr((reg 8) 0xFF) return result.rstrip(\x00)这种读取方式需要和 PLC 侧的存储格式严格对齐。有些 PLC 一个寄存器存两个 ASCII 字符一个存高字节一个存低字节顺序还不一定一致仍然需要通过已知值试出来。4.5 自动重连与超时处理长时间稳定运行的关键产线数据采集程序经常要 7x24 小时跑网络抖动、PLC 断电重启都会导致 TCP 连接断开。如果不做重连机制程序要么死等要么直接崩溃。我的做法是包装一个“带重连的读取类”import time from pymodbus.client import ModbusTcpClient class PlcClient: def __init__(self, ip, port502, timeout5, retry_limit5): self.ip ip self.port port self.timeout timeout self.retry_limit retry_limit self.client None def connect(self): if self.client: self.client.close() self.client ModbusTcpClient(self.ip, portself.port, timeoutself.timeout) return self.client.connect() def read_holding(self, addr, count, slave1): for attempt in range(self.retry_limit): try: if not self.client or not self.client.is_socket_open(): self.connect() rr self.client.read_holding_registers(addr, count, slaveslave) if rr.isError(): raise RuntimeError(f读保持寄存器错误: {rr}) return rr.registers except Exception as e: print(f第{attempt 1}次尝试失败: {e}) time.sleep(1) raise RuntimeError(连续多次读取失败请检查PLC状态) plc PlcClient(192.168.1.10) data plc.read_holding(100, 5) print(data)这个模式的核心是每次读取前判断连接是否还活着is_socket_open()一旦断了就自动重建失败后延退重试避免脚本密集重试给 PLC 造成压力。实测下来这个模式稳定跑过很多天。4.6 快速定位 Modbus 地址与字节序的调参技巧调试 Modbus 通信时我最常用的工具是我自己写的一段“扫描脚本”。它的逻辑很简单在已知的地址范围内依次读寄存器然后打印出所有非零值。for addr in range(0, 20): rr client.read_holding_registers(addr, 1, slave1) if rr.isError(): print(faddr {addr}: error) else: print(faddr {addr}: {rr.registers})通过这种方式你能快速摸清 PLC 地址表里哪些地址有数据。比如你在 PLC 侧给 D200 写了一个已知值 12345扫描时看到地址 200 返回 12345那么你就能确定 D200 对应 Modbus 地址 200。这里有一个细节有些 PLC 的协议地址是 0 开始而触摸屏或组态里显示的是 400201 这种对应关系也要顺手确认。5. 常用连接模式与进阶技巧5.1 单台 PLC 连接与多台 PLC 并发采集的差别如果只监控一两台 PLC上面的单连接模式完全够。但厂房里有十几条产线每台 PLC 都要采集逐个连接的话代码重复度高而且逻辑混乱。我建议维护一个设备清单用循环或并发方式来采集。简单版的多设备顺序采集plc_list [ {name: 产线1, ip: 192.168.1.11, port: 502}, {name: 产线2, ip: 192.168.1.12, port: 502}, {name: 产线3, ip: 192.168.1.13, port: 502}, ] for plc_info in plc_list: client ModbusTcpClient(plc_info[ip], portplc_info[port], timeout3) if client.connect(): rr client.read_holding_registers(100, 10, slave1) print(plc_info[name], rr.registers) client.close()这个方案实现简单但问题是串行采集如果其中一台 PLC 响应慢整个链路就被拖住。想要提高效率就用多线程或异步让每台 PLC 独立采集。5.2 用 threading 实现多台 PLC 并行读取我在一个项目里用 threading 采集八台 PLC 数据整体刷新速率比串行快了不止一倍import threading import time from pymodbus.client import ModbusTcpClient result_dict {} def collect_plc(name, ip, port, addr, count): client ModbusTcpClient(ip, portport, timeout5) if client.connect(): rr client.read_holding_registers(addr, count, slave1) if not rr.isError(): result_dict[name] rr.registers client.close() plc_list [ {name: p1, ip: 192.168.1.11, port: 502, addr: 100, count: 10}, {name: p2, ip: 192.168.1.12, port: 502, addr: 100, count: 10}, {name: p3, ip: 192.168.1.13, port: 502, addr: 100, count: 10}, ] threads [] for x in plc_list: t threading.Thread(targetcollect_plc, args(x[name], x[ip], x[port], x[addr], x[count])) t.start() threads.append(t) for t in threads: t.join() print(result_dict)这种方式有几点注意每个线程里创建一个独立连接不要跨线程共享同一个客户端因为 ModbusTCP 不是线程安全的PLC 侧要能承受多台主机同时建立连接一般中大型 PLC 都支持多个 ModbusTCP 连接但小型网关可能只允许 1~2 个连接需要查规格。5.3 asyncio 异步方案与线程方案的选择Python 的asyncio方案也常用于 PLC 采集。pymodbus 3.x 提供了异步客户端写法如下import asyncio from pymodbus.client import AsyncModbusTcpClient async def read_all(): clients [ AsyncModbusTcpClient(192.168.1.11, port502), AsyncModbusTcpClient(192.168.1.12, port502), ] for c in clients: await c.connect() results [] for c in clients: rr await c.read_holding_registers(100, 10, slave1) results.append(rr.registers) for c in clients: c.close() asyncio.run(read_all())异步方案适合 I/O 密集的高并发采集场景资源占用小但代码复杂度和理解成本高一些。如果只是简单几个设备轮询用 threading 就够了。我个人做十台以内设备时更倾向 threading超过二十台才考虑 asyncio 或直接上采集网关。5.4 ModbusTCP 与串口 ModbusRTU 网关的混合使用很多老旧设备只有 RS485 串口没有网口。这时要用 ModbusRTU 转 ModbusTCP 的网关设备。网关作为一个 TCP 服务器把串口侧的 ModbusRTU 帧转换成 TCP 帧对你的 Python 脚本来说与直接连 PLC 没有区别。使用这类网关要注意几个点网关的串口参数波特率、数据位、校验位必须和 PLC 串口设置一致。网关的单元 ID从站地址要和 PLC 的 Modbus 地址一致。确认网关最多支持多少个 TCP 客户端同时连接有些便宜网关只允许 1 个主站占用连接冲突会直接通信失败。我在一个改造项目里现场七台老旧仪表都是 RS485 接口通过一个八口网关集中转成 TCPPython 脚本用同一个 IP 不同从站地址slave1~7就能读全所有仪表。这个方案部署成本低效果也很稳。6. 常见问题排查与避坑经验6.1 连接不上 PLC 的排查清单这是我每次远程支持别人排查问题时会按顺序检查的列表检查项处理方法IP 地址是否能 ping 通先确认物理链路和本机 IP 网段PLC 的 ModbusTCP 服务是否启用很多 PLC 出厂默认关闭需要在软件中开启PLC 端口号默认 502有些自定义防火墙加白名单或临时关闭验证是否是防火墙拦截单元 IDslave不填或填错都会报错误码默认从 1 开始尝试串口网关参数波特率、数据位、停止位、校验位设置是否一致连接不通时我的习惯做法是先用支持 Modbus 调试的调试助手连一下如果能通那就是 Python 脚本的问题如果调试工具也不通就要回到 PLC 侧查配置了。6.2 报错 IllegalAddress 与 IllegalFunction 的常见原因这两个错误码在 Modbus 协议里有明确含义IllegalAddress错误码 02地址越界或者该地址在当前从站上不存在。IllegalFunction错误码 01该从站不支持这个功能码。比如你用 03 去读一个只支持 04 的设备就会报这个错。处理办法很直接确认功能码和数据类型匹配确认寄存器地址在 PLC 的 Modbus 地址映射范围内确认数量参数没有超出最大长度限制Modbus 协议规定单次读写寄存器数量有限制一般不能超过 125 个寄存器或 2000 个线圈。6.3 字节序错误导致读出的浮点数异常离谱你读出来的数值如果是 8848.22、-0.00001 这种明显不合理的数字那大概率不是通信失败而是解析字节序不对。提起这个我很有体会很多事情就差在一两个字节的排布上。我建议在 PLC 侧给某两个连续寄存器写入一个已知的浮点数比如 12.5然后 Python 端打印出两个原始寄存器值。只要把大小端组合全部枚举一遍通常很快可以找到正确组合。6.4 运行一段时间后通信中断的常见原因长跑项目里通信中断通常不是 Python 代码问题而是设备侧或网络侧的不稳定。常见原因PLC 程序主动结束了 ModbusTCP 连接有的 PLC 在扫描周期过长时会超时断开空闲连接。网络交换机端口老化、物理链路闪断。PLC 或网关的连接数被占满新的连接无法建立。防火墙或安全管理软件定期做端口策略刷新。我的经验是客户端侧做好自动重连只是基础更稳妥的做法是记录通信日志当链路异常时能看到是 TCP 层断开还是超时无响应这两类问题的排查方向完全不同。6.5 多线程环境下共享同一个连接的注意事项如果你用 threading一定要保证每个线程有自己的客户端实例。共享同一个连接在高并发读写时会出现响应交叉导致读到的数据是“别人的”回复排查起来非常痛苦。我见过一个项目开发人员图省事在多个线程里用同一个 pymodbus 客户端结果偶尔读到的数据莫名其妙跳变。后来改成每个线程独立连接问题彻底消失。这就是一个典型的“读懂现象却不理解协议本质”的坑ModbusTCP 的请求和响应没有唯一标识靠 TCP 顺序对应一旦交错就乱套。6.6 PLC 程序扫描周期导致的通信超时有些 PLC 的 Modbus 服务在程序执行任务很重时无法及时响应主站请求。你读少量数据没问题但大批量读取时请求排队、超时甚至报文被丢弃。解决思路很直接减少单次读取的数据量、降低轮询频率、分散读取点。另外不少 PLC 默认的 Modbus 响应时间很短比如 100ms。如果你的 Python 代码同时发了很多请求堆在一起很容易触发超时。给每次请求之间加一点小延时或者用批量读取代替逐点读取都能显著降低问题发生概率。7. 实际项目案例复盘7.1 场景一产线设备数据采集到 MES24 小时运行这个项目里现场有六台包装设备每台配了一台国产 PLC支持 ModbusTCP。需求是把每台设备的运行状态、计件数、故障代码实时采集到 MES 数据库同时支持 MES 下发配方参数。实施要点每台 PLC 单独线程连接避免相互影响。读取频率为 500ms 周期MES 显示基本无延迟。每台设备采集的地址表在做完点位核对后固化成一个配置文件方便调试。写入配方操作使用队列管理防止多个线程同时写同一台设备导致冲突。实际运行下来连续运行了数月没有出现过一次连接中断或者数据错乱。这个项目的关键是点位表在前期核对得足够细致页面上显示的每一个数据都能对应到具体地址。7.2 场景二老旧设备通过串口网关转 ModbusTCP 采集现场有若干台老款仪表只有 RS485 接口通讯协议是 ModbusRTU。我用一个多口网关把串口转成 TCP每台仪表分配一个从站地址Python 脚本通过网关 IP 不同 slave 读取。遇到的主要坑网关的写超时设置较短导致连续写入时偶发失败。把网关响应超时调大后问题解决。某些仪表对读请求数量敏感一次读取超过一定寄存器数量就返回异常。把读取数量控制在合理范围后一切正常。这个项目让我认识到一件事现场环境的复杂性往往不在通信本身而在设备兼容性上。8. 一些经验之谈用 ModbusTCP 对接 PLC 这件事真正难的不是代码而是对协议逻辑和设备特性的理解。我在实际工作中有几点体会特别深第一拿到新设备先读手册的“Modbus 地址映射表”而不是直接写代码。很多人一上来就写脚本结果点位对不上后续返工的成本远高于前期读文档的时间。第二调试时在 PLC 侧写入已知数值是一个最高效的手段。不管是字节序还是地址映射已知值能帮你快速验证链路正确性。第三日志记录一定要加而且是格式化的日志。生产环境出了问题如果没日志排错纯靠猜。我在所有采集程序里都会保留一个日志文件记录每次连接建立、断开、读异常的关键信息。第四能批量读取时坚决不逐点读。ModbusTCP 本身支持一次读多个连续寄存器充分利用这个特性可以减少通信消耗也降低 PLC 的通信负担。最后分享一个小技巧写 PLC 程序时经常会遇到“PLC 里数据没有变化但 Python 读到原始寄存器值是 65535”的异常情况。这个数字在 16 位无符号里表示最大值通常是传感器断线或者数据类型不匹配。不要怪协议先查信号源和地址往往更快见效。
