简介面向C#开发者和工业自动化工程师的完整示例包解决C#与汇川PLC通信中的协议对接、数据读写与界面集成问题涵盖Modbus TCP/RTU通信、网络Socket编程、异常处理和性能优化等核心知识点。压缩包214.54MB内含624个文件以Visual Studio解决方案sln、vcxproj、C#源代码cs、C工程cpp、h、可执行程序exe、动态库dll、调试符号pdb以及说明文档pdf、docx为主同时包含工程编译过程生成的中间文件便于直接运行、调试与二次开发。已有574人学习下载适合希望快速上手PLC上位机通信的初中级开发者。示例中给出Modbus API调用方法、寄存器读写流程、界面展示及排错思路并针对汇川PLC的地址映射、CRC校验和实时性优化进行了实践演示能帮助读者减少摸索时间提升实际项目中PLC通信模块的开发效率。 前阵子给一条产线做数据采集需求本身不复杂用C#和汇川PLC通信把设备状态和关键参数读出来送MES同时支持从工位下发配方。可就是这么个“不复杂”的活儿从选型到联调前前后后踩了不少坑。这篇就把这套完整的C#与汇川PLC通信示例整理出来从方案选型、PLC侧配置、协议细节到最终能跑的代码和排错经验一条龙讲清楚。适合两类人看一是电气工程师想学上位机开发二是写C#上位的程序员第一次接触汇川PLC通信照着抄基本能省下两周折腾时间。1. 通信方案选型先别急着写代码1.1 三选一Modbus TCP、OPC UA还是厂商私有协议很多人一上来就问“C#怎么和汇川PLC通信”其实这个问题应该先反着问你到底要和PLC做什么事如果只是采集数据、读写参数而且实时性要求是几十毫秒到百毫秒级别那Modbus TCP是最务实的选择。理由很直接协议全公开、报文格式简单到能对着手册自己拼字节、汇川大多数带以太网口的PLC都支持、调试工具也多出了问题抓包就能定位不需要额外授权费。OPC UA是另一个常见选项适合车间设备品牌杂、数据点上千、要做复杂数据建模的场景但它部署起来要配证书、配安全策略对于单台PLC加一个上位机这种项目来说属于杀鸡用牛刀光是把OPC服务器调通就得折腾半天。至于厂商私有协议和EtherCAT这类总线那通常是做运动控制的场景比如追剪、电子凸轮规划这种事。Modbus TCP在这种场景下只配做数据采集轴控制得上EtherCAT。所以如果你搜“汇川PLC控制EtherCAT”是为了做运动控制那我这篇讲的方向就偏了你该去查汇川专用运动控制解决方案或第三方库。我当时定的方案就是Modbus TCPPLC做从站上位机做客户端走TCP 502端口用功能码03读保持寄存器、10写多个寄存器。整套方案免费、可控、可复现。1.2 汇川PLC侧需要确认的前提条件很多人在C#代码里折腾半天结果发现连不上最后查出来PLC侧压根没配置。不同系列的汇川PLC配置入口不一样H系列比如H3U通常在AutoShop的通信参数里启用Modbus TCP从站功能设置好IP和端口AM系列比如AM401/402在InoProShop里组态通信配置指定需要开放给上位机的数据区。具体菜单名称不同版本有差异但核心思路是一致的启用Modbus TCP服务、绑定IP和端口、建立内部软元件和Modbus寄存器的映射关系。我当年踩的第一个坑就是这个。代码写完了TCP也连上了读返回的数据全为零。当时还以为是字节序问题翻来覆去排查了很久最后才发现PLC侧的Modbus映射区根本没配置上位机连到的是一块空数据区。PLC不是路由器不会自动把内部D寄存器暴露给Modbus必须在PLC程序里明确做映射。所以强烈建议写C#代码之前先用Modbus Poll这个工具连接PLC试一试。工具能读到数据说明PLC侧配置没问题然后再开始写C#。这一步能把“协议层问题”和“PLC配置问题”干净地切开能省掉大量无意义的排查时间。2. Modbus TCP核心概念把报文搞懂再写代码2.1 请求/响应报文长什么样Modbus TCP报文由两部分组成7字节的MBAP头加上功能码和数据区。和Modbus RTU不同TCP模式下没有CRC校验因为TCP协议本身已经保证数据传输的完整性。MBAP头的结构是这样的事务标识符占2字节用来匹配请求和响应。每次请求递增防止响应错乱这是必须维护的协议标识符固定0x0000长度占2字节表示从单元标识符开始到报文末尾的字节数单元标识符占1字节也就是站号一般填1。常用功能码就这几个03读保持寄存器、04读输入寄存器、01读线圈、06写单个寄存器、10写多个寄存器。采集D寄存器数据最常用03写参数最常用10。举个例子读取从地址0开始的10个寄存器请求报文一共12字节事务ID 0x0001协议ID 0x0000长度0x0006单元ID 0x01功能码0x03起始地址0x0000寄存器数量0x000A。其中的长度字段是6也就是说从单元ID开始到报文末尾一共是6个字节。响应报文的长度字段则是3加数据字节数。这里有个细节很容易忽略响应报文里功能码如果最高位被置1比如0x83说明PLC返回的是异常响应后面跟的字节是异常码。01非法功能码02非法地址03非法数据值04从站设备故障。看到这种响应基本就是请求报文里的地址或数据量超出了PLC允许的范围。2.2 数据存储与字节序坑最多的地方Modbus协议规定数据是大端字节序存储的高字节在前而C#的BitConverter默认是小端序。这两个不匹配的后果就是你读出来的ushort完全对但一拼成32位或者浮点数就全乱了。我举个具体的例子。两个连续的保持寄存器保存一个32位浮点数假设寄存器0的值是0x3F80寄存器1的值是0x0000那么组合起来应该是0x3F800000按IEEE 754标准这就是1.0f。如果C#代码里直接这么写ushort high regs[0]; ushort low regs[1]; float value (high 16) | low; // 错误这是整数移位不是浮点拼接那结果肯定是错的。正确思路是先把两个16位寄存器拼成一个32位无符号整数再用BitConverter把这个整数的内存布局解释成浮点数。代码是这么写的uint raw ((uint)high 16) | low; float value BitConverter.ToSingle(BitConverter.GetBytes(raw), 0);注意BitConverter.GetBytes(raw)拿到的字节数组是本机小端序但这没关系因为BitConverter.ToSingle同样按小端解析两次小端操作正好互相抵消最终得到的就是正确的浮点值。至于寄存器的字序问题也就是高字在前还是低字在前不同PLC厂商可能会有差异。汇川这边按Modbus标准写法能对上但如果你发现数值大小明显不对比如几百变几千万那大概率就是前后两个寄存器的顺序调换一下的问题。这个非常隐蔽不拿实际物理量去对比根本发现不了。3. C#实现封装一个能用的Modbus TCP客户端3.1 连接管理与超时设置TcpClient连接PLC本身不复杂但有几个参数必须设置对。NoDelay要置为true禁用Nagle算法否则小报文会被缓冲合并造成几十毫秒的延迟SendTimeout和ReceiveTimeout要设置避免PLC掉线后Read永久阻塞。连接这块基本就是这样的_client new TcpClient(); _client.NoDelay true; _client.SendTimeout 1000; _client.ReceiveTimeout 1000; _client.Connect(ipAddress, 502);超时时间需要根据现场情况调整。我一般先用1000毫秒如果PLC扫描周期长或者网络环境差再放宽到2000到3000毫秒。太短容易误报太长影响断线后的重连效率。实际项目里有个更关键的问题不要反复创建和断开TcpClient。每次new TcpClient再Connect会走完整的TCP三次握手断开时还会留下TIME_WAIT状态。如果你每次读数据都断开重连PLC侧会积累大量半关闭连接最终导致连接失败。这也是很多人在搜索“C# TCP连接数量”时遇到问题的根源。正确的做法是保持一个长连接由上位机定时轮询只有检测到连接异常时才重连。断线重连的逻辑也不复杂每次读写操作放在try-catch里捕获SocketException或IOException就触发重连。重连要有间隔比如失败后等待2秒再试防止高频重试雪上加霜。PLC毕竟是工业设备不是高并发服务器经不起客户端每秒几十次的重连风暴。3.2 报文构造、发送读取与数值转换报文构造我已经封装好了直接给一个完整的示例。首先是构造读保持寄存器的请求private byte[] BuildReadRequest(ushort startAddress, ushort count) { _transactionId; byte[] buffer new byte[12]; buffer[0] (byte)(_transactionId 8); buffer[1] (byte)_transactionId; buffer[2] 0x00; buffer[3] 0x00; buffer[4] 0x00; buffer[5] 0x06; // 长度单元ID(1) 功能码(1) 地址(2) 数量(2) buffer[6] 0x01; // 单元ID对应PLC端配置的站号 buffer[7] 0x03; // 功能码读保持寄存器 buffer[8] (byte)(startAddress 8); buffer[9] (byte)startAddress; buffer[10] (byte)(count 8); buffer[11] (byte)count; return buffer; }读响应的时候有个关键细节NetworkStream的Read方法不保证一次把数据读完必须自己写一个ReadExact函数循环读取直到读满指定字节数。否则第一次读到半个报文第二次又读到昨天剩下的数据整个通信就全乱了。private byte[] ReadExact(NetworkStream stream, int length) { byte[] buffer new byte[length]; int offset 0; while (offset length) { int read stream.Read(buffer, offset, length - offset); if (read 0) throw new IOException(连接已关闭); offset read; } return buffer; }响应解析的第一步是先读MBAP头里的长度字段根据它确定后续要读多少字节。完整过程是先读6字节头部事务ID2字节、协议ID2字节、长度2字节从长度字段算出剩余字节数再继续读完剩余部分。这样能确保每次读取的都是一个完整报文不会出现粘包半包问题。private ushort[] ReadHoldingRegisters(ushort startAddress, ushort count) { _lock.Enter(); try { if (_client null || !_client.Connected) throw new SocketException(); NetworkStream stream _client.GetStream(); byte[] request BuildReadRequest(startAddress, count); stream.Write(request, 0, request.Length); byte[] head ReadExact(stream, 6); int length (head[4] 8) | head[5]; byte[] body ReadExact(stream, length); // 检查功能码异常 if (body[0] 0x83) throw new Exception($读寄存器异常异常码0x{body[1]:X2}); int byteCount body[1]; int valueCount byteCount / 2; ushort[] values new ushort[valueCount]; for (int i 0; i valueCount; i) { values[i] (ushort)((body[2 i * 2] 8) | body[3 i * 2]); } return values; } finally { _lock.Exit(); } }注意这个_lock。它是一个业务锁保证同一时间只有一个线程在调用Read/Write。因为轮询线程和写参数的操作线程可能会同时访问NetworkStream如果不加锁两个请求交错发送响应就错乱了。在此基础上读取浮点数就是水到渠成的事public float ReadFloat(ushort startAddress) { ushort[] regs ReadHoldingRegisters(startAddress, 2); uint raw ((uint)regs[0] 16) | regs[1]; return BitConverter.ToSingle(BitConverter.GetBytes(raw), 0); }写寄存器的逻辑对称构造写多个寄存器的请求功能码10即可。写单个寄存器用06就够了但如果要连续写多个配方参数用10更高效。3.3 轮询逻辑与UI刷新别在界面线程里干网络活C#上位机读PLC数据最常见的错误是把网络操作直接放在UI按钮点击事件或Timer事件里。这会导致界面卡死一旦PLC响应慢或者网络断开Form就失去响应。正确的做法是后台轮询加UI回调。轮询部分用后台线程或Task读取到的数据通过Control.Invoke或者BeginInvoke回传到界面线程。我实际项目里是这么组织的一个后台轮询服务启动一个while循环用CancellationToken控制退出每次循环读一次PLC数据然后在finally块里Thread.Sleep到下一个周期。轮询周期需要根据实际需求权衡。PLC扫描周期如果是10毫秒上位机没必要5毫秒疯狂读。寄存器读报文本身很短但频率过高会挤占PLC的通信处理时间PLC同时要服务触摸屏和MES系统过高的轮询频率会导致PLC通信负载超标。我实测下来50到100毫秒的周期很稳妥既不影响实时性也不会压垮PLC。4. 真实项目里踩过的坑与排查技巧4.1 常见问题速查表现象可能原因排查方向Connect直接超时IP/端口不对、跨网段、防火墙拦截、PLC从站服务未启用先ping再telnet IP 502最后抓包确认连接成功但读响应超时单元ID不对、PLC映射区配置错误、报文长度字段写错接上Modbus Poll逐项对照测试读回来全是0PLC侧映射区没配置或配置错地址先读单个寄存器和PLC在线监控值对表数据有值但明显不对字节序错、32位数据字序反了、数据类型填错先读原始ushort再人工换算验证偶发通信中断多线程同时读写Stream、轮询过快、PLC负载太高加锁调大轮询周期看Wireshark异常码返回02/03地址越界、寄存器数量超范围核对PLC手册数据区范围4.2 几个容易忽略的细节事务ID必须递增。有些PLC不校验事务ID导致很多示例代码里事务ID随便填也能跑通。但你换一个PLC型号或者PLC固件版本升级后可能就开始严格校验到时候再排查就很痛苦。所以从一开始就要规范递增养成好习惯。地址偏移是所有做Modbus的人都要过一遍的坎。有些厂商的说明书写的是保持寄存器地址从40001开始但在Modbus报文里起始地址填的是0。这个“1”的偏移在读单个寄存器时不容易发现但一旦读连续多寄存器数值就会整体错位。解决方法是明确区分“文档地址”和“协议地址”在代码注释里直接写明当前用的地址对应PLC文档的哪个区域。排查通信问题有个技巧先把Wireshark装好过滤器写tcp.port 502把报文一抓问题往往就清楚了。对比你的请求报文和返回报文是地址错、长度错、还是功能码错一目了然。我见过很多人代码翻来覆去改了一天最后发现是PLC配置里站号和代码里单元ID不一致这类问题不抓包根本看不出来。顺带提一句如果现场还有视觉系统比如海康VisionMaster要跟上位机联动不用把视觉指令也走Modbus TCP。视觉控制器一般有自己的TCP指令协议上位机按它的协议直接发Socket指令就行。Modbus TCP只负责PLC数据交互各司其职别硬把它们绑在一起。另外我个人的一个小习惯通信状态除了看TCP连接是否正常还在PLC里放一个心跳寄存器让PLC程序每秒把这个寄存器的值翻转一次。上位机轮询时如果发现心跳值长时间不变即使TCP连接还在也说明PLC侧程序可能已经卡死或停机。这个比单纯依赖TCP连接的Connected属性靠谱得多因为TCP断线检测本来就有滞后性而生产环境里PLC程序跑飞但网络层正常的情况并不少见。这套模块做好以后后续扩展就方便多了。需要新增变量就在PLC映射区加地址C#端用统一的读寄存器方法就能覆盖。从单台PLC到多台PLC也不过是循环连接多几个客户端对象的事。基础打牢剩下的都是体力活。本文还有配套的精品资源点击获取