MODBUS TCP与C#汇川PLC通讯：从报文封装到避坑实践

简介面向工业自动化与上位机开发人员的 MODBUS TCP 通信 C# 源码基于 C# 编写并针对汇川 PLC 完成实际通信测试属于可直接运行的实用程序。方案从串口 Modbus 延伸至 Modbus TCP解释了两者在传输层上的差异包含连接建立、报文构造、寄存器读写与响应解析等核心逻辑既能帮助新手理解工业以太网通信原理也为有经验开发者提供可复用的功能模块。压缩包共 38 个文件以 cs 源码为主配以 config/ini 配置、exe 可执行程序、resx/resources 资源文件、PDB 调试符号及 docx 说明文档包体仅 322KB结构清晰方便对照学习与二次修改。已有 2049 人浏览学习打开工程即可看到启动入口、主窗体、应用配置和指示灯控制等核心模块界面示例加上后台通信流程可以直观追踪请求发送与反馈解析过程最终掌握 Modbus TCP 在汇川 PLC 通信中的落地写法。对准备搭建上位机与 PLC 通信环境的人员这份源码可作为直接入手的学习样板。1. 这套MODBUS TCP与C#汇川PLC通讯源码解决的不只是“能通”工控老马出品的这套MODBUS TCP C#汇川PLC通讯源码把从站扫描、读写寄存器、事务ID管理、超时重试这些在现场真正要命的事都封装好了。做上位机最怕的不是协议读不懂而是网上找的Demo只能点个按钮读一个地址一接MES或者产量统计系统就废掉重写一遍又得折腾一两周。这套代码覆盖汇川H系列、AM系列和CODESYS平台的H5U与C#上位机的数据互通读线圈、读保持寄存器、写单个、写多个这些日常操作用例都在里面。适合的读者很明确手上有汇川PLC需要写C#上位机做产线数据采集、设备参数下发或者触摸屏与上位机并存的场景不想从裸Socket开始拼报文想拿一套能直接落地的代码改改就用。我把它拆了一遍功能上确实够用但要跑得稳寄存器映射和字节序这两个点得先想清楚下面按我的思路展开。2. 协议选型与汇川PLC的支持范围为什么MODBUS TCP比RTU省心2.1 总线型与网络型的取舍现场走线和设备数量决定一切MODBUS RTU走串口RS485菊花链接法对布线顺序、终端电阻、地电位差都敏感车间里变频器一启动通讯偶发乱码是家常便饭。MODBUS TCP把链路交给以太网交换机隔离了电气干扰物理层的问题一下子少了大半。这是选TCP的首要原因不是因为它“高级”而是因为它省掉了串口现场那堆玄学问题。另一个决定因素是设备数量。一条RS485总线虽然理论上能挂32个从站但实际超过10台时轮询周期就会拉长某台设备掉线还会拖慢整条链路。MODBUS TCP一台设备一个IP上位机用多线程并发轮询6台PLC同时采集每个站独立超时互不影响。对需要对接MES或者SCADA的产线TCP这种“并联”结构明显更合理。MODBUS TCP和RTU的报文差异也值得说清楚很多人第一次抓包会愣住。对比项MODBUS RTUMODBUS TCP物理层RS232/RS485以太网校验方式CRC16必须自己算去掉CRC16交给TCP/IP层报文头地址功能码数据CRCMBAP头事务ID协议ID长度单元ID功能码数据最大从站数理论32实际10台以内稳妥取决于IP规划几乎不受限轮询方式串行一台超时拖累全局多线程并行单站独立超时现场布线手拉手菊花链终端电阻必须接交换机星型布线走线随意很多从RTU转TCP后原来计算CRC16那段代码可以直接删掉但代价是协议头从1个字节地址变成了7个字节的MBAP头事务ID的维护成了新的坑。后面第3章会详细讲事务ID这是TCP版和串口版最大的不同。2.2 汇川不同系列对MODBUS TCP的支持从站配置先查明白汇川PLC对MODBUS TCP的支持分三个梯队。老款H1U、H2U系列本体没有以太网口要加扩展模块才支持具体映射关系看扩展模块手册。AM系列和MC系列本身带以太网支持MODBUS TCP从站但需要在轴控参数或者通讯配置里打开“MODBUS TCP服务器”开关默认不一定开启。H5U系列是CODESYS平台在“Modbus TCP”从站配置界面里拖一个从站设备绑定到以太网口就行地址映射非常直观。不管哪个系列动手写C#之前先做一件事在PLC编程软件里找到MODBUS TCP从站配置页查看当前固件版本下的寄存器映射表。部分版本有个“地址偏移”选项勾选后MODBUS地址会整体加1网上很多“明明读了地址100却返回0”的求助帖最后都是这个偏移没对上的问题。还有端口占用要注意。PLC的以太网口如果同时给触摸屏、编程软件、上位机用502端口是MODBUS TCP默认端口有的触摸屏占用了502PLC就无法再作为从站响应MODBUS请求。现场排查时用一条命令行确认连通性ping 192.168.0.10提示如果ping通了但上位机连不上先telnet 192.168.0.10 502确认端口是开放状态。端口不通基本就是PLC侧从站服务没启动或端口被占用别急着查代码。3. 报文封装与读写实现功能码、事务ID和超时重试三件套3.1 读保持寄存器12字节请求帧的构造与响应解析读保持寄存器是数据采集用得最频繁的操作功能码0x03。MODBUS TCP请求帧固定12字节代码里可以按位置直接把字节填好比用MemoryStream再ToArray更直观也不会引入额外的内存分配。public byte[] BuildReadRequest(byte unitId, ushort startAddr, ushort count) { // 事务ID每帧递增从站响应时会原样带回客户端靠它匹配请求和响应 _transactionId; byte[] frame new byte[12]; frame[0] (byte)(_transactionId 8); // 事务ID高字节 frame[1] (byte)(_transactionId 0xFF); // 事务ID低字节 frame[2] 0x00; // 协议IDMODBUS固定为0 frame[3] 0x00; frame[4] 0x00; // 后续字节长度 frame[5] 0x06; // 6 单元号1 功能码1 地址2 数量2 frame[6] unitId; // 从站单元号汇川默认视配置为1或255 frame[7] 0x03; // 功能码读保持寄存器 frame[8] (byte)(startAddr 8); // 起始地址高字节 frame[9] (byte)(startAddr 0xFF); frame[10] (byte)(count 8); // 数量高字节 frame[11] (byte)(count 0xFF); return frame; }这段代码的核心是把MODBUS TCP的MBAP头和PDU拼在一起。frame[4]和frame[5]是长度字段表示“单元号功能码数据”的字节数读请求固定是6所以frame[5]直接填0x06。count参数是寄存器数量协议上限是125超过这个值从站直接返回异常响应代码里应该加一个防御判断。响应解析比请求构造更容易出错。响应帧结构是“事务ID2字节协议ID2字节长度1字节单元号1字节功能码1字节字节数1字节数据N字节”解析时要先看功能码最高位是否为1是1说明从站返回的是异常码。public ushort[] ParseReadResponse(byte[] response) { // 异常响应功能码最高位置1下一个字节是错误码 if ((response[7] 0x80) ! 0) { throw new ModbusException($MODBUS异常响应错误码0x{response[8]:X2}); } int byteCount response[8]; // 数据区字节数等于寄存器数×2 ushort[] values new ushort[byteCount / 2]; for (int i 0; i values.Length; i) { // 单寄存器内高字节在前低字节在后这是MODBUS标准字节序 values[i] (ushort)((response[9 i * 2] 8) | response[10 i * 2]); } return values; }这里有个容易忽略的点response数组的前6个字节里包含了请求时发出去的事务ID但这段代码没有校验它。实际多线程环境下必须确认response[0]和response[1]等于当前请求的事务ID否则你拿到的可能是上一次超时重试残留的旧响应。识别到不匹配时直接丢弃不要解析。3.2 写单个与写多个功能码06、10、05的使用边界写操作比读操作要谨慎因为一旦写错寄存器设备可能直接动作。功能码的选择看操作对象05写单个线圈06写单个寄存器0F写多个线圈10写多个寄存器。日常参数下发用06就够批量初始化配方参数时用10一次写入一堆连续寄存器效率高很多。public byte[] BuildWriteMultipleRequest(byte unitId, ushort startAddr, ushort[] values) { int dataBytes values.Length * 2; // 帧长 MBAP头7字节 单元号1 功能码1 起始地2 数量2 字节数1 数据N byte[] frame new byte[12 dataBytes]; _transactionId; frame[0] (byte)(_transactionId 8); frame[1] (byte)(_transactionId 0xFF); frame[2] 0x00; frame[3] 0x00; // 长度字段 单元号1 功能码1 地址2 数量2 字节数1 数据N int length 7 dataBytes; frame[4] (byte)(length 8); frame[5] (byte)(length 0xFF); frame[6] unitId; frame[7] 0x10; // 功能码写多个保持寄存器 frame[8] (byte)(startAddr 8); frame[9] (byte)(startAddr 0xFF); frame[10] (byte)(values.Length 8); frame[11] (byte)(values.Length 0xFF); frame[12] (byte)dataBytes; // 数据字节数 for (int i 0; i values.Length; i) { frame[13 i * 2] (byte)(values[i] 8); frame[14 i * 2] (byte)(values[i] 0xFF); } return frame; }注意length的计算MBAP头里长度字段是从单元号开始算的所以是“1(单元号)1(功能码)2(起始地址)2(数量)1(字节数)dataBytes”即7dataBytes。很多人在长度上多算或少算一个字节从站返回的异常码是0x03非法数据值排查时先检查这里。写单个寄存器的功能码06帧长只有12字节比写多个简单得多但要注意写单个完成后从站会回显完整请求帧不是空响应写多个只回显“事务ID协议ID长度单元号功能码起始地址数量”共12字节。响应解析逻辑不同别拿同一个函数去套。3.3 超时与重试为什么重试时必须换新事务IDTcpClient自带的ReadTimeout在UDP和连接断开场景下表现不可靠尤其是PLC断电重启的瞬间同步读可能直接抛IOException而不是超时。更稳妥的做法是读写操作都走自定义超时用ManualResetEvent或CancellationToken实现重试逻辑单独封装。public ushort[] ReadRegistersWithRetry(byte unitId, ushort startAddr, ushort count, int retryTimes 3) { Exception lastException null; for (int i 0; i retryTimes; i) { try { // 每次循环都重新构造请求事务ID会继续递增不会复用旧帧 byte[] request BuildReadRequest(unitId, startAddr, count); byte[] response ExecuteTransaction(request, timeoutMs: 500); return ParseReadResponse(response); } catch (Exception ex) { lastException ex; // 重试前清空TCP接收缓冲区把上次可能残留的半包数据丢掉 ClearTcpBuffer(); Thread.Sleep(100); } } throw lastException; }重试的关键是绝不能复用同一个byte[]数组。如果重试时把上一帧原样再发一次事务ID还是同一个汇川从站会把这一帧当作重复请求悄悄丢弃你只能一直等到超时。事务ID就像TCP的序列号必须全局唯一并且递增。超时时间的选择也有讲究。500ms对局域网内的PLC通讯足够车间现场如果经过多级交换机建议放大到1000ms。重试次数3次是底线超过3次还在失败应该切换为重新连接而不是继续重试因为此时大概率是物理链路断了再试只是浪费CPU。提示ExecuteTransaction内部要同时处理Socket异常、超时和半包读取。半包需要通过累积缓冲区处理因为一帧MODBUS TCP响应可能分两次到达TCP是流协议不是报文协议。4. 汇川PLC寄存器映射与数据类型地址和字节序搞对再谈通讯4.1 寄存器地址映射%MW、%MX与MODBUS地址的换算汇川PLC里变量地址和MODBUS地址不是总能直接画等号。%MW是最常用的保持寄存器区H5U和AM系列的%MW0通常对应MODBUS地址0但老款H系列或者开了“地址偏移”选项后会整体错位。开始写代码之前先把编程软件里“Modbus TCP从站映射表”截图存档所有地址换算以那张表为准。汇川数据区数据类型典型MODBUS地址说明%MW0~%MW9999WORD保持寄存器0~9999参数读写最常用%MDxDINT双字按字地址顺延占2个寄存器注意高低字顺序%MFxREAL浮点按字地址顺延IEEE754格式占2个寄存器%MXx.y位/线圈视型号映射有些型号需要单独映射到线圈区%QWxWORD输出视型号映射和%MW不同段小心重叠我遇到过这样一个现场HMI上配置的地址是%MW100PLC编程软件里的映射表显示MODBUS地址也是100但C#上位机读100一直返回0。最后打开PLC侧配置才发现从站设置里勾选了“Modbus地址偏移1”实际要读101才对应%MW100。这种坑查代码查不出结果必须回到PLC侧看配置。线圈%MX的映射更麻烦。PLC里一个字节的位地址通常是%MX10.0到%MX10.7映射到MODBUS线圈地址时有些固件按位展开有些固件按字展开位序还可能反转。读线圈的报文本身很简单功能码01或02但解析回来的字节数组需要按位拆包位序错了数值就全错。4.2 浮点数与32位整数的拆装高字在前还是低字在前汇川PLC的DINT和REAL都占两个寄存器。麻烦的是C#的BitConverter在小端机器上处理字节序的方式和PLC内部的大端布局不一样直接拿寄存器值硬拼会得到完全错误的浮点数。下面是可靠的转换方式。/// summary /// 两个寄存器合成浮点数 /// /summary public static float RegistersToFloat(ushort high, ushort low) { // reg[0]是高位寄存器reg[1]是低位寄存器这是汇川默认布局 uint bits ((uint)high 16) | low; return BitConverter.ToSingle(BitConverter.GetBytes(bits), 0); } /// summary /// 浮点数拆成两个寄存器 /// /summary public static (ushort high, ushort low) FloatToRegisters(float value) { byte[] bytes BitConverter.GetBytes(value); // 小端机器上 bytes[0]/[1] 是浮点的低16位bytes[2]/[3] 是高16位 ushort high (ushort)((bytes[3] 8) | bytes[2]); // 对应reg[0] ushort low (ushort)((bytes[1] 8) | bytes[0]); // 对应reg[1] return (high, low); }逻辑说明IEEE754单精度浮点共4字节x86机器上BitConverter.GetBytes返回小端序列b0、b1、b2、b3其中b3是最高字节。汇川PLC寄存器按大端存储高字放进第一个寄存器低字放进第二个。RegistersToFloat把high左移16位拼上low就得到了完整的32位浮点位模式再交给BitConverter解析。参数说明high是PLC侧第n个寄存器的值low是第n1个寄存器的值不是反过来的。如果现场发现浮点数值是对的但符号位或指数错乱大概率就是高低字对调了。DINT的处理方式一样只是拼接完直接强转int不需要经过浮点位模式。4.3 批量读取一次读60个寄存器比循环60次快一个数量级MODBUS TCP的局域网往返时间大概0.5到2毫秒读一个寄存器和读60个寄存器的时间几乎一样因为报文长度差异只有几十字节。把参数规划成连续寄存器块一次批量读回来再按偏移拆成工程变量是提升采集效率最直接的手段。public Dictionarystring, object ReadParamGroup() { // 上位机与PLC约定%MW200开始连续60个字全部是设备参数 ushort[] raw ReadRegistersWithRetry(0xFF, 200, 60, retryTimes: 3); // 按协议拆变量2个字放运行速度2个字放目标位置1个字放报警字…… return new Dictionarystring, object { [运行速度] RegistersToFloat(raw[0], raw[1]), [目标位置] RegistersToFloat(raw[2], raw[3]), [当前报警字] raw[4] }; }建议一次读60个寄存器而不是125个理由有两个一是避免超出某些老款固件单帧处理的缓冲区限制二是如果里面混着掉电保持区与非保持区分组规划时要留出呼吸空间。PLC侧规划变量时尽量把同类型、同用途的参数排在一起上位机维护一个地址分配表比读一个变量定义一个地址要清晰得多。批量读之后要做的第一件事不是解析数据而是校验返回的寄存器数量是否等于预期数量。从站响应数据字节数不对时直接按固定偏移解析会把整帧数据解释成乱码而且这种错误不会抛异常只会得到一堆看起来合理但实际不正确的数值。5. 避坑记录五个通讯故障的现象、原因与排查路径5.1 偶发超时事务ID重复导致从站丢弃请求现象程序每运行十几分钟出现一次超时异常重试一次就恢复不影响整体功能但日志很难看。原因上位机里有多个线程触发读写每个线程各自维护了一套事务ID计数两个线程产生相同的事务ID。汇川从站认为事务ID重复的帧是重复请求直接丢弃不响应客户端等到超时。解决事务ID改成全局唯一用Interlocked.Increment保证原子性重试时调用BuildReadRequest重新构造报文不能复用旧帧。排查方式是给每帧的响应打时间戳看超时是否集中在某个写入操作附近。5.2 数据错乱32位数据的高低字顺序搞反现象写入DINT数值100PLC侧读出来是65546这种莫名奇妙的数。原因DINT占两个寄存器上位机把低位寄存器放进第一个高位寄存器放进第二个和PLC内部布局相反。MODBUS寄存器本身是大端但“哪个寄存器是高字节”由PLC厂商定义汇川绝大多数型号是高字在前。解决写数据前先读一次该地址的原始寄存器值把两个寄存器的十进制值做对比数值大的那个是高字。确认后再用4.2节的FloatToRegisters风格去拼装。这类问题最容易出现在从别的品牌PLC项目移植过来的代码里。5.3 地址偏移按HMI地址写MODBUS请求读出来全是0现象HMI上显示%MW100的变量值是123C#读MODBUS地址100返回0读101才读到123。原因PLC侧“Modbus从站配置”里启用了地址偏移。地址偏移选项在某些固件里默认开启偏移量通常是1导致%MW100映射到MODBUS地址101。解决以PLC编程软件映射表为准不要以HMI地址为准。排查时用Modbus Poll之类工具手动扫一段地址范围找出实际有数据的地址区间再把上位机地址表整体对齐。5.4 数据不刷新TCP缓冲残留旧响应现象PLC变量值和上位机显示值不一致点击刷新按钮有时能恢复有时不能。原因TCP接收缓冲区里有上次响应的残留字节下一帧响应到达后和残留数据拼在一起解析器按固定偏移截取截出来的数据是错位的。特别是请求超时后没有清空缓冲区就发下一帧最容易触发。解决每次重试前调用ClearTcpBuffer清空接收缓存解析响应前强制校验事务ID不匹配直接丢弃整个字节数组。排查时在解析函数入口打印响应前4字节对比请求的事务ID一眼就能看出错位。5.5 PLC重启后上位机卡死同步读阻塞与断线重连现象现场断电检修后PLC恢复上位机界面卡住CPU占用不高但任何操作都没反应。原因TcpClient的同步Receive阻塞在等待数据上PLC断电时链路没有正常发FIN包客户端不知道连接已死ReadTimeout在某些网络异常场景下不会触发。解决读操作统一走带超时的ExecuteTransaction超时后主动关闭Socket并重新连接业务层加心跳轮询一个看门狗线程定时读一个固定寄存器连续3次失败就触发重连。从那以后我每个上位机项目都强制带看门狗线程不再信任裸TCP的长连接。6. 进阶落地事件分发、写队列与断线重连把第3章的通讯层代码单独封装成类之后下一步是解决“怎么和UI界面协同”的问题。直接让按钮事件里去调用ReadRegisters会卡界面用BackgroundWorker又容易在窗体关闭时抛出ObjectDisposedException。我一般会在通讯层之上加一个事件总线的壳读写操作全部异步化UI只订阅事件。public class PlcDataService { // 数据更新事件参数名 寄存器原始值数组 public event Actionstring, ushort[] OnDataUpdated; public async Task PollLoopAsync(CancellationToken token) { while (!token.IsCancellationRequested) { try { ushort[] values _plc.ReadRegistersWithRetry(0xFF, 200, 60); OnDataUpdated?.Invoke(产量参数块, values); } catch (Exception ex) { // 连续失败3次触发ReconnectRequested由外部断线重连 ReconnectRequested?.Invoke(ex); } await Task.Delay(100, token); } } }订阅事件的一方在UI线程里更新文本框和曲线天然规避了Control跨线程访问的问题。接口层会按照这个思路演化成一个完整的C#上位机通用框架扫描周期可配置、参数块地址用配置表维护、写入操作做成队列避免多个线程同时往一个地址写。写入队列的做法是所有写请求放进ConcurrentQueue由独立线程串行消费每次写入后等待响应或超时再处理下一条。这样即使多个界面对同一个寄存器发写命令也不会出现两条指令交错的脏数据。断线重连在事件分发之外单独做重连成功后重新拉一次全量参数保持界面数据新鲜。这套源码最值钱的部分不是那几十个函数而是事务ID管理、批量读取、重试策略这些经过现场验证的组合方式。我接手过的项目里有照着网上Demo随便拼的第一版都能跑三个月后全在改超时和字节序的坑。现在新项目我会直接把通讯层独立成一个DLL工程UI永远不直接持有TcpClient对象数据变更全走事件写操作全进队列——刚从这套源码迁移过来时觉得绕后来发现排除问题省了一半时间。希望帮到你。本文还有配套的精品资源点击获取