简介资源围绕C#与汇川H5U PLC的Modbus-TCP通讯展开面向需要开发工业上位机或设备数据交互应用的C#工程师。包内含清晰的项目工程与核心源码覆盖从TcpClient连接建立、NModbus库调用到寄存器/线圈读写等关键环节并封装了H5UModuleControl、H5UModuleData等模块便于直接复用或二次开发。资源共61个文件以26个C#源码文件、XAML窗体布局、JSON配置及项目解决方案为主另含编译生成的exe/dll与调试缓存整体约164KB可直接在Visual Studio中打开H5UTest.sln运行学习。已有1563人浏览学习适合刚接触工业通信或希望快速落地PLC上位机功能的开发者。通过示例能掌握Modbus-TCP报文交互思路、异步读写处理及异常排查方法为产线数据采集和设备控制提供可参考的代码模板。1. 通讯这件事卡在“对地址”而不是“敲代码”做上位机开发的人第一次接触汇川 H5U最容易遇到的情况是C# 代码写好了TCP 也能连上但读出来的数据要么是 0要么是乱码要么干脆报错。原因往往不是代码写错而是 H5U 侧的 Modbus 从站地址映射没搞明白。H5U 支持 Modbus-TCP 从站功能但它的寄存器地址不是直接对应 %MW0、%MD0 这些 PLC 内部软元件而是要经过一层映射规则转换。标题里这个“通讯示例”真正要解决的就是这条链路C# 作为主站H5U 作为从站通过 Modbus-TCP 协议读写寄存器然后把寄存器里的原始数据解析成我们认识的整数、浮点数、字符串。适合谁看做设备数据采集、MES 对接、上位机监控的工程师特别是第一次把汇川 H5U 接进 C# 程序的人。2. 先把 H5U 侧的事情定下来IP、从站 ID 与地址映射2.1 H5U 作为 Modbus-TCP 从站的工作原理Modbus-TCP 是典型的主从问答式协议C# 这一侧是主站ClientH5U 这一侧是从站Server。主站主动发起请求从站收到后回复响应从站永远不会主动往主站推数据。这就意味着如果你想让 PLC 某一台设备的数据每隔一秒自动上报协议层面做不到唯一的办法是主站按固定周期去轮询读取。这个机制决定了 C# 侧程序的整体架构连接保持 定时读写而不是事件驱动。H5U 出厂默认开启了 Modbus-TCP 从站功能端口一般是 502但具体是否启用、从站 ID 是多少、哪些寄存器区域开放给主站读写要看 PLC 程序里的配置。常见做法是在汇川的编程软件里找到 Modbus 配置页面把需要对外暴露的软元件一一映射到 Modbus 地址空间比如把 %MW100 映射到保持寄存器的 40001 地址。这个映射关系决定了 C# 侧读到的是哪一块数据是通讯能否成功的第一道关卡。H5U 支持的 Modbus 功能区主要落在保持寄存器03 功能码读、06 写单寄存器、16 写多寄存器和输入寄存器04 功能码读上。保持寄存器是可读可写的输入寄存器只读。线圈和离散输入在 H5U 上一般不常用因为 PLC 内部的开关量通常通过寄存器位来访问而且位访问指令在 Modbus-TCP 上的执行效率并不比读寄存器高。所以建议把所有需要采集的数据无论是模拟量、计数器还是状态位全部归整到保持寄存器区。2.2 PLC 侧必查的三个配置项IP、端口、从站 ID在写 C# 代码之前先坐下来检查 H5U 侧的三项配置每一项都能让通讯彻底失败。第一项是 IP 地址。H5U 的以太网口 IP 需要和 C# 上位机在同一个网段并且不能冲突。很多新手把 PLC 的 IP 设置成 192.168.0.10上位机是 192.168.1.100两边完全不在一个网段TCP 连接根本建立不了还以为是代码问题。我的习惯是先在本机 ping 一下 PLC 的 IP通了再写通讯代码。第二项是端口号。H5U 的 Modbus-TCP 服务默认监听 502 端口但有些项目里 PLC 的网口还被其他协议占用或者现场网络设备改过端口。检查时注意看 PLC 侧配置页里的端口值C# 代码里 TcpClient 连接的端口必须和它一致。第三项是从站 ID也叫 Unit ID。虽然 Modbus-TCP 报文里这个字段只有 1 个字节但它的值必须和 PLC 侧配置的从站地址一致。有的 PLC 里设的是 1有的设的是 255如果 C# 代码里写的是 0请求就会被丢弃。这里有个坑很多 Modbus 库默认把 Unit ID 设成 0 或 1但你连的 PLC 可能配的是其他值所以建立连接后第一次读写前先确认 Unit ID 匹配。配置项典型值检查要点IP 地址192.168.0.10与上位机同网段ping 通端口号502与 PLC 配置页一致避免被防火墙拦截从站 ID1 或 255与 PLC 侧 Modbus 从站地址一致2.3 先规划一张地址映射表再动手写代码我在实际项目中吃过亏代码写了一半才发现 PLC 侧的变量没映射到 Modbus 地址只能停下来重新改 PLC 程序两边来回折腾。后来养成一个习惯动手前先做一张变量映射表把 C# 要读写的每一个变量和 PLC 程序里的软元件、Modbus 地址绑定清楚。这张表一般包含五列变量名、数据类型、PLC 软元件、Modbus 地址寄存器编号、读写方向。比如变量名数据类型PLC 软元件Modbus 地址方向设备启停状态位WORD 的第 0 位%MW10040001读当前温度浮点数%MD20040101读目标温度设定值浮点数%MD21040103读写设备运行模式无符号 16 位%MW30040150读写这张表的意义在于它把 C# 侧的代码和 PLC 侧的逻辑彻底解耦。后续如果 PLC 程序里的软元件地址变了只需要改这张表再同步改 C# 里的地址常量即可不需要重新梳理通讯逻辑。需要注意的是Modbus 地址写 40001 还是写 0取决于 Modbus 库的地址约定。有的库要求传寄存器索引 0有的库要求传 PLC 地址 40001用了错误的约定读出来的数据就会整体偏移 1 个寄存器这是常见问题后面避坑章再细说。3. C# 侧建立 Modbus-TCP 连接一次读写一个包3.1 先看懂 Modbus-TCP 报文结构省得被黑匣子坑不管用现成的 Modbus 库还是自己拼报文都得先理解 Modbus-TCP 的报文结构。Modbus-TCP 报文分为两部分MBAP 报文头7 个字节和协议数据单元PDU。MBAP 头包含四个字段事务处理标识符2 字节、协议标识符2 字节、长度2 字节、单元标识符1 字节。事务处理标识符用于匹配请求和响应。主站每次发一个请求带上自增的序号响应里会带回相同的事务 ID。这样可以判断收到的响应是不是刚才那个请求的回复尤其是 TCP 连接上同时有多个请求在途时这个字段特别重要。协议标识符在 Modbus 协议里固定为 0。长度字段表示后面所有字节的数量即单元标识符加 PDU 的总长度。单元标识符就是前面说的从站 ID。PDU 部分以功能码开头。读保持寄存器的功能码是 0x03请求 PDU 里包含起始地址2 字节和寄存器数量2 字节。响应 PDU 里是字节数1 字节和寄存器数据N 字节。一个寄存器占 2 字节所以读 10 个寄存器的响应数据区是 20 字节。如果请求的地址不存在或数量越界从站会返回异常响应功能码最高位置 1后面带一个异常码。0x02 表示非法数据地址0x03 表示非法数据值0x01 表示非法功能码。字段长度说明事务 ID2 字节请求响应匹配协议 ID2 字节Modbus 固定为 0长度2 字节单元 ID PDU 长度单元 ID1 字节从站地址功能码1 字节0x03 读保持寄存器起始地址2 字节寄存器索引寄存器数量2 字节连续读取的寄存器个数3.2 自己拼报文的最小读写示例如果项目里不方便引入第三方库或者需要完全掌控帧格式自己拼报文也只需要几十行代码。下面这个示例是用 TcpClient 发送一个读保持寄存器请求并解析响应中的数据。using System.Net.Sockets; static byte[] ReadHoldingRegisters(string ip, int port, byte unitId, ushort startAddr, ushort count) { using var tcp new TcpClient(); tcp.Connect(ip, port); var stream tcp.GetStream(); // 生成事务ID ushort transId (ushort)DateTime.Now.Millisecond; byte[] request new byte[12]; request[0] (byte)(transId 8); // 事务ID高字节 request[1] (byte)(transId 0xFF); // 事务ID低字节 request[2] 0; // 协议ID高字节 request[3] 0; // 协议ID低字节 request[4] 0; // 长度高字节 request[5] 6; // 长度低字节unitId(1) 功能码(1) 起始地址(2) 数量(2) request[6] unitId; // 单元ID从站地址 request[7] 0x03; // 功能码读保持寄存器 request[8] (byte)(startAddr 8); // 起始地址高字节 request[9] (byte)(startAddr 0xFF); request[10] (byte)(count 8); // 寄存器数量高字节 request[11] (byte)(count 0xFF); stream.Write(request, 0, request.Length); // 读取响应头事务ID 2 协议ID 2 长度 2 单元ID 1 功能码 1 8字节 byte[] header new byte[8]; stream.ReadExactly(header, 0, 8); if (header[0] ! request[0] || header[1] ! request[1]) throw new Exception(事务ID不匹配响应异常); if (header[7] 0x83) // 异常响应 throw new Exception($读寄存器异常错误码: {header[8]}); int dataLen (header[4] 8 | header[5]) - 3; // 总长度减去unitId、功能码、字节数字节 byte[] data new byte[dataLen]; stream.ReadExactly(data, 0, dataLen); return data; }这段代码的核心逻辑是先把请求报文按 Modbus-TCP 格式填入 byte 数组然后从响应里先读 8 字节头校验事务 ID 和异常码最后读取寄存器数据。参数上最需要关注的是事务 ID 的处理它不需要全局唯一只要在同一连接上短期内不重复就行示例里用毫秒时间戳的低 16 位实际项目可以换成自增计数器。ReadExactly方法会严格读满指定字节数避免因为网络分包导致只读到半个报文的情况。自己拼报文的优点是可控能精确处理每一个异常分支缺点是功能码一多代码量膨胀快而且容易在地址偏移、字节长度上犯错。如果项目只有读保持寄存器这一种操作自己拼完全没问题如果还要写寄存器、读多个数据区段就考虑用库。3.3 用现成库但要知道它帮你做了什么C# 生态里最常用的是 NModbus 库封装得比较完整。用库的前提是理解它内部做的事情建立 TcpClient 连接、拼装 MBAP 头、管理事务 ID、解析异常响应。下面是用 NModbus 完成同样操作的代码。using Modbus.Device; using System.Net.Sockets; var tcpClient new TcpClient(192.168.0.10, 502); var master ModbusIpMaster.CreateIp(tcpClient); // 读保持寄存器从寄存器索引0开始连续读10个 ushort startAddress 0; ushort numberOfRegisters 10; ushort[] registers master.ReadHoldingRegisters(0, startAddress, numberOfRegisters); foreach (var reg in registers) { Console.WriteLine($寄存器值: {reg}); }这里的第一个参数是 Unit ID也就是前面说的从站 ID必须和 PLC 侧配置一致。第二个参数是起始地址注意这里传的是寄存器索引 0对应 Modbus 协议报文里的起始地址 0而不是 40001。很多文档或表格里写的是 PLC 地址 40001实际调库时要换算成索引40001 对应索引 040002 对应索引 1。如果不换算直接传 40001请求的寄存器范围就可能超出 H5U 的映射区返回异常码。NModbus 的读方法返回ushort[]这只是原始寄存器值不区分数据类型。后面要转成浮点数、32 位整数还得自己做字节拼接和转换。另外库默认的读写超时时间设置可能偏短在工业现场网络抖动时容易出现超时异常建议根据实际情况调大。4. 寄存器读出来了但数值对吗字节序与多寄存器数据解析4.1 ushort 直接能用int 和 float 要从两个寄存器拼出来Modbus 寄存器的基本单位是 16 位一个寄存器对应一个 ushort。温度、压力这类模拟量如果直接用 16 位整型存读出来就是 ushort直接转 int 就能用基本没坑。但遇到 32 位整数或浮点数就需要把两个连续的寄存器拼起来。这里有一个必须警惕的字序问题。PLC 内部存储 32 位数据时不同品牌甚至同一品牌不同系列高低寄存器的顺序可能不一样。有的 PLC 把高 16 位放在前一个寄存器低 16 位放在后一个有的反过来。如果顺序搞反读到的数值完全不对但一时又很难发现。我一般会先写一个通用转换函数把寄存器数组按指定的字序拼接成 32 位值。// registers: 寄存器数组, startIndex: 起始下标, highWordFirst: 高字在前为true static int ConvertRegistersToInt32(ushort[] registers, int startIndex, bool highWordFirst) { if (highWordFirst) return (registers[startIndex] 16) | registers[startIndex 1]; else return (registers[startIndex 1] 16) | registers[startIndex]; } // 浮点数转换BitsConverter static float ConvertRegistersToFloat(ushort[] registers, int startIndex, bool highWordFirst) { int raw ConvertRegistersToInt32(registers, startIndex, highWordFirst); var bytes BitConverter.GetBytes(raw); return BitConverter.ToSingle(bytes, 0); }ConvertRegistersToInt32的关键在于先确认 highWordFirst 的值。怎么确认在 PLC 里写一个已知的 32 位值比如 0x12345678然后 C# 侧用两种顺序分别解析看哪个结果正确。一个常见做法是先用 highWordFirst true 试如果读出来的值感觉不对再换成 false。这里没有理论上的捷径不同厂家的固件习惯不同只能实测确认。除了字序还要注意 ushort 的符号问题。很多 PLC 里的温度值是带符号的但 Modbus 寄存器返回的是无符号的 ushort。比如 -10 度ushort 读出来是 65526C# 里强转成 short 才能得到 -10。4.2 字符串和 BCD 码的解析方式设备铭牌、批次号这类字符串数据在 PLC 里通常按 ASCII 码或多个寄存器存放。每个寄存器 2 字节可以放 2 个 ASCII 字符。高字节放第一个字符低字节放第二个字符这是最常见的存放顺序。但如果 PLC 工程里是按字序倒置的读出来就会变成字符串首尾互换、乱码。解析字符串时建议先把字节序问题单独抽出来测试。比如在 PLC 里存一个已知字符串 ABC看 C# 读出来是 ABC 还是乱码。如果是乱码就交换高低字节再解析。BCD 码相对少见但老设备上用得多。一个寄存器存两位十进制数高 4 位存十位低 4 位存个位。比如 0x1234 表示十进制 1234。C# 解析时不能直接转 int要用位运算把两个 BCD 字节分别拆出来再合并。static int BcdToInt(ushort reg) { int high (reg 8) 0x0F; // 高字节十位 int low (reg 0x0F); // 低字节个位 return high * 10 low; }这个函数只处理一个寄存器里的两位 BCD 码如果 BCD 值超过两位要按同样的逻辑扩展到多个字节。另外注意高位上的值如果大于 9说明不是合法的 BCD 编码有可能是字节序反了或读取地址错了。4.3 批量读取时把变量分组而不是一次跨块乱读一个常见的错误做法是把整张变量表从第一个地址到最后一个地址连续读一遍中间不管有没有没用到的寄存器。这样做的问题是Modbus 读操作要求连续地址如果中间某个地址在 H5U 上没有映射整个请求就会失败返回非法地址异常后面的数据全都读不到。我的做法是把映射表按用途分组成多个连续区段。比如设备状态区占 20 个寄存器温度数据区占 30 个寄存器分别用不同的起始地址去读。分组之后即使某一组读失败其他组的数据不会受影响。分组粒度可以根据实际的变量表来定关键是保证每一组的地址区间内所有寄存器都有效。批量写入同理。用功能码 0x10 写多个寄存器时数据长度字段是字节数寄存器数量是字数两者容易搞混。提交给 PLC 的数据要先把每个寄存器拆成高低两个字节再依次放入请求帧。5. 通讯不稳定从连接、超时、重连三个维度排雷5.1 现象ping 得通但 TCP 连接总被拒绝这个情况我遇到过多次网络明明是通的但 C# 这边TcpClient.Connect就是抛异常。可能的原因有两个一是 H5U 的 Modbus-TCP 服务没启用有些工程模式或运行状态下需要手动启动该服务二是防火墙拦截了 502 端口。解决方法是先检查 PLC 侧的服务状态再在上位机上用命令行工具确认端口是否开放。如果都没问题再排查 Unit ID 是否匹配有时候连接能建上但因为 Unit ID 不对第一次读写就返回异常看起来像连接失败。5.2 现象读到的数值比实际大很多或者变成负数温度 25 度读出来是 6400或者明明设备停了读出来一个很大的数基本就是字节序和字序问题不是通讯链路的问题。此时用前面提到的已知值验证法在 PLC 里写一个简单直观的 32 位数据比如 0x00000001然后用不同的解析顺序对照。如果按高字在前解析出 1那就固定用这种顺序。这里还有一个隐患在排查时改过解析代码结果过段时间发现代码里同时存在两种顺序的写法后面维护的人完全分不清哪个是对的所以注释里一定要写清楚验证日期和 PLC 固件版本区间。5.3 现象程序跑几分钟后偶发超时偶发超时的原因大多数不是网络而是请求频率和超时设置不匹配。如果 C# 侧定时器 10 毫秒发一次读请求而 PLC 处理一条 Modbus 指令需要 20 毫秒请求就会排队甚至被丢弃。我一般把轮询周期控制在 100 毫秒以上同时把读超时设成 1000 到 2000 毫秒。如果某个请求偶尔超时不要立刻判定 PLC 故障先看同一时刻有没有其他请求在途。如果开启了多线程并发读写同一个 H5U要引入锁或信号量保证同一个 TCP 连接上同时只有一个请求在等待响应。5.4 现象写寄存器返回成功但 PLC 程序没反应写入成功只代表 Modbus 从站收到了数据不代表它把数据写到了你想要的那个软元件上。最常见的原因是写进去的地址映射到了错误的寄存器区或者目标是掉电保持区但该区在程序运行中被周期刷新覆盖。检查思路是先把写入的地址和值在 PLC 侧监控窗口里确认看对应软元件有没有变化如果变了但程序没反应查程序里有没有其他地方对这个软元件做赋值。5.5 现象PLC 断电重启后C# 程序连不上PLC 重启往往比上位机慢上位机如果没做重连机制TCP 连接会断开且不会自动恢复。更严重的是如果重连逻辑写得不好会进入重连风暴每 100 毫秒尝试一次连接把 PLC 的通讯模块拖垮。这就是下面第 6 章要解决的问题。现象原因方向解决思路ping 通但连不上Modbus 服务未启用检查 PLC 侧服务状态数值不对字节序字序反了已知值验证后固定解析偶发超时轮询频率太快降低频率调大超时写成功但无效地址映射错误PLC 侧监控确认重启后连不上无重连机制状态机重连6. 把通讯程序做成一个可靠服务状态机与退避重连6.1 用状态机管理连接生命周期不要把连接逻辑散落在各个按钮事件或定时器里我通常会把通讯逻辑收敛成一个独立的后台服务用状态机管理连接状态。状态机的核心是四个状态已断开、连接中、已连接、重连中。每次状态切换都有明确的前置条件和动作。比如重连状态到已连接状态的迁移条件是 TcpClient 连接成功且完成一次读写握手。这样做的好处是任何时刻代码都清楚当前处于什么状态不会出现连接已经断开但定时器还在傻傻地发读请求的情况。6.2 心跳、看门狗与退避重连连接不能只在断开时才判断状态还要有主动探测机制。我一般会在连接建立后每隔 5 秒执行一次读操作读一个固定的寄存器值这个值在正常运行时保持不变。如果连续三次心跳失败就判定连接失效进入重连流程。重连不能立即疯狂尝试要有退避策略。我的习惯是第一次重连等 1 秒第二次等 2 秒第三次等 5 秒之后固定为 5 秒一次直到连接成功。这样 PLC 重启期间上位机的请求不会把通讯端口打满。数据读写还要加看门狗如果超过设定时间没有收到任何有效的响应就把当前请求超时并在状态机上做标记防止线程卡死在等待响应的代码里。6.3 一次真实教训带来的设计修正有一次在现场调试PLC 在前一天晚上断电第二天早上恢复供电但上位机程序里的一堆线程全部卡住因为 TCP 连接已经断了却没有一个地方去通知那些正在等待响应的请求超时退出。那次之后我就养成了两个习惯所有读写请求必须带超时控制所有连接断开必须统一通知上层业务模块同时用读写线程池而不是无限制地创建新线程。现在这套状态机加深呼吸心跳的模式已经用在多个模拟项目里效果稳定。给 H5U 做通讯最大的坑从来不是协议本身而是对异常情况的容忍度不够。越是想把程序写得一步到位现场就越容易被一根网线、一个 IP 改动绊倒。早点把状态管理和重连机制补上后面会省很多半夜去现场调试的时间。希望帮到你。本文还有配套的精品资源点击获取