上位机与汇川PLC的Modbus TCP通讯：视觉结果回写与联调避坑指南

简介：针对汇川H5U/H3U系列PLC的Modbus TCP上位机通讯示例工程，面向工控软件开发者与PLC集成调试人员，解决上位机与PLC稳定读写、批量采集及视觉通讯联调等工程问题。资源经两星期实际测试，已稳定运行并落地到项目中；支持M、Y、X、D、DD、S、R等软元件读取，具备批量读取能力，吞吐速度较快，且读取过程中可同时写入，弥补了常见实现只能单向操作的局限。压缩包共87个文件，约10.34MB，以C#源代码（cs）为核心，配套可执行文件（exe）、动态库（dll）、配置文件（config）与文本说明（txt），便于二次开发和现场部署。工程内部标注使用方法和中文注释，读者可直接借鉴通讯架构与批量读写逻辑。已有20395人学习下载，适合需要快速实现汇川PLC上位机通讯的开发者参考复用。

1. 上位机与汇川PLC通讯：一条视觉检测链路的落地参考

一台检测工位的上位机要在 300ms 内把视觉判定结果写进汇川 PLC，机械手才能准确分料。我见过不少项目卡在这一步，问题往往不在写代码，而在协议选型、寄存器映射和断线重连这三件小事上。这个项目把「上位机 ↔ 汇川 PLC」的通讯完整做了一遍：上位机基于 Modbus TCP 读取产线状态、下发命令，并把视觉通讯的结果实时写回 PLC，同时带心跳监测、断线重连和寄存器地址配置。它适合正在做上位机软件、视觉集成或 PLC 联调的开发者，你可以把它当成一套能直接跑、能照着改的通讯工程模板。

2. 技术架构与协议选型：Modbus TCP 链路全景

2.1 通讯链路全景：上位机、PLC 与视觉系统如何各司其职

上位机这边我习惯拆成三层：界面层只管显示和按钮，业务层处理视觉结果、计数、报警逻辑，通讯层单独负责 Socket 连接、报文封装、断线重连。这样拆的原因是通讯层最容易出隐性故障，它一旦和业务代码搅在一起，后面排查一个“写不进”的问题往往要翻遍整个窗体文件，成本极高。

项目里汇川 PLC 作为 Modbus TCP 从站，上位机作为主站主动发起读写。视觉系统不是独立通道，而是通过上位机中转：相机 SDK 把检测结果交给业务层，业务层调用通讯层写入 PLC 指定寄存器。这样设计的好处是视觉模块可以单独替换，只要保持回调接口不变，换算法、换相机品牌都不影响 PLC 侧程序。

2.2 为什么选 Modbus TCP 而不是串口 RTU

很多老产线还在用 RS485 串口 RTU，这个项目选用 Modbus TCP 主要是三个现实原因。第一是速度，串口波特率一般 115200，一个读写周期在十几毫秒到几十毫秒，视觉判定场景要求 300ms 内完成从拍照到结果回写，串口也能撑住，但余量太紧；Modbus TCP 在百兆或千兆局域网里，只要报文不大，一次往返基本在 1ms 级别。第二是多主访问，串口 RTU 是单主站轮询结构，如果上位机、HMI 同时要读数据会很别扭；Modbus TCP 允许局域网内多个主站同时连接同一个从站，产线调试时特别省事。第三是链路自诊断，TCP 自带序列号和重传机制，断线能被及时发现，而串口线松了往往要等到超时才发现。

补充一点：串口 RTU 的抗干扰和长距离传输并不差，项目里选 Modbus TCP，不是说 RTU 不好，而是这个场景是机台内部通讯，距离不超过 10 米，网线布防方便，PLC 又自带以太网口，后续要接扫码枪、相机，统一走交换机比再插一个串口服务器划算。如果你遇到的是几十米甚至上百米的分布式产线，RTU 反而可能是更稳的选择。

2.3 寄存器地址映射：PLC 软元件与 Modbus 地址的对应关系

汇川 PLC 的软元件里，M 区是位元件，D 区是字元件。Modbus 协议里对应关系是：M 区映射到线圈，用功能码 01 读、05 写单个、15（0F）写多个；D 区映射到保持寄存器，用功能码 03 读、06 写单个、16（10）写多个。输入寄存器 04 和离散输入 02 这个项目没用到，因为 PLC 侧完全可以用 M 和 D 区覆盖。

这个项目里寄存器表规划如下：

这里有个容易搞混的点：PLC 监控里看到的是 D10，但 Modbus 报文的地址是 40011。因为协议里保持寄存器编号从 1 开始，而 PLC 软元件从 0 开始偏移。真正发到网上的报文里，地址字段是 10（十六进制 0x000A），不是 11。有的通讯库已经帮你处理了这个差额，直接传 10 就行；自己写协议时，注意这个 1 的差值，把它写进注释里，避免后来维护的人对着报文数据一头雾水。我一般建议直接用「PLC 地址」作为沟通口径，在配置里单独做换算，不要在代码里写死 40011 这种神秘数字。

