简介：一套C#与汇川PLC通信开发示例资源，主要面向工业上位机软件开发者与自动化系统集成人员，重点呈现基于Modbus TCP协议的通信流程、网络编程要点，以及上位机界面如何与PLC数据进行交互。压缩包内共有624个文件，整体约214.54MB，以C#与C++源文件、工程文件、可执行程序与动态链接库为核心，并配有说明文档、日志和调试记录，便于按模块阅读和实践。整体目录结构较完整，示例函数封装与调用分离，便于对照理解协议细节。目前已有580人学习，包内多个测试工程演示了Modbus寄存器读写、I/O状态获取、TCP连接建立、异常处理与性能优化等关键环节，编译好的程序可直接运行验证效果。通过研读源码和接口调用过程，可以快速理清汇川PLC的地址映射、报文构造及校验规则，并在此之上改造复用，缩短自动化系统集成中的通信调试周期。
1. C# 与汇川 PLC 通信示例：先解决三个影响成败的参数
C# 与汇川 PLC 通信示例下载下来，最容易出现的情况是：代码能编译、TcpClient 也能连上，但第一条读寄存器的指令就超时，或者返回一堆对不上的数据。问题通常不在 C# 语法，而在三个协议层面的参数——MBAP 报文的 Length 字段、PLC 点表地址到报文 PDU 地址的偏移、以及 Modbus 大端字节序。
这份示例的价值在于它把「C# 网络通信」和「PLC 寄存器读写」之间的黑匣子拆开：不是调一个封装好的控件双击绑定，而是从 Socket 连接、报文拼接、响应解析一步步走完。适合刚接触上位机开发的工程师，也适合那些用库调通了但心里没底、一换 PLC 型号就翻车的人。按这个思路复现一次，后续换网口、换 PLC 品牌，你都能用同一套报文分析能力去排查。
2. 通信方式选型：为什么示例默认走 Modbus TCP 而不是 OPC UA
2.1 三条理由：透明、兼容、易调试
汇川带以太网口的 PLC 型号，常见都内置 Modbus TCP 服务器，不需要额外授权，也不需要加网关。对做示例来说，这是最优先考虑的一条链路。相比 OPC UA，Modbus TCP 的报文结构固定，用一个 Socket 加 byte 数组就能完成全部收发，Wireshark 抓到什么就是什么，不存在协议栈内部的隐含状态。
OPC UA 在数据模型和安全策略上强很多，但代价是初始化复杂：证书、端点、命名空间、节点 ID 映射，一套跑通的时间够把 Modbus TCP 示例跑三遍。裸 Socket 直连自定义协议则更麻烦，汇川专用协议不在公开文档里，第三方系统去适配成本太高，也不适合作为通用示例。
| 对比项 | Modbus TCP | OPC UA | 裸 Socket 自定义协议 |
|---|---|---|---|
| 学习成本 | 低，报文结构固定 | 高，先过证书和数据模型 | 中，但需私有协议文档 |
| 调试手段 | Wireshark 直接抓包看 | 要用 UA Expert 等工具 | 基本靠双方日志 |
| PLC 侧配置 | 多数带网口型号直接支持 | 部分型号需额外使能 | 取决于 PLC 固件 |
| 适合场景 | 快速打通数据链路、中小点数 | 跨厂商、跨车间数据集成 | 厂商深度定制 |
我一般建议把 Modbus TCP 作为项目的默认起点，等遇到多客户端并发、数据语义需要自描述时再考虑 OPC UA。示例遵循同一原则：先跑通一条读写链路，再看需不需要升级。
2.2 Modbus TCP 报文结构：MBAP 头 6 个字节决定成败
Modbus TCP 请求和响应都以 MBAP 头开始，6 个字节固定不变：事务 ID 2 字节、协议 ID 2 字节（恒为 0）、长度 2 字节。长度字段计算的是它自身之后的所有字节数，也就是从单元 ID 开始到报文结束。很多人第一次自己拼报文，长度字段多算 1 或少算 1，PLC 侧直接不响应。
| 字段 | 长度 | 含义 |
|---|---|---|
| Transaction ID | 2 | 事务标识，请求响应需一致 |
| Protocol ID | 2 | 固定 0x0000 |
| Length | 2 | 后续字节数 |
| Unit ID | 1 | 从站号，常见为 1 |
| Function Code | 1 | 读/写功能码 |
| Data | N | 地址、数量或数据 |
功能码在示例里最常用到四个：0x03 读保持寄存器、0x01 读线圈、0x06 写单个寄存器、0x10 写多个寄存器。响应里的功能码如果带了最高位，比如 0x83，说明 PLC 返回异常码，常见原因不是数量越界就是地址越界。
组装请求时顺序不能乱：先是起始地址高字节、低字节，再是寄存器数量高字节、低字节。PLC 内部严格按大端解析，C# 的 BitConverter 默认小端，这两者如果不做转换，读回的数据就会出现高低字节对调。
2.3 汇川侧地址映射：D 区、M 区与 PDU 地址的换算
PLC 组态软件里显示的是点表地址，报文里用的是从 0 开始的 PDU 物理地址，两者差着一个基准偏移，这是最常见的翻车点。以某型号带网口汇川 PLC 为例，Modbus 映射表里 D 区对应保持寄存器区，基准是 400001；M 区对应线圈区，基准是 000001。
举例：PLC 侧点表 D100，对应 Modbus 显示地址 400101。但报文 PDU 里要填的是 0x0064，也就是 100。换算规则是：PDU 地址 = 面板显示地址 - 区基准地址。保持寄存器区显示 400101，减去 400001 得到 0x0064；线圈区显示 000033，减去 000001 得到 0x0020。
这个换算在不同软件上呈现方式不同，有的显示 400101，有的直接显示 0x0064，还有库会自动补 1。拿到一台新 PLC 时，第一件事是在 PLC 组态软件里打开 Modbus 映射表，确认基准偏移和起始地址，不要直接照抄别人项目的参数。
3. 工程落地：用一套可复用的 C# 通信类把读写打通
3.1 为什么不用现成 Modbus 库：示例阶段自己拼报文更值
第三方库确实能省时间，但会把地址、端序、异常码全部包进封装层，出了问题只能看库文档猜。示例的目的不是「调通一次」，而是「搞清楚每一步在做什么」。自己拼报文，事务 ID、长度字段、地址偏移都在手里，现场排查时能直接对着抓包结果说话。等这套逻辑跑稳定后，再决定要不要用库重写。
下面的实现不依赖 .NET 8 的新 API，连老工控机上常用的 .NET Framework 4.x 也能编译。每个字节都是手工移位拼接，这样无论目标框架是什么，逻辑都一样。
3.2 通信类核心代码：连接、读保持寄存器、防拆包
using System.Net.Sockets; public class ModbusTcpClient : IDisposable { private TcpClient _tcp; private NetworkStream _stream; private ushort _transactionId; public string Ip { get; set; } = "192.168.1.10"; public int Port { get; set; } = 502; public byte UnitId { get; set; } = 1; public void Connect() { _tcp = new TcpClient(); // 注意：必须设置超时，否则PLC没响应时Read会一直阻塞 _tcp.ReceiveTimeout = 3000; _tcp.SendTimeout = 3000; _tcp.Connect(Ip, Port); _stream = _tcp.GetStream(); } private byte[] ReadExactly(int count) { byte[] buffer = new byte[count]; int offset = 0; while (offset < count) { int read = _stream.Read(buffer, offset, count - offset); if (read == 0) throw new IOException("连接被PLC关闭"); offset += read; } return buffer; } private byte[] BuildFrame(byte functionCode, byte[] pdu) { int len = 1 + 1 + pdu.Length; // UnitID + 功能码 + PDU byte[] frame = new byte[6 + len]; _transactionId++; frame[0] = (byte)(_transactionId >> 8); frame[1] = (byte)_transactionId; frame[2] = 0; frame[3] = 0; // 协议ID固定0 frame[4] = (byte)(len >> 8); frame[5] = (byte)len; frame[6] = UnitId; frame[7] = functionCode; Array.Copy(pdu, 0, frame, 8, pdu.Length); return frame; } private void ValidatePrefix(byte[] prefix) { int responseId = (prefix[0] << 8) | prefix[1]; if (responseId != _transactionId) throw new InvalidDataException($"事务ID不匹配: 请求{_transactionId} 响应{responseId}"); // prefix[7]是功能码，带了最高位就是异常响应 if ((prefix[7] & 0x80) != 0) throw new IOException($"PLC返回异常码: 0x{prefix[7]:X2}"); } public ushort[] ReadHoldingRegisters(ushort startAddress, ushort quantity) { byte[] pdu = new byte[4]; pdu[0] = (byte)(startAddress >> 8); pdu[1] = (byte)startAddress; pdu[2] = (byte)(quantity >> 8); pdu[3] = (byte)quantity; byte[] req = BuildFrame(0x03, pdu); _stream.Write(req, 0, req.Length); byte[] prefix = ReadExactly(8); // 头6 + UnitID + 功能码 ValidatePrefix(prefix); int byteCount = ReadExactly(1)[0]; byte[] data = ReadExactly(byteCount); ushort[] values = new ushort[quantity]; for (int i = 0; i < quantity; i++) { // Modbus是大端，手工拼回无符号短整型 values[i] = (ushort)((data[i * 2] << 8) | data[i * 2 + 1]); } return values; } public void Dispose() { _stream?.Dispose(); _tcp?.Dispose(); } }这段代码里最关键的是ReadExactly。TCP 是流协议，一次Read不一定返回完整报文，可能半包也可能粘包。循环读到指定长度，才不会出现「报文没读完就当响应解析」的问题。事务 ID 校验同样重要，请求和响应必须匹配，否则说明通信链路里报文错位了。超时设置建议不低于 3000 毫秒，PLC 在大数据量响应时偶尔会慢，太短会误判故障。
3.3 写寄存器：0x06 和 0x10 两条路径
写单个寄存器用功能码 0x06，适合启停信号、模式切换；批量写参数用 0x10，一次可以下发多个寄存器值，效率更高。批量写请求的数据区结构是：起始地址 2 字节、数量 2 字节、字节数 1 字节、寄存器数据按大端排列。
public void WriteSingleRegister(ushort startAddress, ushort value) { byte[] pdu = new byte[4]; pdu[0] = (byte)(startAddress >> 8); pdu[1] = (byte)startAddress; pdu[2] = (byte)(value >> 8); pdu[3] = (byte)value; byte[] req = BuildFrame(0x06, pdu); _stream.Write(req, 0, req.Length); byte[] prefix = ReadExactly(8); ValidatePrefix(prefix); // 0x06响应会重复请求PDU，这里可读可不读，但最好读完保持流干净 ReadExactly(4); } public void WriteMultipleRegisters(ushort startAddress, ushort[] values) { int byteCount = values.Length * 2; byte[] pdu = new byte[5 + byteCount]; pdu[0] = (byte)(startAddress >> 8); pdu[1] = (byte)startAddress; pdu[2] = (byte)(values.Length >> 8); pdu[3] = (byte)values.Length; pdu[4] = (byte)byteCount; for (int i = 0; i < values.Length; i++) { pdu[5 + i * 2] = (byte)(values[i] >> 8); pdu[5 + i * 2 + 1] = (byte)values[i]; } byte[] req = BuildFrame(0x10, pdu); _stream.Write(req, 0, req.Length); byte[] prefix = ReadExactly(8); ValidatePrefix(prefix); ReadExactly(4); // 起始地址2 + 数量2 }0x06 的响应会把请求里的地址和值再原样返回一次，所以 Send 完之后必须把这次响应读完，否则下一次ReadHoldingRegisters会读到旧数据。0x10 的响应只返回起始地址和数量，不返回具体值。两个方法写完都要求把尾部读完，保持流同步，这是很多人忽略的细节。
3.4 控制台调用：用点表地址验证通信链路
static void Main() { var client = new ModbusTcpClient { Ip = "192.168.1.10", UnitId = 1 }; client.Connect(); // 读取D100开始的8个字，PDU地址=100=0x0064 var regs = client.ReadHoldingRegisters(0x0064, 8); for (int i = 0; i < regs.Length; i++) { Console.WriteLine($"D{100 + i} = {regs[i]}"); } // 写D100为1234 client.WriteSingleRegister(0x0064, 1234); }注意调用时传的是0x0064，不是 PLC 组态里显示的400101。如果示例返回的值全为 0，先确认 PLC 侧对应寄存器地址里真的有数据，用 PLC 软件在线监控看一眼。控制台输出正常说明链路是通的，接下来再去接界面、接数据库。
4. 常见问题排查：示例翻车的四个高频点位
4.1 网络层排查：连不上、间隔断流
现象：Connect()成功，但第一次读数据就抛超时异常；或者程序跑几分钟后通信断开，重启又恢复。
原因：多数情况是 Socket 没设超时，PLC 响应稍慢，客户端永远卡在Read上。另一类是 PLC 侧 Modbus TCP Server 没启用，或者端口 502 被其他软件占用。间隔断流则一般是上位机没有按长连接管理，每次请求都新建连接，把 PLC 的并发连接数打满了。
解决：TcpClient一定要设置ReceiveTimeout和SendTimeout；生产环境一个站维持一个长连接，不要频繁断开重连。现场先用抓包工具确认 TCP 三次握手是否完成，再检查 PLC 侧服务使能状态。端口被占用的情况，在 PLC 组态软件里改一个备用端口，客户端同步改就行。
4.2 数据层排查：读到乱码先查字节序
现象：读回寄存器值后，用BitConverter.ToUInt16转换，得到的结果和 PLC 监控面板上显示的差很多，比如面板显示 100，程序读到 25600。
原因：C# 的BitConverter在小端架构上按低字节在前解析，而 Modbus 报文是大端。收到0x00 0x64，小端解析会变成0x64 0x00，也就是 25600。这是示例里最典型的「代码看着没问题，结果全错」的场景。
解决：读寄存器时不要用BitConverter，改成手动拼接：(ushort)((data[i * 2] << 8) | data[i * 2 + 1])。如果数据区是 32 位浮点数，还要注意字序问题，有的 PLC 高字在前，有的低字在前，先用模拟器写入一个已知浮点数，读回来对比字节顺序就能确认。
4.3 报文层排查：寄存器数量越界
现象：读连续寄存器超过某个数量后，PLC 返回异常码 0x02 或 0x03，或者返回的数据从中间某段开始全为 0。
原因：Modbus 协议单次读保持寄存器上限是 125 个，读线圈上限是 1968 个。即使没超过上限，如果 PLC 地址区有保留段未映射，也会返回异常。很多工程师把整个数据区从 0 一直读到 65535，一次请求就把 PLC 打回异常。
解决：每次读取不超过 120 个寄存器，给协议余量。不确定地址段是否连续时，分段读，每段独立捕获异常。返回 0x02 表示地址越界，0x03 表示数据量非法，这两类错误码在自我排查时就已经能定位问题方向。
4.4 PLC 侧排查：点表地址和 PDU 地址差 1
现象：读400101传地址时故意直接填400101，结果数据错位，甚至报地址非法；改成100后又能读了。
原因：PLC 组态软件里显示的是 1 基地址，报文 PDU 从 0 开始，两者差 1。示例代码里读D100用的是0x0064，也就是 100，而不是400101。
解决：统一用 PDU 0 基地址传参，在 PLC 侧用「显示地址减区基准地址」换算。写代码前在组态软件里先查清楚 D 区基准是 400001 还是 400001 附近的其它偏移，每个固件版本可能有差异。这个换算规则在示例代码注释里写清楚，能省掉后面接手同事的大量排查时间。
5. 验证与进阶：没有汇川 PLC 时先把 Demo 跑通再上产线
5.1 用 Modbus TCP 从站模拟器做离线验证
手头没有 PLC 的时候，可以用任意一款 Modbus TCP 从站模拟器先跑通这套 C# 代码。模拟器监听本机或局域网 IP 的 502 端口，把模拟器的寄存器区填入一组已知数值，比如地址 100 填 1234、101 填 5678，然后让示例程序去连模拟器的 IP。两端在同一台电脑时，IP 填127.0.0.1也能跑。
这一步非常值得做。它能在完全没有硬件的情况下，验证报文的字节序、地址偏移、超时机制是否正确。等到了现场再接真实 PLC，只需要改 IP 和站号。我习惯把模拟器里填的测试值和程序读回的值做成一张核对表，每个寄存器地址、期望值、实际值列出来，真机调试时直接对照。
5.2 轮询引擎与断线重连：示例到产线的最后一步
示例里的同步读写适合功能验证，长时间跑在产线上还需要一层轮询和重连。下面是一个最小可用的轮询骨架：
CancellationTokenSource _cts = new(); Task.Run(() => PollLoop(_cts.Token)); async Task PollLoop(CancellationToken ct) { while (!ct.IsCancellationRequested) { try { using var client = new ModbusTcpClient { Ip = "192.168.1.10" }; client.Connect(); while (true) { ct.ThrowIfCancellationRequested(); var regs = client.ReadHoldingRegisters(0x0064, 32); OnDataReceived(regs); await Task.Delay(300, ct); } } catch (Exception ex) { // 断线后等1秒自动重连，避免高频重试打爆PLC连接数 await Task.Delay(1000, ct); } } }内层while负责持续读数据，读不到就抛异常落到外层catch，等待 1 秒后重新Connect()。这个结构虽然简单，但避免了两类常见问题：一是断线后立即重连导致的重试风暴，二是 PLC 重启后客户端自动恢复。轮询间隔根据工艺要求调整，一般不低于 200 毫秒，太快的轮询会把 PLC 通信任务占满，反而影响设备本身的控制逻辑。
有次我在某现场调试一套 32 个工位的数据采集，程序跑起来整体数值都正常，唯独每隔几分钟凭空多出几条乱码。排查了半天，最后发现是上一个版本的通信类没做防拆包处理，响应报文被截断后错误地按新报文解析。从那以后我每次集成前都在模拟器上强制跑一遍完整链路，确认字节序、地址偏移、超时三项参数固定了才上真机。希望帮到你，这套 C# 与汇川 PLC 通信示例值得你照着复现一次，踩过一遍坑比读十遍文档都管用。
本文还有配套的精品资源，点击获取
