C# 与汇川 H5U PLC 的 Modbus-TCP 通讯实战：从帧结构到轮询框架

简介本资源面向具备一定C#基础的工控开发人员与自动化工程师聚焦于使用C#实现与汇川H5U PLC的Modbus-TCP通讯这一典型工业场景。内容围绕Modbus-TCP协议在TCP/IP栈上的报文交互展开涉及NModbus库的引入、TcpClient连接建立、寄存器与线圈读写等核心环节帮助读者打通上位机与PLC之间的数据通道。压缩包共61个文件以26个cs源码文件为主体辅以xaml界面文件、csproj与sln工程配置、json与txt说明文档及少量dll、exe等运行依赖整体约164KB结构紧凑可直接在Visual Studio中打开调试。资源中H5UModuleControl与H5UModuleData等模块划分清晰便于按功能定位代码。目前已有1556人学习下载适合希望快速掌握C#与汇川PLC通讯实现思路、对照源码理解Modbus-TCP交互流程的开发者参考。1. 从一根网线到读写寄存器C# 与汇川 H5U 的 Modbus-TCP 通讯到底怎么落地车间里一台汇川 H5U 系列 PLC 跑着产线逻辑上位机这边要用 C# 把产量、节拍、报警状态实时抓过来还要能下发配方参数。很多人第一反应是去找汇川的专用库或者 OPC 服务结果发现要么授权成本高要么部署链路太长。其实 H5U 自带以太网口原生支持 Modbus-TCP 从站协议只要上位机按标准 Modbus-TCP 帧格式发请求就能直接读写它内部的软元件不需要任何中间件。这条路子对做 C# 上位机的工程师来说是最短路径一个 TcpClient、一套帧封装、一张寄存器地址映射表就能把通讯跑通。适合刚接触汇川 PLC 的 C# 开发者、需要快速搭原型的设备工程师以及想把现有 Modbus 轮询框架复用到 H5U 上的老手。下面按实际调试顺序从协议帧拆到代码再到踩过的坑一步步来。2. Modbus-TCP 帧结构与 H5U 软元件映射先把地址表搞对2.1 为什么选 Modbus-TCP 而不是 Modbus-RTUH5U 的以太网口支持 Modbus-TCP 从站走的是 TCP 502 端口默认可改。相比 RS485 上的 Modbus-RTUTCP 省掉了串口参数配置、波特率匹配、终端电阻这些硬件层玄学帧头多了 MBAP 报文头但校验从 CRC 换成了 TCP 自带的校验反而更省心。实际项目里如果 H5U 和上位机在同一网段直接网线对接或者过交换机都行延迟稳定在毫秒级轮询几十个寄存器完全够用。常见做法是上位机做 Modbus-TCP 客户端MasterH5U 做从站Slave请求-响应模式一问一答。2.2 MBAP 头 PDU一帧请求到底长什么样Modbus-TCP 的完整帧 MBAP 头7 字节 PDU协议数据单元。MBAP 头结构如下字段长度说明事务标识符2 字节请求和响应配对用每次请求自增协议标识符2 字节Modbus 固定为 0x0000长度2 字节后续字节数单元标识符 PDU单元标识符1 字节从站地址H5U 默认 0x01TCP 下也常用 0xFFPDU 部分读保持寄存器功能码 0x03的请求是功能码(1) 起始地址(2) 寄存器数量(2)。响应是功能码(1) 字节数(1) 数据(N)。写单个寄存器0x06请求功能码(1) 地址(2) 值(2)。写多个寄存器0x10请求功能码(1) 起始地址(2) 数量(2) 字节数(1) 数据(N)。2.3 H5U 软元件与 Modbus 地址的对应关系这是最容易翻车的地方。H5U 的 Modbus 地址映射不是简单地把 D 寄存器编号直接当 Modbus 地址用。常见映射规则以实际手册为准不同固件版本可能有差异H5U 软元件Modbus 区域功能码地址换算M0-M7999线圈0x01/0x05/0x0FM 编号直接作为地址D0-D7999保持寄存器0x03/0x06/0x10D 编号直接作为地址X0-X377输入线圈0x02按八进制编号映射Y0-Y377输出线圈0x01/0x05按八进制编号映射我一般会先在 H5U 编程软件里确认 Modbus 从站功能已启用并记下单元标识符和端口号。然后拿一个 D 寄存器做测试比如 D100用功能码 0x03 读 1 个寄存器起始地址填 100。如果读回来不对先检查是不是地址偏移了 1有些文档写 40001 这种 Modbus 传统地址实际发帧时要减 1 或减 40001。// 构造读保持寄存器请求帧功能码 0x03 // transactionId: 事务标识每次请求递增 // unitId: 从站单元标识符H5U 默认 1 // startAddress: 起始寄存器地址如 D100 则填 100 // registerCount: 要读的寄存器数量 byte[] BuildReadHoldingRegisters(ushort transactionId, byte unitId, ushort startAddress, ushort registerCount) { var frame new byte[12]; // MBAP 7 字节 PDU 5 字节 // MBAP 头 frame[0] (byte)(transactionId 8); // 事务标识高字节 frame[1] (byte)(transactionId 0xFF); // 事务标识低字节 frame[2] 0x00; // 协议标识高字节 frame[3] 0x00; // 协议标识低字节 frame[4] 0x00; // 长度高字节 frame[5] 0x06; // 长度低字节单元标识符(1) PDU(5) 6 frame[6] unitId; // 单元标识符 // PDU frame[7] 0x03; // 功能码读保持寄存器 frame[8] (byte)(startAddress 8); // 起始地址高字节 frame[9] (byte)(startAddress 0xFF); // 起始地址低字节 frame[10] (byte)(registerCount 8); // 寄存器数量高字节 frame[11] (byte)(registerCount 0xFF); // 寄存器数量低字节 return frame; }这段代码里事务标识符用来匹配请求和响应如果并发请求多必须保证每个请求的 transactionId 唯一。长度字段固定为 6 是因为单元标识符 1 字节加 PDU 5 字节。起始地址和寄存器数量都是大端序高字节在前这是 Modbus 的规矩别按小端发了。3. C# 端 TcpClient 封装与同步读写实现把帧发出去、把数据收回来3.1 连接管理与超时设置用TcpClient连 H5U关键参数是ReceiveTimeout和SendTimeout。工业现场网络抖动难免超时设太短会频繁断连设太长会卡住 UI 线程。我一般设 1000ms 到 2000ms配合重试机制。连接建立后NetworkStream的读写是阻塞的如果在上位机主线程里直接调用界面会假死所以要么放后台线程要么用 async。using System; using System.Net.Sockets; public class ModbusTcpClient : IDisposable { private TcpClient _tcpClient; private NetworkStream _stream; private ushort _transactionId 0; public bool Connect(string ip, int port 502, int timeoutMs 2000) { try { _tcpClient new TcpClient(); // 异步连接并等待避免无限阻塞 var result _tcpClient.BeginConnect(ip, port, null, null); if (!result.AsyncWaitHandle.WaitOne(timeoutMs)) { _tcpClient.Close(); return false; } _tcpClient.EndConnect(result); _tcpClient.ReceiveTimeout timeoutMs; _tcpClient.SendTimeout timeoutMs; _stream _tcpClient.GetStream(); return true; } catch (Exception ex) { Console.WriteLine($连接失败: {ex.Message}); return false; } } public void Dispose() { _stream?.Close(); _tcpClient?.Close(); } }连接超时用BeginConnectWaitOne的方式比直接Connect更可控。ReceiveTimeout和SendTimeout设成一样的值保证读写都不会无限等待。注意TcpClient的NoDelay属性建议设为true禁用 Nagle 算法减少小包延迟对轮询场景有帮助。3.2 发送请求与解析响应发送就是_stream.Write接收要先读 MBAP 头拿到长度再读剩余字节。因为 TCP 是流式协议一次Read不一定能读全一帧必须循环读直到凑够长度。public byte[] SendAndReceive(byte[] request, int expectedResponseLength) { _transactionId; // 更新请求帧中的事务标识 request[0] (byte)(_transactionId 8); request[1] (byte)(_transactionId 0xFF); _stream.Write(request, 0, request.Length); // 先读 MBAP 头 7 字节 byte[] header new byte[7]; int read 0; while (read 7) { int n _stream.Read(header, read, 7 - read); if (n 0) throw new IOException(连接已关闭); read n; } // 从 MBAP 头第 5、6 字节取后续长度 int remaining (header[4] 8) | header[5]; byte[] body new byte[remaining]; read 0; while (read remaining) { int n _stream.Read(body, read, remaining - read); if (n 0) throw new IOException(连接已关闭); read n; } // 合并成完整响应帧 byte[] response new byte[7 remaining]; Array.Copy(header, 0, response, 0, 7); Array.Copy(body, 0, response, 7, remaining); return response; }这里先读 7 字节 MBAP 头从中解析出后续长度再循环读 body。_stream.Read返回 0 表示对端关闭连接必须抛异常或重连。响应帧回来后检查功能码是否等于请求功能码如果最高位是 1比如 0x83说明是异常响应后面一个字节是异常码常见的有 0x02非法地址、0x03非法数据值。3.3 读寄存器与写寄存器的完整调用示例把上面的方法串起来读 D100 开始的 2 个寄存器public ushort[] ReadHoldingRegisters(byte unitId, ushort startAddress, ushort count) { byte[] request BuildReadHoldingRegisters(0, unitId, startAddress, count); byte[] response SendAndReceive(request, 9 count * 2); // 检查异常 if ((response[7] 0x80) ! 0) { throw new Exception($Modbus 异常异常码: 0x{response[8]:X2}); } int byteCount response[8]; ushort[] values new ushort[byteCount / 2]; for (int i 0; i values.Length; i) { values[i] (ushort)((response[9 i * 2] 8) | response[10 i * 2]); } return values; }响应帧里response[7]是功能码response[8]是字节数后面才是数据。每个寄存器 2 字节大端序合成 ushort。写单个寄存器用功能码 0x06写多个用 0x10帧结构和读类似只是 PDU 不同。实际项目里我一般把读和写封装成独立方法上层调用只传地址和值不关心帧细节。4. 避坑与排查H5U Modbus-TCP 调试中常见的五个翻车点4.1 现象连接成功但读回来全是 0 或超时原因H5U 的 Modbus 从站功能没启用或者端口号不是 502。有些项目里 PLC 程序里没配置以太网参数或者被其他协议占用了端口。解决在 H5U 编程软件里检查以太网设置确认 Modbus-TCP 从站已使能端口号记下来。用ping确认网络通再用telnet IP 端口测端口是否开放。如果端口不通先解决 PLC 侧配置。4.2 现象读 D 寄存器返回异常码 0x02非法地址原因地址映射搞错了。H5U 的 D 寄存器在 Modbus 里不一定从 0 开始有些固件版本有偏移或者把 Modbus 传统地址40001直接填进去了。解决先用 H5U 软件监控 D100 的值然后发请求读地址 100。如果异常试地址 0 或 1确认偏移量。另外注意读多个寄存器时起始地址加数量不能超出该区域范围否则也会报非法地址。4.3 现象响应帧解析错位数据对不上原因TCP 粘包或拆包。一次Read可能读到多个响应帧的部分数据或者一帧分多次到达。上面的循环读方式能解决大部分情况但如果上位机同时发多个请求响应顺序可能乱。解决严格保证一问一答发一个请求等一个响应再发下一个。如果必须并发用事务标识符匹配响应并且每个连接独立。我一般用单连接同步轮询简单可靠。4.4 现象写寄存器后 PLC 值没变原因写的是只读区域或者功能码用错。比如用 0x06 写线圈应该用 0x05或者写 D 寄存器时地址填成了 M 区地址。解决确认软元件类型和功能码对应关系。写 D 寄存器用 0x06 或 0x10写 M 线圈用 0x05 或 0x0F。写之前先读一次确认地址可读再写。4.5 现象长时间运行后连接断开重连失败原因H5U 的 Modbus-TCP 从站有最大连接数限制或者空闲超时自动断开。上位机没有心跳机制网络交换机也可能老化。解决加心跳定期读一个固定寄存器。断线后先Dispose旧连接再重新Connect不要复用已断的TcpClient。重连间隔建议 1 到 2 秒避免频繁冲击 PLC。提示调试阶段用 Modbus Poll 或 Modbus Slave 工具先验证 PLC 侧配置再用 C# 代码对接能省一半时间。5. 进阶批量读写优化与一个可复用的轮询框架5.1 批量读写的地址合并技巧实际项目里要读的寄存器往往不是连续的比如 D100、D200、D300。如果逐个读一轮下来十几个请求延迟累积明显。常见做法是把地址相近的合并成一次读比如 D100 到 D110 一次读 11 个然后在内存里拆。但要注意如果中间有非法地址或跨区域合并会失败。我一般按区域分组M 区一组、D 区一组组内按地址排序相邻间隔小于 10 的合并间隔大的单独读。// 简单的地址合并示例把相邻的地址合并成块 // 输入是一组要读的寄存器地址输出是合并后的起始地址和数量 public static List(ushort start, ushort count) MergeAddresses(Listushort addresses, int maxGap 10) { addresses.Sort(); var blocks new List(ushort start, ushort count)(); ushort blockStart addresses[0]; ushort blockEnd addresses[0]; for (int i 1; i addresses.Count; i) { if (addresses[i] - blockEnd maxGap) { blockEnd addresses[i]; // 合并到当前块 } else { blocks.Add((blockStart, (ushort)(blockEnd - blockStart 1))); blockStart addresses[i]; blockEnd addresses[i]; } } blocks.Add((blockStart, (ushort)(blockEnd - blockStart 1))); return blocks; }maxGap控制合并的激进程度设 10 表示两个地址间隔不超过 10 就合并。合并后一次读回来再按原地址从数组里取对应偏移。这样能把十几个请求压缩到两三个轮询周期明显缩短。5.2 轮询线程与数据缓存上位机通常需要周期性刷新数据我一般起一个后台线程按固定间隔比如 200ms执行一轮读把结果写到一个线程安全的缓存字典里UI 线程只读缓存不直接碰网络。这样即使网络卡顿界面也不会卡。缓存用ConcurrentDictionarystring, ushortkey 用 “D100” 这种软元件名方便上层按名字取值。// 轮询线程示例 private CancellationTokenSource _cts; private ConcurrentDictionarystring, ushort _cache new ConcurrentDictionarystring, ushort(); public void StartPolling(ModbusTcpClient client, byte unitId) { _cts new CancellationTokenSource(); Task.Run(() { while (!_cts.IsCancellationRequested) { try { // 读 D100-D109 var values client.ReadHoldingRegisters(unitId, 100, 10); for (int i 0; i values.Length; i) { _cache[$D{100 i}] values[i]; } } catch (Exception ex) { Console.WriteLine($轮询异常: {ex.Message}); // 触发重连逻辑 } Thread.Sleep(200); } }, _cts.Token); }轮询间隔根据实际需求调太快会占满 PLC 通讯资源太慢数据不及时。200ms 是个折中值。异常处理里要区分是网络断还是 Modbus 异常网络断就重连Modbus 异常就记日志跳过。5.3 验证方法用 H5U 软件和抓包双重确认写完代码别急着上产线先做两步验证。第一步在 H5U 编程软件里监控目标寄存器手动改值看上位机缓存是否跟着变。第二步用 Wireshark 抓包过滤tcp.port 502看请求帧和响应帧的字节是否和代码构造的一致。抓包能看到事务标识符、功能码、地址、数据一眼就能定位是发错了还是收错了。我习惯在代码里加一个日志开关把每帧的十六进制打出来和抓包对照基本能覆盖所有协议层问题。从那以后我每次对接新的 Modbus-TCP 设备都强制先抓包确认帧格式再写解析代码省得在地址映射上反复试错。希望帮到你。本文还有配套的精品资源点击获取