3. 核心实现拆解：握手、读写与视觉结果回写

3.1 通讯层封装：连接握手与超时控制

通讯层的入口是 Connect 方法。这里用 Socket 自己实现 TCP 连接，不依赖第三方库，好处是遇到问题可以直接抓报文手算字节，不必被库封装的黑匣子挡住。代码里有两个细节：锁对象_lock防止 UI 线程和后台线程同时对连接做操作；BeginConnect 配合 WaitOne 实现可配置的超时。

private static TcpClient _client; private static readonly object _lock = new object(); public static bool Connect(string ip, int port, int timeoutMs = 2000) { lock (_lock) { try { _client?.Close(); _client = new TcpClient(); IAsyncResult ar = _client.BeginConnect(ip, port, null, null); if (!ar.AsyncWaitHandle.WaitOne(timeoutMs)) { _client.Close(); return false; // 超时未连接成功，释放资源后返回失败 } _client.EndConnect(ar); _client.NoDelay = true; return _client.Connected; } catch { return false; } } }

参数说明：ip 是 PLC 的以太网 IP，port 固定 502，timeoutMs 默认 2000 毫秒。BeginConnect 先建立异步连接，WaitOne 在超时时间内等待握手完成；如果不成功，把资源清理掉再返回 false。NoDelay 设为 true，是为了关闭 Nagle 算法，避免连续发送小报文时被 TCP 攒包，导致 PLC 侧响应延迟。

3.2 读保持寄存器：报文结构与解析

读 D 区在 Modbus 里就是读保持寄存器，功能码 03。请求报文一共 12 个字节：前 7 个字节是 MBAP 头，后 5 个字节是 PDU。事务 ID 占高位，协议标识固定为 0，长度字段是后面数据的字节数，再往后依次是设备号、功能码、起始地址、寄存器数量。

public static byte[] BuildReadRequest(ushort transId, byte unitId, ushort startAddr, ushort quantity) { byte[] frame = new byte[12]; frame[0] = (byte)(transId >> 8); // 事务ID高位 frame[1] = (byte)(transId & 0xFF); // 事务ID低位 frame[2] = 0x00; frame[3] = 0x00; // 协议标识固定0 frame[4] = 0x00; frame[5] = 0x06; // 剩余字节数：unitId+func+addr2+quantity2 frame[6] = unitId; // 从站设备号 frame[7] = 0x03; // 功能码03 frame[8] = (byte)(startAddr >> 8); frame[9] = (byte)(startAddr & 0xFF); frame[10] = (byte)(quantity >> 8); frame[11] = (byte)(quantity & 0xFF); return frame; }

收到响应后解析，格式是：事务 ID 两字节、协议标识两字节、长度两字节、设备号一字节、功能码一字节、字节数一字节，然后才是寄存器数据。正常响应里功能码还是 03；如果 PLC 返回异常，功能码最高位置 1 变成 0x83，后面跟异常码。

public static ushort[] ParseReadResponse(byte[] resp, ushort quantity) { if (resp.Length < 9 + quantity * 2) return null; if (resp[7] != 0x03) return null; // 0x83 表示异常，这里简化处理 ushort[] values = new ushort[quantity]; for (int i = 0; i < quantity; i++) { // Modbus 规定寄存器高位字节在前 values[i] = (ushort)((resp[9 + i * 2] << 8) | resp[10 + i * 2]); } return values; }

解析时特别注意下标：resp[0] 到 resp[5] 是事务 ID、协议标识和长度，resp[6] 是从站设备号，resp[7] 是功能码，resp[8] 是字节数，真正数据从 resp[9] 开始。很多新手上来就从 resp[7] 开始取数据，读回来的值全是错位后的结果，这类问题最难排查，因为它不报错，只是数据不对。

3.3 写单个寄存器：视觉判定结果回写 PLC

视觉通讯的落点就是把判定结果写进 D100。项目里结果值被定义成枚举：1 表示 OK，2 表示 NG，0 表示无效。写单个保持寄存器用的功能码是 06，报文同样是 12 字节，只是 PDU 里没有数量字段，取而代之的是要写入的值。

public static byte[] BuildWriteSingleRegister(ushort transId, byte unitId, ushort regAddr, ushort value) { byte[] frame = new byte[12]; frame[0] = (byte)(transId >> 8); frame[1] = (byte)(transId & 0xFF); frame[2] = 0x00; frame[3] = 0x00; frame[4] = 0x00; frame[5] = 0x06; frame[6] = unitId; frame[7] = 0x06; // 功能码06 frame[8] = (byte)(regAddr >> 8); frame[9] = (byte)(regAddr & 0xFF); frame[10] = (byte)(value >> 8); frame[11] = (byte)(value & 0xFF); return frame; }

调用侧这样写：

if (visionResult == ResultType.OK) { SendFrame(BuildWriteSingleRegister(1, 1, 100, 1)); // D100=1 表示OK } else { SendFrame(BuildWriteSingleRegister(1, 1, 100, 2)); // D100=2 表示NG }

regAddr 这个参数传的是 PLC 软元件地址的偏移量，也就是 D100 传 100，而不是 Modbus 地址 40101。这个映射关系放在通讯层统一处理，界面和业务层只写 “D100”，不需要知道 Modbus 编号，减少一层心智负担。value 参数注意是大端序，先高字节后低字节。

3.4 视觉通讯轮询：请求位、完成位与 50ms 周期

产线上的典型配合是：PLC 程序判定当前有工件到位，就往 D10 写 1，表示“请求拍照”。上位机轮询到 D10 为 1，触发相机拍照，拿到结果后写入 D100，再把 D11 置 1 告诉 PLC “本次拍照完成”。PLC 看到 D11 为 1，就去读 D100，处理完下料逻辑后把 D10 和 D11 一起清零。这个握手过程里没有谁主动给谁发命令，而是靠两个寄存器位配合，最常见也最不容易乱。

while (true) { ushort[] req = ReadHoldingRegisters(10, 1); // 读 D10 if (req != null && req[0] == 1) { bool ok = CaptureAndDetect(out int result); // 调用视觉SDK，执行拍照和算法 WriteSingleRegister(100, (ushort)(ok ? 1 : 2)); WriteSingleRegister(11, 1); // 置完成位 } Thread.Sleep(50); }

参数说明：ReadHoldingRegisters 的第一个参数是 PLC 地址偏移量，不是 Modbus 地址。CaptureAndDetect 是视觉模块的入口，在真实项目里替换成相机 SDK 的采集加算法调用即可。轮询周期 50ms 是经验值：太快会占用 CPU 和网卡带宽，太慢又可能错过 PLC 的短暂信号，在 300ms 节拍要求下，50ms 足够捕捉到所有请求。如果 PLC 侧触发位只保持一个扫描周期，建议改成“PLC 置位后保持到上位机回完成位才复位”的互锁写法。

4. 联调避坑指南：连接超时、数据错乱与断线假死

4.1 联调前的准备：IP、端口与最小验证清单

联调里踩过的坑我总结过好几类，每条背后都对应一个真实现场。但最值得先做的其实是“最小验证”：在写任何业务代码之前，先确认上位机能不能用调试工具读到 PLC 的寄存器。我一般是三步。第一步，把工控机和 PLC 的 IP 设到同一网段，例如工控机 192.168.1.20，PLC 192.168.1.10；第二步，在 PLC 编程软件里确认 Modbus TCP 服务已经使能，记录端口号，默认是 502；第三步，用 Modbus 从站调试工具读一个已知寄存器，比如 D0，确认能读到值。这一步能提前排除掉八成以上的通讯问题，剩下的才值得去查代码。

4.2 避坑一：Socket 能连上，但读 D0 永远是 0

现象：上位机 TCP 连接成功，发读请求也没有异常返回，但 D0 的值一直是 0。

原因：首先是 PLC 侧 Modbus TCP 会把 D 区直接映射出来，如果 PLC 程序里没有往 D0 写过任何值，寄存器出厂初始值就是 0。其次是有些系列 PLC 的保持寄存器区分为掉电保持区和非保持区，默认数据区可能和掉电保持区不重叠，导致写入和读出根本不在同一个物理位置。

解决：在 PLC 程序的初始化逻辑里给 D0 写入一个非零初值，例如用 M8002 初始化脉冲，然后在线监控确认 D0 已经变了。如果还是 0，再看这个 D 区是否在掉电保持区内，以及初始化逻辑是否真的执行过。这类问题本质不是通讯问题，而是 PLC 侧数据源问题，但现象在通讯层，最容易误导初次上手的人。

4.3 避坑二：写入 100，PLC 侧读到 25600

现象：上位机写了一个整数 100，在 PLC 监控里看到的却是 25600，或者用别的工具读出来数据错乱。

原因：这是字节序搞错了。100 的十六进制是 0x0064，Modbus TCP 规定寄存器高位字节在前。如果发送端先放了低字节，报文中变成 0x64 0x00，PLC 侧收到的就是 0x6400，等于 25600。如果 PLC 侧变量定义时也按小端读写，数据会被再次颠倒，看起来毫无规律。

解决：发送端统一按“高位在前”组包，接收端用(byte0 << 8) | byte1解析。遇到某些固件版本对字序有特殊处理时，在配置里加一个字节序开关，界面里可以切换 AB / BA，不要每次改代码重新编译。这个坑几乎每个写 Modbus 上位机的人都会遇到一次，知道原理后其实就一行代码的事。

4.4 避坑三：上位机程序重启后，PLC 端连接假死

现象：上位机异常退出后再次启动，Connect 显示成功，但发送请求后一直等不到响应，过几分钟又自己恢复了。

原因：TCP 连接没有正常四次挥手断开，PLC 从站侧还保留着旧的 TCP 连接。新连接和旧连接的四元组（源IP、源端口、目标IP、目标端口）完全相同，PLC 协议栈认为这是重复连接，于是拒绝响应。

解决：程序启动后先主动 close 上一次的 Socket，再走 Connect；同时把 TcpClient 的客户端端口设置成 ReuseAddress。如果还是复现，去 PLC 的通讯参数里找“自动断开时间”或“无通信超时”，默认 300 秒比较长，现场可以调到 30 秒，让 PLC 主动清掉僵尸连接。这个问题在工控机上特别常见，因为工控机随时可能断电、杀进程，连接残留几乎是必然事件。

4.5 避坑四：视觉结果写成功了，但 PLC 动作不触发

现象：上位机日志显示写 D100 成功，响应帧也没有异常，但机械手不动作。

原因：常见有两种。一是 PLC 程序里对 D100 用的是“等于 1”的电平判断，而上次写入的 1 没有及时被清掉，导致下一次的 1 不构成有效触发；二是上位机写入后，PLC 扫描周期刚好错过上升沿，动作条件被跳过了。

解决：在 PLC 侧把 D100 的判定改成上升沿触发，或者要求上位机写完结果后，必须等 PLC 把 D100 读走并清 0 再开始下一次拍照。更稳妥的是前面提到的请求位/完成位互锁协议，拍照请求和完成状态各自占用寄存器，任何一方不参与握手流程就走不下去。这种设计让视觉通讯从“尽力而为”变成“可确认交付”，在产线上能省掉大量猜疑。

5. 二次开发技巧：把通讯层做成可配置的通用组件

5.1 点位表外置：JSON 配置驱动

项目里把寄存器映射直接写在代码里可以跑，但换个产线就要改代码重新编译，非常痛苦。我习惯把点位表抽成 JSON，启动时加载配置对象。这样换设备、换点位都不用动通讯层和业务层。

{ "plc": { "ip": "192.168.1.10", "port": 502, "unitId": 1, "timeoutMs": 2000 }, "points": [ { "name": "RequestCapture", "area": "D", "offset": 10, "direction": "read" }, { "name": "CaptureDone", "area": "D", "offset": 11, "direction": "write" }, { "name": "VisionResult", "area": "D", "offset": 100, "direction": "write" } ] }

加载之后，点名字符串就成了唯一标识，业务层不要再出现裸的 100、11 这种魔法数字。即使临时要读 D200，也只要加一行配置，不用重新编译。

5.2 定义设备接口，把协议实现隔离在门后

为了让通讯层未来能兼容串口 RTU 或厂家私有协议，对外暴露的接口收窄成三个方法加一个事件。内部用什么协议实现，外部不关心。

public interface IPlcClient { bool Connect(); bool ReadWord(string pointName, out ushort value); bool WriteWord(string pointName, ushort value); event Action<string> OnDisconnected; }

ReadWord 和 WriteWord 接收点名字符串，内部根据点位表自动换算地址和功能码。OnDisconnected 事件让业务层可以订阅断线告警。这样写视觉流程代码时完全不知道 TCP 和 Modbus 的存在，未来替换成任何新协议都只需要实现这个接口。

5.3 模拟从站先行验证

我的习惯是先起一个 Modbus 从站模拟程序，把配置里的点位表模拟出来，在模拟环境里跑完整个视觉握手流程，确认请求位、完成位、结果寄存器的读写值全部符合预期，再上真机。具体操作是：启动模拟从站，把配置文件的 ip 改成 127.0.0.1，跑业务层看日志，人工往模拟寄存器写值，验证上位机读到的和发出的都正确。这样才能把问题切分成“通讯代码问题”和“PLC 程序问题”两类，不用抱着笔记本蹲在现场改一行试一次。

从那以后，我每个视觉通讯项目都强制先走一遍“配置点位表 → 模拟从站 → 人工造数据 → 联调真机”的流程。尤其写 D 区值的时候，先在模拟从站里把写进去的值读出来核对一遍，再上产线，比直接在真机上反复试要省太多时间。希望帮到你。

本文还有配套的精品资源，点击获取