简介这是一份面向C#开发者的汇川PLC通信示例工程覆盖Modbus TCP协议调用、Socket网络编程、寄存器/线圈读写、异常处理与界面绑定等关键环节可用于工业自动化上位机开发、设备数据采集和协议对接。压缩包共624个文件包含C#及C源码、Visual Studio工程配置、编译后的exe/dll、调试符号pdb以及文档说明等整体约214.54MB既可直接运行演示也能参考源码进行二次开发。目前已有580人学习下载。示例中完整提供了Modbus消息构造与解析、汇川PLC地址映射配置、实时数据刷新界面等实现并附多种语言版本便于对照可帮助开发者快速搭建稳定可靠的PLC通信模块、理解主从通信流程显著降低从零开发的试错成本。1. 写给谁的项目C#上位机直连汇川PLC产线调试台上最让人头疼的事莫过于上位机软件写好了却死活读不到PLC里的数据。某次去现场支持设备供应商扔过来一台汇川PLC说“你们上位机自己想办法连”我翻遍手册发现对方连个现成的通信Demo都没有只能对照Modbus协议一步步把报文抠出来。这个项目就是一套C#与汇川PLC通信的完整示例覆盖了TCP连接、报文组包、数据读写、异常重连这几条最核心的链路。适合正在做上位机开发、MES数据采集、设备监控软件的朋友尤其是第一次接触汇川PLC、翻协议文档翻到头疼的开发者。拿到手不是看概念是能直接照着把通信跑通。2. 技术选型与整体架构Modbus TCP协议、分层设计、一个请求的完整链路2.1 为什么选Modbus TCP汇川PLC的网口通信路径汇川PLC不同系列支持的通信方式不太一样比如AM系列和H系列基本都带以太网口往上走既可以走厂商私有协议也可以走标准的Modbus TCP。这个示例选的是Modbus TCP原因很朴素协议文档公开、报文结构简单、C#里用Socket就能实现不依赖任何厂商SDK。相比之下走厂商私有协议虽然功能更全但文档不一定拿得到调试工具也得用厂家的对二次开发并不友好。Modbus TCP是标准的请求-响应模式客户端发请求帧服务端回响应帧。报文核心是MBAP报文头加PDUMBAP头里包含事务标识符、协议标识符、长度和单元标识符PDU里包含功能码和数据。实际操作中你会发现多数情况下只需要关心事务标识符、功能码和寄存器地址这三件事。这里要澄清一个常见误区很多人以为连PLC必须装驱动或者厂商提供的通信库其实走标准Modbus TCP的话一个TcpClient就够了。汇川PLC作为Modbus TCP服务端监听502端口上位机作为客户端主动连接。当然前提是PLC侧启用了Modbus TCP功能并且在参数里配置好了IP地址和端口这部分在第4章会细说。2.2 项目目录结构从解决方案到核心类这个示例采用的是经典的简单分层一个控制台程序加一个通信类库没有引入重量级框架。结构如下PlcModbusDemo/ ├── PlcModbusDemo.sln ├── PlcModbus.Core/ # 通信核心类库 │ ├── ModbusTcpClient.cs # 报文组包、发送、接收、解析 │ ├── ModbusDataConverter.cs # 寄存器值到C#类型的转换 │ ├── PlcConnectionOptions.cs # 连接参数模型 │ └── PlcException.cs # 自定义异常 ├── PlcModbus.Console/ # 控制台示例程序 │ ├── Program.cs # 演示调用入口 │ ├── appsettings.json # PLC地址、端口、超时配置 │ └── PlcModbus.Console.csproj └── README.md # 使用说明与协议参考核心是ModbusTcpClient.cs它负责所有与PLC的网络交互ModbusDataConverter.cs承担字节序转换和数据类型换算PlcConnectionOptions.cs把IP、端口、超时时间收敛成一个强类型配置对象。控制台项目只做一件事读取配置调用核心类库完成任务。这样一个拆分方式的好处是后边你把控制台换成WinForm、WPF或者Web API只需要换表现层通信层完全不用动。我一般做这类采集项目时都这么分避免后期界面和逻辑耦合在一起改起来头疼。2.3 一个读请求的完整链路读操作是最高频的通信场景完整的链路一定要掰清楚第一段是建立连接。ModbusTcpClient内部维护一个TcpClient实例调用ConnectAsync方法时传入PLC的IP和端口建立TCP连接。连接建立后客户端需要维护这个连接而不是每次读写都重新握手正因如此连接管理是性能的关键。第二段是组包。读保持寄存器时功能码是0x03报文帧里事务标识符每次请求递增协议标识符固定为0x0000长度字段表示后续字节数单元标识符一般填0x01或0xFF取决于PLC侧配置。数据部分要指定起始地址和读取数量。第三段是发送与接收。通过NetworkStream写入报文等待响应。这里的关键是超时控制——PLC在极端情况下可能不响应不能让程序无限等下去。一般用CancellationTokenSource加Task.WhenAny来做超时中断。第四段是解析。响应帧前六个字节和请求帧类似从第七个字节开始是数据。读保持寄存器的响应里数据区每个寄存器占两个字节大端序排列把字节拼接成ushort再按业务需求转换即可。这些步骤里最容易出问题的点在组包和解析尤其是长度字段算错、单元标识符对不上、超时时间给得太短这三个坑会在第5章展开。3. 核心模块代码拆解C# Modbus TCP客户端的实现细节3.1 报文组包构建Modbus TCP帧组包这个环节不复杂但必须严谨因为PLC侧是严格按字节解析的。一个读保持寄存器的请求帧我用下面这个方法来构建// PlcModbus.Core/ModbusTcpClient.cs private byte[] BuildReadRequest(byte unitId, ushort startAddress, ushort quantity, byte functionCode) { // MBAP头事务标识符(2字节) 协议标识符(2字节) 长度(2字节) 单元标识符(1字节) // PDU功能码(1字节) 起始地址(2字节) 寄存器数量(2字节) byte[] buffer new byte[12]; // 事务标识符每次请求递增用于匹配响应 byte[] transactionId BitConverter.GetBytes(_transactionId); // Modbus TCP使用大端序但BitConverter在小端环境返回的是小端序需要反转 if (BitConverter.IsLittleEndian) { Array.Reverse(transactionId); } Buffer.BlockCopy(transactionId, 0, buffer, 0, 2); // 协议标识符固定为0x0000表示Modbus协议 buffer[2] 0x00; buffer[3] 0x00; // 长度字段 单元标识符(1) 功能码(1) 起始地址(2) 数量(2) 6 buffer[4] 0x00; buffer[5] 0x06; // 单元标识符默认0x01需与PLC侧保持一致 buffer[6] unitId; // 功能码0x03读保持寄存器0x06写单个寄存器 buffer[7] functionCode; // 起始地址和数量同样转大端序 byte[] addr BitConverter.GetBytes(startAddress); byte[] qty BitConverter.GetBytes(quantity); if (BitConverter.IsLittleEndian) { Array.Reverse(addr); Array.Reverse(qty); } Buffer.BlockCopy(addr, 0, buffer, 8, 2); Buffer.BlockCopy(qty, 0, buffer, 10, 2); return buffer; }这里的核心是字节序处理。BitConverter.GetBytes在当前平台上返回小端字节序而Modbus TCP要求大端序所以必须做反转。事务标识符的作用是匹配请求和响应——如果程序里并发发送多个请求响应返回时可以依赖事务标识符找到对应的请求。参数说明unitId对应PLC侧Modbus从站地址多台设备并联时用这个区分startAddress是寄存器起始地址寄存器编号从0开始quantity是一次读取的寄存器个数。注意Modbus协议里寄存器编号和实际地址差1比如PLC手册里写“%MW100”在报文里填的起始地址通常是99这个偏移我一开始就吃过亏。3.2 异步读写TcpClient、CancellationToken、超时控制通信不能是同步阻塞的否则PLC响应慢的时候整个UI线程会卡死。这个示例的读写方法全部走异步配合CancellationTokenSource做超时控制。核心的读方法如下// PlcModbus.Core/ModbusTcpClient.cs public async Taskbyte[] ReadHoldingRegistersAsync( byte unitId, ushort startAddress, ushort quantity, CancellationToken cancellationToken default) { // 检查连接状态未连接时先建立连接 if (_tcpClient null || !_tcpClient.Connected) { await ConnectAsync(cancellationToken); } // 构建读保持寄存器请求帧 byte[] request BuildReadRequest(unitId, startAddress, quantity, 0x03); var stream _tcpClient.GetStream(); // 发送请求 await stream.WriteAsync(request, cancellationToken); await stream.FlushAsync(cancellationToken); // 响应头固定9个字节MBAP头(7) 功能码(1) 字节数(1) byte[] responseHeader await ReadExactlyAsync(stream, 9, cancellationToken); // 校验事务标识符防止响应错配 if (responseHeader[0] ! request[0] || responseHeader[1] ! request[1]) { throw new PlcException(事务标识符不匹配响应与请求不对应); } // 异常响应功能码最高位为1时表示错误 if ((responseHeader[7] 0x80) ! 0) { throw new PlcException($PLC返回异常响应错误码: 0x{responseHeader[8]:X2}); } // 数据区长度 字节数每个寄存器占2字节 int dataLength responseHeader[8]; byte[] data await ReadExactlyAsync(stream, dataLength, cancellationToken); return data; }这段代码里有两个细节值得留意。一是ReadExactlyAsync方法它要确保读取到指定长度的字节才算完成因为NetworkStream.ReadAsync一次不一定读满缓冲区需要循环读取。二是超时控制调用方传入的CancellationToken可以由CancellationTokenSource.CancelAfter触发实现“超过500毫秒就放弃等待”。连接管理方面我一般会在ConnectAsync里做一次TCP连接超时保护默认3秒连不上就抛异常这个值可以通过PlcConnectionOptions配置。PLC的响应时间通常在几十毫秒所以读操作超时设置200~500毫秒比较合理连接超时要放长一些因为现场网络环境不稳定交换机端口协商也需要时间。3.3 数据解析字节序、偏移量、寄存器值转换PLC寄存器的原始数据是16位无符号整数但业务数据可能是浮点数、32位整数、布尔量或者字符串所以需要一组转换工具类。这个示例里我把常见转换都封装在ModbusDataConverter中// PlcModbus.Core/ModbusDataConverter.cs public static class ModbusDataConverter { // 两个连续寄存器转32位浮点数32位浮点数在汇川PLC中占2个寄存器 public static float ToFloat(byte[] data, int offset) { // 默认大端序高字节在前 ushort high (ushort)((data[offset] 8) | data[offset 1]); ushort low (ushort)((data[offset 2] 8) | data[offset 3]); // 转换为32位二进制高16位寄存器在前 uint rawValue (uint)((high 16) | low); return BitConverter.ToSingle(BitConverter.GetBytes(rawValue), 0); } // 两个连续寄存器转32位有符号整数 public static int ToInt32(byte[] data, int offset) { ushort high (ushort)((data[offset] 8) | data[offset 1]); ushort low (ushort)((data[offset 2] 8) | data[offset 3]); return (int)((high 16) | low); } // 单个寄存器转16位无符号整数 public static ushort ToUInt16(byte[] data, int offset) { return (ushort)((data[offset] 8) | data[offset 1]); } }汇川PLC的32位数据有两种排列模式一种是大端序高字在前一种是小端序低字在前具体取决于PLC内的数据存储格式设置。这个示例默认采用大端序如果你的项目发现读出来的浮点数完全不对优先怀疑寄存器顺序反了把high和low对调一下再验证。参数说明offset是字节偏移量不是寄存器偏移量。因为每个寄存器占2字节所以第n个寄存器对应的字节偏移是n * 2。调用方拿到响应数据后如果用寄存器索引去访问字节数组极容易越界或取到错位数据。另外布尔量的读取方式不太一样。Modbus读线圈用功能码0x01返回的数据是按位压缩的一个字节表示8个线圈状态。如果业务需求是读单个开关量用读保持寄存器的方式去读会失败因为地址空间和功能码都不对。这块是很多人容易混淆的地方。4. 运行与验证从空目录到连上真实PLC4.1 创建工程与依赖在Visual Studio里新建解决方案添加上述两个项目。目标框架建议选.NET 6或.NET 8因为NetworkStream.ReadAsync和WriteAsync的CancellationToken重载在.NET 6里已经很好用了不需要额外引包。PlcModbusDemo.sln解决方案创建完成后给控制台项目添加对核心类库的项目引用dotnet add PlcModbus.Console/PlcModbus.Console.csproj reference PlcModbus.Core/PlcModbus.Core.csproj控制台项目里引入命名空间后就能用了// PlcModbus.Console/Program.cs using PlcModbus.Core; // 从配置文件读取连接参数 PlcConnectionOptions options new() { IpAddress 192.168.1.10, // 汇川PLC的IP地址 Port 502, // Modbus TCP默认端口 TimeoutMs 500, // 单次请求超时 ConnectTimeoutMs 3000 // TCP连接超时 }; ModbusTcpClient client new(options); try { // 读 %MW100 开始的 2 个寄存器解析为浮点数 byte[] data await client.ReadHoldingRegistersAsync(0x01, 99, 2); float value ModbusDataConverter.ToFloat(data, 0); Console.WriteLine($当前温度{value} ℃); } catch (PlcException ex) { Console.WriteLine($通信异常{ex.Message}); } finally { client.Dispose(); }这里的事务标识符、单元标识符等参数均采用默认值如果你在PLC侧改了从站地址记得同步修改unitId参数。启动方式是先编译dotnet build PlcModbusDemo.sln dotnet run --project PlcModbus.Console如果程序能正确打印出PLC里的寄存器值说明通信链路已经通了。很多第一次上手的人卡在这一步——编译不过或者运行直接崩溃多数是因为目标框架版本不对或者控制台项目误用了Main方法返回Task但没配置async入口。4.2 配置PLC侧的网络参数PLC侧不配置上位机怎么连都没用。汇川PLC的Modbus TCP配置通常在编程软件的系统参数里需要设定IP地址、子网掩码并启用Modbus TCP功能。核心参数如下配置项典型值说明IP地址192.168.1.10与上位机在同一网段子网掩码255.255.255.0默认即可端口号502Modbus TCP标准端口PLC侧一般不可改从站地址1对应报文里的单元标识符0x01寄存器起始地址%MW100对应Modbus地址99配置完成后把PLC程序下载到设备并运行先用电脑ping一下PLC的IP地址通了再跑上位机。如果ping不通检查网线连接和IP网段别急着查代码。有一点要特别说明汇川PLC的Modbus地址映射和HMI组态软件里看到的地址编号有可能不一致。比如组态软件里写“%MW100”报文里实际填的是99因为Modbus地址从0开始而汇川的%MW号从1开始。如果你发现读出来的数据一直对不上先做个地址偏移验证。4.3 联调验证读寄存器、写寄存器、监控报文联调时建议分三步走。第一步只读不写用一个已知寄存器地址读取数据验证连接和读链路第二步写单个寄存器把特定值写入某个空闲寄存器再读回来验证写链路第三步模拟真实业务连续读写多个寄存器。读链路验证通过后写一个测试方法// 写入单个保持寄存器功能码0x06 public async Task WriteSingleRegisterAsync(byte unitId, ushort address, ushort value) { byte[] request new byte[12]; // 事务标识符 byte[] transactionId BitConverter.GetBytes(_transactionId); if (BitConverter.IsLittleEndian) Array.Reverse(transactionId); Buffer.BlockCopy(transactionId, 0, request, 0, 2); // 协议标识符和长度 request[2] 0x00; request[3] 0x00; request[4] 0x00; request[5] 0x06; // 单元标识符和功能码 request[6] unitId; request[7] 0x06; // 寄存器地址 byte[] addr BitConverter.GetBytes(address); if (BitConverter.IsLittleEndian) Array.Reverse(addr); Buffer.BlockCopy(addr, 0, request, 8, 2); // 写入值 byte[] val BitConverter.GetBytes(value); if (BitConverter.IsLittleEndian) Array.Reverse(val); Buffer.BlockCopy(val, 0, request, 10, 2); var stream _tcpClient.GetStream(); await stream.WriteAsync(request, CancellationToken.None); await stream.FlushAsync(CancellationToken.None); }写完寄存器后用读请求把同一个地址的值读回来比对是否一致。这是最直接的验证手段不需要看PLC侧的程序运行状态。调试阶段我建议用Modbus Poll这类工具做双保险。因为有时候代码逻辑没问题但PLC侧的寄存器地址映射发生了变化——程序改过、设备重新上电、配置丢失都可能导致地址偏移。先用工具读通一个地址再在代码里读同一个地址两边数据一致了就能确定是你的代码问题还是PLC配置问题。5. 避坑记录汇川PLC通信中我踩过的几个坑5.1 事务标识符没递增响应对不上现象程序第一次读数据是正常的第二次开始偶发读到脏数据甚至抛异常说响应长度不对。原因事务标识符固定为0导致每次请求的报文完全一样。当PLC返回的响应在网络缓冲里没有及时读完时下一次读操作会匹配到上一次残留的响应帧。解决每次请求前让事务标识符自增并使用ReadExactlyAsync确保把响应数据读完整。从那以后我写通信代码时这个机制都是默认自带不给自己留偷懒的空间。5.2 字节序反了浮点数完全不对现象读出来的32位浮点数是一个天文数字比如预计20.5实际读出1.43E-41。原因数据排列方式与预期不符。Modbus寄存器本身是大端序但在汇川PLC中32位数据的字顺序可配置。有的设备配置成高字在前有的低字在前代码里写死了其中一种就会出错。解决先写一个已知浮点数到PLC再读回来对比确定字顺序。然后把转换方法扩展出ToFloatBigEndian和ToFloatLittleEndian两个版本运行时通过配置选择。自那以后我每次对接新设备第一件事就是用已知数据试通信而不是直接上业务数据。5.3 超时时间设得太短PLC响应稍微慢点就断现象程序跑一段时间后频繁报超时重启程序又正常过一会儿又超时。原因PLC扫描周期不固定某些复杂的控制逻辑会让PLC的响应时间突破300毫秒而超时设的是200毫秒。另外上位机系统繁忙时线程调度也可能导致响应处理被拖延。解决超时时间设置为500~1000毫秒并加入重试机制——首次超时后重试一次如果重试成功说明是瞬时抖动不必断开连接。重试依然失败再重新建立TCP连接。这个方法帮我解决了不少“通信不稳定”的伪问题很多所谓的不稳定其实是超时设置太激进。5.4 PLC上电重启后连接不自动恢复现象产线断电重启后上位机软件一直报连接失败必须人工重启软件才能恢复。原因TCP连接在PLC重启后已经失效但客户端检测不到继续往断开的连接上写数据。写入失败时如果没有触发重连逻辑连接就卡死在半开状态。解决在每次读写前检查_tcpClient.Connected一旦发现连接不可用就执行重连。另外通过心跳机制每隔几秒读一个已知寄存器如果连续三次失败就主动断开并重新连接。这个设计让采集程序的连续性有了基本保障算是能上线的底线。5.5 地址偏移寄存器编号和实际地址差1现象PLC程序里明明写的是%MW100上位机读了99和100两个寄存器数值都对不上但读101和102反而对了。原因%MW100里的100是寄存器编号从1开始计数。而Modbus TCP报文里的起始地址从0开始所以映射到报文地址是99。如果直接在报文里填100访问的实际是%MW101。解决读文档里的地址映射表确认编址方式。写代码时把“PLC寄存器编号 - 1”作为报文地址并通过离线模拟验证一遍。这个偏移问题不只是汇川有很多PLC都有同样的设计养成习惯后就不容易翻车了。6. 二次开发方向从“能通信”到“能上线”示例程序能跑通只是第一步真正放到产线上还得做几件事。这里说四个最实用的改造方向。第一个是轮询调度。示例里是一次读一个地址但产线设备往往要采集几十个变量逐个读效率太低。改成批量读把连续的寄存器地址合并成一次读取例如把%MW100到%MW120一次读完然后按偏移量解析。对于确实不连续的寄存器建立一张采集点位表用一个后台循环按优先级轮询高优先级的点位读得勤一些低优先级的可以慢一些。第二个是断线重连机制。我在第5章提过心跳和重连的思路实际落地时可以封装一个ReconnectionPolicy类内部维护连接状态、重试次数、退避时间。连续失败次数超过阈值时延长重试间隔避免PLC还没恢复就把日志刷屏。第三个是数据上送。通信层拿到寄存器数据之后结合业务场景将数据推送到数据库或者Web API这样就能支撑看板显示和报表统计了。这个环节要注意的是数据的时间戳应该由上位机生成而不是依赖PLC的内部时钟——很多PLC不保持时间重启后就回到出厂设置。第四个是配方管理。场景是设备需要根据产品型号切换参数可以在上位机维护多组配方把参数一次性写入PLC的寄存器区域。注意写入时要做二次确认先读到当前值再写新值写完再读回来校验防止通信干扰导致数据不一致。说到底通信示例最核心的永远是报文和状态管理。我后面做每个采集项目时都会强制走一遍这套流程先写死配置联调出数据再封装连接生命周期最后才做业务功能。设计上始终遵循一条原则——PLC通信这类底层模块代码里想要换设备换协议不至于推倒重来。希望这些经验能帮到你让你少走几个我走过的弯路。本文还有配套的精品资源点击获取