简介一套围绕汇川AM402 PLC与C# Winform上位机开展Modbus TCP通讯的实战工程资源适合PLC工程师、上位机开发人员及工业通信初学者参考。压缩包内含完整测试项目覆盖从Socket非阻塞连接、Modbus功能码封装如读离散输入、写单个寄存器到异常重试与数据解析显示的联调链路文件共47个以C#源文件15个cs为核心配以工程配置、解决方案、编译生成的exe/pdb以及AM402 PLC测试程序等整体约922KB便于快速导入Visual Studio查看和运行。已有2256人浏览学习。其中通信类封装与PLC端测试程序可直接作为联调起点能节省自行搭建环境和排查报文格式的时间。1. 拿到 InproModebusTCP通讯测试 这类压缩包时先想清楚要解决什么问题拿到一个叫InproModebusTCP通讯测试.rar的压缩包在工控现场太常见了甲方、同事或设备厂商丢过来里面可能是测试脚本也可能是通讯测试的说明和记录潜台词都差不多——帮我把 Modbus TCP 通讯验证一下。这事看着简单实际上一大半时间耗在“连不上”和“数据不对”上。把这套测试做扎实不只是确认一次能不能通而是把测试沉淀成可复现、可留痕的过程后面验收和排障都能直接拿数据说话。下面这套做法适合做 PLC 调试、上位机开发和设备联调的工程师照着复现。2. 通讯测试前先看懂Modbus TCP 报文与主从站时序Modbus TCP 测试翻车的根源多数不是协议复杂而是把串口 Modbus 的习惯带了过来。串口要算 CRC、管波特率TCP 版就是标准 Modbus 报文用 TCP 封装固定端口 502链路交给 TCP 保证没有 CRC。换来的代价是参数错得隐蔽Unit ID、功能码、寄存器地址、字节序任何一个对不上返回的要么是异常码要么是永远“通了但不对”。好在 Modbus TCP 的报文非常短手工拆一组请求响应就能看清黑匣子里发生什么。这一章会从参数、报文到代码一步步把它摊开。2.1 从站地址、功能码、寄存器地址三个一错就翻车的参数Modbus TCP 里“从站地址”不叫地址叫 Unit ID。串口 Modbus 里这个字节必须和设备拨码一致TCP 版里它已经被 IP 取代了定位作用但很多设备仍然会校验它。常见的坑是主站发 Unit ID0有的设备会直接丢弃请求保守做法是填 1或者填设备手册指定的值抓包时注意看它有没有原样回显。功能码决定了“这次请求要干什么”。通讯测试里最常用的是 0x03 读保持寄存器、0x04 读输入寄存器、0x05 写单个线圈、0x10 写多个寄存器。把功能码搞错从站会回异常码 0x01非法功能码而不是你想读的数据。高手的习惯是先定功能码再定地址区域两者是绑定的保持寄存器用 0x03输入寄存器用 0x04不要把设备文档里的“寄存器地址 40001”直接当成 0x03 的起始地址来填。寄存器地址也要小心“差一个”的问题。Modbus 协议里的地址是从 0 开始计数的比如第一个保持寄存器是 0x0000但很多上位机、触摸屏和文档会用 PLC 式地址第一个保持寄存器写成 40001。于是你在工具里填 40001 还是 0答案是看工具怎么解释Modbus Poll 里填 0 对应协议地址 0x0000也就是文档里的 40001。地址差一、差十这种问题比协议本身难查得多尤其在寄存器数量多的时候表现为读回来整体偏移一位。2.2 拆一个读保持寄存器请求从 6 个字节看主从站对话先看请求侧。下面是一次读保持寄存器的完整请求共 12 个字节字段字节数示例值说明事务处理标识符20x0001用于匹配请求和响应协议标识符20x0000Modbus 协议固定为 0长度字段20x0006从单元标识符到报文结束共 6 字节单元标识符10x01从站地址 / Unit ID功能码10x03读保持寄存器起始地址20x0000从 0 号寄存器开始读寄存器数量20x000A连读 10 个寄存器请求的报文是00 01 00 00 00 06 01 03 00 00 00 0A。长度字段 0x0006 是后面01 03 00 00 00 0A这 6 个字节的计数不含自己的长度也不含事务标识符和协议标识符。很多手拼报文的人在这里算错导致从站直接断连。响应侧要会看长度和异常码。读 10 个寄存器的正常响应是00 01 00 00 00 17 01 03 14后跟 20 个字节数据。这里 0x1420 表示后面有 20 字节0x001723 是从单元标识符到报文结束的总字节数。如果返回的功能码变成 0x83说明请求被拒后面还会跟一个异常码0x01 非法功能码0x02 非法数据地址0x03 非法数据值0x04 从站设备故障。看到这些码别去查网络回头查参数。2.3 用 Python 模拟 Modbus TCP 主站最小代码先跑通一次读取工具点完一通最后还是要落一段能重复执行的代码。我一般用 pymodbus 3.x 写最小主站装好之后代码如下from pymodbus.client import ModbusTcpClient # 参数说明 # host - 从站 IP先确保和主站同网段 # port - Modbus TCP 固定 502除非设备改过 # timeout - 连接和响应超时单位秒初调建议 3~5 秒 client ModbusTcpClient(192.168.1.10, port502, timeout3) if not client.connect(): print(连接失败检查 IP、端口、网线和防火墙) exit(1) # 读保持寄存器(起始地址, 数量, slaveUnit ID) # 地址从 0 开始文档里写 40001 的寄存器这里就是 0 resp client.read_holding_registers(0x0000, count10, slave1) if resp.isError(): print(读返回异常功能码 0x%02X % resp.function_code) else: print(寄存器值, resp.registers) client.close()这段代码的逻辑很直白先建立 TCP 连接再发一次读请求最后判断返回是否异常。resp.isError()是 pymodbus 里判断异常响应的统一入口不用自己解析异常码如果返回异常function_code里能看到 0x83 这类带错误标志的功能码。写单个线圈也是同样的套路# 写线圈地址 0值 TrueUnit ID 保持和读请求一致 resp client.write_coil(0x0000, True, slave1) # 写多个保持寄存器地址 0x0100 起写入三个值 resp client.write_registers(0x0100, [100, 200, 300], slave1)pymodbus 里slave参数对应的就是报文里的 Unit ID读和写必须一致。如果设备要求 Unit ID 固定为 0xFF把所有slave都改成 0xFF。这段代码跑通说明 TCP 链路和协议参数都对了接下来才有资格谈测试。3. 把测试跑起来工具选型、最小步骤与读写轮询脚本通讯测试最大的浪费是每次换设备都重新点一遍工具、重新记一遍参数。我一般把它分成三块先用 PC 工具做连通性验证再用 PLC 库指令做设备侧验证最后用脚本做批量轮询和留痕。三块的分工不一样但测试参数要统一不然就会出现工具能通、程序不能复现的现象。这一章把三块的选型和落地步骤讲清楚。3.1 工具怎么选Modbus Poll、PLC 库指令和自写脚本的分工工具角色适合场景注意点Modbus PollPC 作主站最快验证从站能不能通、响应时间多少免费版有连接数限制注意 Unit ID 和超时设置Modbus SlavePC 作从站没有真实设备时模拟从站给上位机调寄存器地址范围要覆盖主站请求PLC 库指令如 SMART 200 的 MB_CLIENT / MB_SERVER设备侧主站或从站验证现场程序与库指令配合库存储区要单独分配不能和用户 V 区重叠pymodbus 脚本自定义主站批量轮询、偶发问题复现、留痕版本不同导入路径有差异以你环境里的版本为准选型不用贪多。现场排查我通常只开一个 Modbus Poll确认“从站是好的”然后立刻切回自己写的脚本做复现。Modbus Poll 能给你一个基线如果 Poll 能通而脚本不能通那就是脚本参数写错别让设备背锅。3.2 一轮完整通讯测试的最小步骤先读后写超时从 1000ms 开始完整测试我按六步走每一步都有明确产出。第一步把 IP 定死。主站和从站设置到同一网段从站用固定 IP不要依赖 DHCP。现场最常见的问题是 IP 冲突和子网掩码不对ping 不通就直接查这两项。第二步确认 TCP 端口能进。用命令验证ping 192.168.1.10 telnet 192.168.1.10 502telnet能出现一个黑窗口说明 TCP 层已经通了。这时不要急着关窗口等请求超时断开也算正常——Modbus TCP 没有握手协议对端不会主动发欢迎语。第三步读保持寄存器。Modbus Poll 里设置从站 IP、端口 502、Unit ID、功能码 0x03、起始地址 0、数量 10超时填 1000ms。能读出数值就记下基线包括响应时间。第四步写线圈或写寄存器。先找一个不影响工艺的地址比如空闲线圈或设备手册明确标注“测试用”的寄存器。写之前记录原值写后读回确认。这里特别提醒不要在运行中的设备上随意写写坏了没有后悔药。第五步观察连续轮询。把轮询周期从 1000ms 缩短到 200ms持续 5 分钟看有没有超时和异常码。短周期轮询最容易暴露从站处理能力不够的问题。第六步整理记录。把 IP、Unit ID、功能码、地址、数量、期望值、实读值、响应时间、错误码写进表格保留原始报文截图。这个习惯能省掉后面一半的扯皮。3.3 读写轮询脚本与测试记录模板结果要能留痕工具测试只能覆盖“当下这一会儿”要验证稳定性得让脚本挂机跑。下面这段脚本会把每一轮的结果写进 CSV同时统计平均延迟和错误次数import time import csv from pymodbus.client import ModbusTcpClient def run_test(host, port, unit, register, count, rounds100, interval0.2, timeout2): # host - 从站 IP # port - 502 # unit - Unit ID读和写必须一致 # register - 起始寄存器地址基于 0 # count - 单次读取的寄存器数量 # rounds - 总轮询次数 # interval - 轮询间隔秒不要小于从站响应时间 # timeout - 请求超时秒 client ModbusTcpClient(host, portport, timeouttimeout) if not client.connect(): print(连接失败, host, port) return ok 0 fail 0 latencies [] with open(mb_test_log.csv, w, newline) as f: writer csv.writer(f) writer.writerow([seq, timestamp, status, latency_ms, values]) for i in range(rounds): t0 time.time() resp client.read_holding_registers(register, countcount, slaveunit) dt_ms (time.time() - t0) * 1000 if not resp.isError(): ok 1 values .join(str(v) for v in resp.registers) writer.writerow([i, time.strftime(%H:%M:%S), OK, round(dt_ms, 2), values]) latencies.append(dt_ms) else: fail 1 writer.writerow([i, time.strftime(%H:%M:%S), ERR, round(dt_ms, 2), ]) time.sleep(interval) client.close() avg sum(latencies) / len(latencies) if latencies else 0 print(f完成OK{ok}, ERR{fail}, 平均延迟{avg:.1f}ms)逻辑说明每一轮先记录开始时间再发请求用dt_ms计算单次响应耗时isError()只负责判断协议层是否异常网络层的超时会抛异常或被 pymodbus 封装成错误响应所以ERR行要保留原始latency_ms超时的行通常延迟会等于 timeout 乘 1000。参数说明interval别设太短建议 200ms 起步从站处理不过来时缩短interval只会加剧失败不会提高吞吐。rounds想测长期稳定性就直接改成 86400配合 200ms 间隔可以连续跑一夜。CSV 里的latency_ms一列就是最直接的稳定性指标平均延迟正常不代表没有偶发超时要看的是ERR行的数量和时间分布。4. 避坑smart200 的 done 为 0与通讯测试里另外 4 个高频翻车点测试做得多了就会发现一个共性单次操作一切正常一进循环就出妖。这里面一半是参数问题一半是时序问题。下面 5 条是我调试现场最常碰到的按现象、原因、解决的顺序说看完能少走很多弯路。4.1 Done 一直为 0先查触发方式再查连接建立现象西门子 SMART 200 用 MB_CLIENT 指令做 Modbus TCP 主站EN 给通REQ 也给信号了但 Done 位始终为 0Error 位也不变化。很多人第一反应是“从站没连上”然后反复检查 IP 和端口其实一大半情况不是连接问题。最常见的第一个原因是 REQ 触发了。MB_CLIENT 是边沿触发指令REQ 必须有一个从 0 到 1 的跳变不能用常 ON 一直给高电平。如果你用 SM0.0 去驱动 REQ只有程序第一次扫描能产生上升沿之后永远没有新的请求Done 自然一直为 0。解决方法是把 Done 位取反后接回 REQ让上一条完成后自动发起下一条或者用一个定时器每 200ms 给一个脉冲。第二个原因是库存储区分配错位。SMART 200 的 Modbus 库需要单独指定一块 V 区作为库存储区这个区域不能和用户程序里用到的 V 区重叠。重叠后程序看起来在跑实际数据互相踩踏MB_CLIENT 的内部状态机根本走不完。解决方法是重新分配一个足够大的 V 区常见做法是留出 300 字节并确认程序其他地方没有使用这段地址。第三个原因是连接压根没建立。SMART 200 的 MB_SERVER 同一时刻只能处理一个客户端连接。如果你的电脑正开着 Modbus Poll 连着从站PLC 这边再发请求只能排队等待表现也是 Done 始终为 0。解决方法是先断开 PC 工具再观察 PLC 的 Done 位是否翻转。抓包确认 TCP 握手有没有建立一眼就能看出是哪一层卡住。4.2 连接占满、地址差一、字节序反转与异常码4 个高频问题现象Modbus Poll 还开着另一边 PLC 的 MB_SERVER 或者另一个主站就连接失败关掉 Poll 立刻恢复。原因就是上面说的连接数被占满。这不是玄学是很多从站设备同时只允许一个 TCP 连接。解决方式是测完一个工具立刻断开或者给 PC 工具配置空闲自动断开不要挂着一晚上不关。现象通讯正常但读回来的数值全是 0或者整体偏移了一个寄存器。优先怀疑地址基准不一致。工具里填 0 可能对应文档里的 40001也可能对应 40000取决于文档用哪种标注方式。解决方法是先用一个已知值的寄存器做基准比如从站手册里写明了某个寄存器固定为 0xC350先读到这个值再定位偏移量。现象读回来的数值单个看没问题但组合起来不对比如一个 32 位浮点数拆成两个寄存器数值完全对不上。这是字节序问题。Modbus 寄存器本身是大端但不同设备会把高字低字反过来甚至字节序也反转。解决方法是先读回一个已知值比如 0x12345678看报文里是12 34 56 78还是78 56 34 12确定设备是哪种字节序后在代码里统一转换。现象返回异常码 0x02非法数据地址。原因是请求的起始地址加数量超过了从站实际寄存器范围。解决方法是逐步缩小数量比如从 100 个改成 10 个定位到具体哪个地址越界另外检查功能码和地址区域是否匹配用 0x03 去读输入寄存器也会得到异常码 0x02因为在这种实现下那个地址不存在。现象PC 工具能通自己写的程序就是连不上。先查三件事第一程序是否绑定了错误的网卡第二防火墙是否拦截了 502 端口第三端口是否被其他程序占用。排查命令很简单netstat -ano | findstr 502如果有进程占着端口先杀掉它。这类问题最坑的地方在于“工具能通”会误导你让你一直去查从站配置实际上问题在自己主机上。5. 往后推一步用 Wireshark 把“能连通”升级成“能复现异常”前面说的都是基本连通测试。想把偶发超时这类问题定位准我会再加一层抓包对照。Wireshark 里用tcp.port 502作为抓包过滤器跑起来之后再叠加显示过滤器modbus就能直接看到 Modbus TCP 解析后的字段不需要自己数十六进制。抓包之后我习惯看三个时间点。第一个是 TCP 三次握手没有握手就说明请求根本没发出去问题在自己主机有握手但随后立刻 RST说明对端拒绝了连接查端口和 Unit ID。第二个是请求与响应的配对用事务标识符让 Wireshark 自动关联看响应里的功能码、地址和数据是否与请求一致。第三个是断开连接时有没有 FIN如果从站不主动断开主站也没有超时关闭机制连接就会一直被占住这就是偶发超时的经典来源。定位偶发问题还有个技巧不要只抓“出问题的那一刻”而是开着抓包跑完整轮询回头在 Wireshark 里按时间排序对比延迟突然变大的几秒钟里网络层发生了什么。是 TCP 重传还是从站迟迟不回响应前者是链路问题后者是从站固件或程序卡死了。有过一次血泪经验Modbus Poll 点着全通自己程序一跑就偶发超时抓包才发现有个客户端连接没有释放把从站的连接数占满了后续请求全在排队。从那以后我做通讯测试都会顺手看一眼连接建立和断开不能只看“有没有数据”连接生命周期本身也是测试对象。希望帮到你。本文还有配套的精品资源点击获取