汇川PLC Modbus通讯Demo实战：从RTU/TCP到寄存器地址与调试排错

简介：这是一份基于VB.NET的汇川PLC Modbus TCP通讯示例项目，面向工业自动化上位机开发者与PLC编程初学者，演示了如何通过Modbus TCP协议实现PC与汇川PLC的实时数据交换，涵盖寄存器读写、请求报文构建、响应解析等关键环节。压缩包内共33个文件，以vb源码、exe可执行程序、dll动态库和xml配置为主，同时包含pdb调试符号与resources资源文件，整体仅141KB，结构精简、便于直接打开工程对照学习。工程中既包含窗体界面与交互逻辑代码，也封装了Modbus TCP通信核心类，可直接复用相关通信方法。目前已有1135人学习，作为轻量级入门案例具有较高参考价值。通过查看完整源码并运行示例，可快速掌握VB.NET环境下Modbus TCP通信库的调用方式、PLC寄存器与线圈读写流程、异常处理及通信稳定性保障机制，为后续开发复杂上位机监控系统打下扎实基础。 很多刚接触汇川PLC的工程师，来问的第一句基本都是："我要跟变频器、伺服或者仪表做Modbus通讯，这个Demo到底怎么写？"我一般不会急着甩程序，而是先反问一句：你用的是RTU还是TCP，从站设备的寄存器地址表拿到没有？这两个问题答不上来，程序写出来也跑不通。

这篇文章就是围绕"汇川PLC做Modbus通讯Demo"这件事，把从协议理解、机型差异、指令写法到调试排错的全过程拆开讲一遍。里面既有我实际调试H5U、Easy522、AM系列的经验，也有跟Modbus Poll、Modbus Slave这些工具打交道的细节，适合正在做汇川PLC串口或以太网通讯，或者准备做触摸屏、上位机联调的工程师参考。

1. 一个能跑的Demo背后是三件事：协议、通路、寄存器

1.1 为什么网上那些"照着敲一遍就通"的教程总翻车

先说个现象：很多人下载过某某大神共享的"汇川PLC Modbus RTU通讯例程"，打开一看，主程序里几条指令，注释还写得挺全，结果拿到自己现场一跑，要么通讯指示灯不闪，要么数据读出来全是0，要么干脆报错。问题出在哪？

因为这些Demo只给了"程序"，没给"前提条件"。Modbus通讯不是PLC单独一方的事，它牵涉三个层面：

• 物理通路：RS485的A/B线接对没有，网线是否通，变频器的通讯参数和PLC侧是否一致。
• 协议参数：波特率、数据位、校验位、停止位、从站地址，这是Modbus通讯的"身份证"，六个数只要有一个不对，帧都发不出去。
• 数据映射：目标寄存器地址在设备里到底是什么含义——是频率设定、状态字还是电流值，是16位还是32位，是高位在前还是低位在前。

只看程序，不看这三层，等于拿了一把钥匙去开不知道锁在哪的门。所以比起复制代码，我更建议大家先理解一套Demo的运行逻辑，然后照着逻辑自己拼一个出来，遇到问题也知道往哪查。

1.2 先搞清楚主从关系，再谈指令写法

Modbus协议的模型是一主多从。通讯链路上只能有一个主站（通常是PLC或上位机），从站是被轮询的对象（变频器、伺服、仪表、远程IO等）。主站主动发请求，从站收到后做出响应；从站之间不能主动说话，也不能互相通信。

这就像车间主任派活：主任问一组员"你现在做到哪一步了"，组员答"做到第三步了"，主任再问另一个组员。组员之间不互相打听。联想起真实的车间场景，你让任何一个人同时接受两个领导的询问，他一定会乱套——现场总线也一样，一条RS485总线上如果出现两个主站，通讯必然紊乱。

因此，写Demo之前要明确自己的角色：汇川PLC到底是主站还是从站？如果PLC去控制变频器，那PLC是主站，变频器是从站；如果上位机或触摸屏来读写PLC数据，那PLC是从站。角色定反了，整个程序结构都要返工。

1.3 你手里的汇川PLC是哪一类：指令型和Codesys型

汇川的中大型PLC产品线比较多，但从编程方式上可以分成两大类，Modbus的处理方式差异很大：

H5U和Easy系列是现在市面上最常见的，也是我写Demo时最常碰到的。前者带网口，多走Modbus TCP；后者主打性价比，串口RTU用得更多。而AM系列因为跑Codesys，本质上和汇川"自家风格"的指令体系完全不同，需要单独建模。

分清这一点，再去网上搜例程的时候才不会拿错代码。很多人拿一个H5U的TCP例程往Easy522上套，串口当然通不了——这跟程序好不好没关系，是平台压根不一样。

2. 地址换算与功能码：数据能不能读对，全看这一层

2.1 Modbus功能码不是背出来的，是查设备手册查出来的

Modbus协议里最常用的功能码就那几个：03读保持寄存器、04读输入寄存器、06写单个寄存器、16（0x10）写多个寄存器。但有一个认知必须纠正：功能码不是"想用哪个用哪个"，而是取决于从站设备支持什么。

以汇川MD800变频器为例，它的运行频率设定地址通常是"运行频率"这个参数，通过03功能码可以读取当前频率，通过06功能码可以写入设定频率。如果你对一个只支持保持寄存器的设备用04功能码去读，它会直接返回异常码——实际表现就是PLC这边报通讯错误，从站那边通讯指示灯闪了一下就没反应了。

所以拿到一台新设备，第一件事永远是找它的Modbus通讯手册，翻到寄存器地址表，确认三件事：

• 目标参数对应的寄存器地址是多少（注意有些手册直接写十六进制，有些写PLC地址格式）。
• 参数类型是16位无符号、16位有符号还是32位浮点。
• 参数性质是只读还是可读写。

这三条信息直接决定你调用功能码和寄存器地址时填什么。

2.2 寄存器地址"40001"到底怎么换算

这是新手最容易晕的地方之一。很多第三方仪表或变频器手册上，地址列写成"40001、40002"，而汇川PLC的Modbus指令里要求填的却是"1、2"或者"0x0000"。为什么？

因为"40001"是Modbus协议早期的"PLC地址"写法，它包含了数据类型信息：4开头是保持寄存器，3开头是输入寄存器。而实际协议报文里，地址字段是16位的，从0开始计数。两者差了个偏移量：

• 40001对应协议地址0x0000（即十进制0）
• 40002对应协议地址0x0001
• 如果把40001直接填成40001发出去，帧格式就错了

具体到汇川平台，H5U的Modbus TCP指令里，地址参数通常直接填协议地址；Easy522的RTU指令里一般填相对地址，即0、1、2这种。遇到手册给的是40001形式，先把4xxxx去掉4再减1，得到的就是协议地址。

2.3 32位数据的大小端问题：明明读出来了，数据却不对

16位寄存器好处理，一个参数对应一个寄存器。但变频器里的频率、电流、电压很多是32位浮点，一个参数占用两个连续寄存器，这时候就会遇到大小端问题。

Modbus协议规定32位数据是由两个16位寄存器组成的，但先传高字节还是先传低字节，不同厂家实现不一样。汇川自家设备之间通讯，默认顺序往往是"高字节在前"（Big-Endian）。但如果汇川PLC去读一个台达或者别的品牌的仪表，对方可能用的是"低字节在前"（Little-Endian）。

我处理过一个案例：汇川Easy522去读一台国产温控器的当前温度，读出来数值除以10以后是"乱数"，比如实际126.5度，显示2433.2。后来把两个寄存器的字节序换了一下，数值立刻对了。这不是程序逻辑写错了，是设备间字节序约定不同。

所以Demo里最好留一个"字节交换"的开关或功能块，方便现场调。H5U和Easy系列做32位浮点通讯时，指令里通常有字节序相关的参数项，默认值别急着用，先查从站手册确认。

3. 从H5U到Easy522再到AM：三种典型机型，三种不同写法

3.1 H5U走Modbus TCP：几条指令拉通一个网口通讯

H5U做Modbus TCP是最省事的，因为底层TCP/IP协议栈已经封装好了，不需要去配置串口参数。

在Autoshop软件里，H5U集成了Modbus TCP客户端指令，一般分三步：建立连接、读写数据、断开连接。实际写程序的时候，我通常把"建立连接"放在初始化段执行一次，把"读写数据"放在周期性任务里，比如每100ms轮询一次。

一个典型的主站读写流程可以这么理解：

• 第一步：指定要访问的从站IP和端口号（默认502）。
• 第二步：指定远程寄存器起始地址和数据个数。
• 第三步：定义本地存储区，把读回来的数据放到一个数组里，或者把要写的数据从数组发出去。

这里有一个容易被忽略的地方：H5U的Modbus TCP指令里填的从站地址（Unit ID），如果只有一个设备，通常填1；但如果通过网关连接多个RTU从站，Unit ID必须和每个设备的串口地址对应上，不能都填1。

网口通讯的好处是速度比串口快，而且没有RS485的A/B线接反、终端电阻这些问题。但坑也有，比如PLC的IP和电脑不在同一网段时，连不上就是连不上，PING不通就别谈通讯了。

3.2 Easy522走Modbus RTU：寄存器映射和COM口配置缺一不可

Easy系列是汇川在主推的入门级PLC，做Modbus RTU时，我一般用ADPRW指令或者直接通过组态软件的"通讯配置"功能来实现。但不管用哪种方式，都需要先完成两个前提：

第一，COM口的物理参数要和从站一致。比如变频器侧设置波特率9600、8数据位、无校验、1停止位，那PLC侧也必须一模一样。参数不一致时，帧结构就是错的，表现通常是通讯超时。

第二，确定从站地址和寄存器映射。Easy522的Modbus指令里通常有一个"从站站号"参数，范围是1到247。这个站号必须和从站设备上拨码或软件设置的站号一致，否则从站根本不会应答——它收到一个叫别人的请求，不觉得自己该回答。

Easy系列还有一个常见用法：作为Modbus从站，让昆仑通态或者别的触摸屏来读写它的内部寄存器。

这种情况下，不需要写太多通讯指令，主要是把PLC的内存区和Modbus地址映射关系配好。Easy522的寄存器映射有讲究，比如M区对应Modbus的线圈（0x区）、D区对应保持寄存器（4x区）。你在触摸屏上组态的时候，填的地址要和PLC侧映射地址一一对应，否则标签上读出来全是"设备无响应"。

3.3 AM系列跑Codesys：标签通讯和Modbus功能块是两条路

AM系列走的是Codesys生态，好处是标准化，坏处是它和H5U/Easy的"原生风格"差异太大，习惯了Autoshop的人第一次上手会很不适应。

在AM系列上做Modbus主站，通常是添加一个Modbus Master的通讯对象，然后建立I/O映射：把Modbus从站的寄存器映射到PLC的变量上。映射配置好以后，代码里直接读写变量就行，不需要为通讯本身写逻辑——这其实更接近触摸屏的组态方式。

AM系列也支持Modbus从站功能，让第三方主站（比如上位机）来访问它。配置路径一般是添加"Modbus Slave"设备，然后把需要暴露给外部的变量一一映射到寄存器地址。有一次我帮客户做触摸屏和AM600的标签通讯，关键是两边的变量类型和地址别绑错，一个Word绑成Bool，标签通讯就断断续续，在线监控才知道是映射错位了。

另外Mac用户注意一下，AM系列如果在InoProShop里改了Modbus映射表，在线下载程序的时候通讯会短暂中断，这是正常现象，但现场有设备正在跑的话，要挑停机窗口去搞。

3.4 昆仑通态屏和汇川PLC通讯：中文字符乱码的问题

很多项目用汇川PLC配昆仑通态触摸屏，走Modbus RTU或TCP。通讯搭好后，数字量、开关量都正常，偏偏字符串变量显示出来是乱码。这个问题我在现场处理过好几次。原因倒不复杂：触摸屏和PLC对字符串的编码格式不一致，或者寄存器区解析成了16位整数而不是字符串。

解决方法是：在触摸屏的变量组态里，把对应通道的数据格式改为"字符串"或"ASCII"，并选择正确的字节序。如果PLC侧把中文字符按GB2312存了两个寄存器，屏幕侧却按Unicode去解释，必然乱。

还有一个实用技巧：PLC侧把字符串的末尾加上结束符（比如0x00），触摸屏侧才不容易把残留数据也显示出来。不加结束符的话，字符串长度变了就容易带出上一帧的脏数据。

4. 数据读对了没有：用Modbus Poll/Slave把通讯过程"看"出来

4.1 电脑先当从站，PLC程序不白写

写完了PLC主站程序，不想直接拿现场变频器去试，最稳妥的做法是先用电脑模拟一个从站。Modbus Slave这个工具就是干这个的。

具体操作步骤：

1. 电脑通过USB转RS485线连接到PLC的COM口，或者直接网线连到PLC的网口。
2. 在Modbus Slave里设置从站地址为1，功能区选择寄存器类型（比如Holding Register），填入模拟数据。
3. PLC程序正常跑，看它能不能从Modbus Slave里读到你在电脑上设置的数值。

这一步能验证的事情非常多：PLC的指令参数有没有填错、轮询周期是否正常、报文能否成功发送、接收回来的数据是否符合预期。如果PLC对电脑这个"假从站"都通不了，那就不用急着去现场接真设备了，先检查参数配置。

4.2 电脑当主站，看PLC从站数据对不对

反过来，当PLC做从站时，用Modbus Poll这个主站工具去读PLC，可以快速验证PLC内部的Modbus从站配置是否正确。

同样先连线，然后新建连接，填入PLC的IP地址（TCP模式）或串口参数（RTU模式），再以合适的命令和地址去读。能读到数据，说明PLC的从站配置和映射没有问题；读不到或者返回异常错误码，说明寄存器映射或者站号设置有问题。

Modbus Poll还有一个功能我觉得非常实用：它能把通信报文原样显示出来，每一帧的地址、功能码、数据、CRC校验码都看得一清二楚。做通讯调试，看到报文比看到最终数值有用得多——因为你可以判断是"发了没收到"还是"收到但解析错了"。

4.3 RTU模式下的CRC校验错误：十有八九是参数不一致

用Modbus Poll做RTU调试时，如果软件提示CRC错误，先别怀疑是工具的问题。CRC是Modbus协议里的循环冗余校验，从站收到帧以后会自己重新算一遍，算出来的和帧尾带的不相等，就会丢弃这帧数据。

CRC对不上的常见原因有三个：

• 波特率不一致导致的采样错位。
• 数据位/校验位/停止位配置错误，字节边界都乱了。
• 外部干扰导致报文变形，比如RS485线走得太长或者跟动力线捆在一起。

如果是前两种，改参数就能解决；如果是第三种，就需要从布线层面去处理了。

4.4 物理层排查：RS485的A/B线、终端电阻和地线

有些通讯问题是物理层引起的，协议参数再对也没用。RS485是差分信号，靠A、B两根线的电压差来传数据。A/B接反时，信号电平逻辑完全翻转，设备收到的一定是乱码或者干脆无响应。

终端电阻也不可忽视。一条RS485总线两端各需要接一个120欧左右的终端电阻，用来吸收信号反射。总线长度几十米时可以不管，超过100米或者波特率较高时，不接终端电阻就可能出现偶发的通讯超时。

还要注意RS485的GND（参考地）。很多设备上的RS485接口只引出了A和B两根线，但严格来说，总线上各个节点的参考地应该尽量等电位。距离远的时候，建议在总线上拉一根公共地线或者用带隔离的RS485模块，否则雷击或共模干扰会烧通讯口——这个我在工厂现场见过不止一次。

5. 汇川Modbus Demo调试中的常见坑：从"格式不正确"到"屏连不上"

5.1 RS485通讯提示"传输格式不正确"，到底是谁的锅

这个报警是汇川PLC或触摸屏在做串口通讯时经常跳出来的。很多人的第一反应是"程序写错了"，但排查下来往往不是程序的问题。

根据我的经验，"传输格式不正确"绝大多数出在通讯参数的"约定环节"：

• PLC侧设置的帧格式（比如8E1）和从站设备实际使用的格式（比如8N1）不一致。
• 从站地址超出范围，比如填了0或者大于247。
• 数据在传输过程中发生了帧断裂，导致PLC收到的不完整或错位的报文。

遇到这个报警，我的排查顺序是：

1. 先核对通讯参数，把波特率、数据位、校验位、停止位和从站设备厂家手册里的出厂值逐一对照。
2. 把从站设备单独接出来，用Modbus Poll去试，看报文是否正常，CRC是否报错。
3. 如果Poll这边正常，但PLC报警，那就检查PLC指令里填的从站地址、寄存器地址是否和你测试时一致。

有一次我调一台Easy522跟汇川变频器的通讯，频繁报"格式不正确"，一直怀疑是程序有问题。后来用电脑接上去一抓报文，才发现变频器的站号实际是2，而PLC里填了1——没有人拨过码，默认站号可能跟手册标的不一样。改完站号，通讯立刻恢复。

5.2 三菱FX3GA与GT1150屏通讯不上：换个思路排查

热搜词里有"三菱FX3GA与GT1150屏通讯不上"，这类问题跟汇川Modbus调试思路完全相通。FX3GA自带编程口，GT1150触摸屏跟它通讯通常走的是三菱专用协议，而不是标准Modbus。如果通讯老是建立不了，先确认触摸屏工程里选择的PLC类型是否匹配，通讯端口参数是否和PLC内置参数一致，连接线是否是原装的编程线。

有一次类似的案例，客户一直怀疑屏有问题，后来发现是触摸屏的通讯协议选成了Modbus RTU，而PLC侧默认的是三菱专用协议——两边对不上，自然连不上。这种"协议不匹配"的问题，换成汇川PLC与触摸屏通讯时也一样常见。

5.3 轮询周期和超时时间：Demo能跑和能扛是两回事

很多Demo在实验室里一切正常，一到现场就频繁超时，问题往往出在轮询周期设计上。

Modbus主站是"一问一答"式的：发一帧请求，等一帧响应，收到后再发下一帧。如果轮询周期设置太短，上一帧还没等到响应，下一帧就发出去了，帧冲突自然避免不了。现场设备比实验室设备响应慢是很正常的，尤其是某些国产仪表，动作时间能到几百毫秒。

我的习惯是：把超时时间设为500ms以上，轮询周期设为200ms到1s，具体值根据现场最慢的那个从站的响应时间来定。如果总线上挂了多个从站，要给每一个从站分配独立的轮询时间，不要一个循环无脑刷到底。

现场经验也告诉我，通讯周期不是越快越好。某些变频器在做参数读写操作时，内部时序会暂停通讯处理，这时候频繁写入反而容易造成偶发失败。宁可慢一点，也不能让故障率上去——项目验收看的是稳定，不是速度。

5.4 调试完Demo之后，至少要做一次"断电重启验证"

这是我个人比较坚持的一个习惯：Demo在在线监控状态下跑通了，不要急着算完，把PLC断电，等几秒钟再上电，看程序能不能自动恢复正常通讯。

为什么要在意这个？因为很多程序能正常工作，靠的是"调试过程中已经建立了连接"的状态。PLC重启后，有些通讯连接需要重新初始化，如果初始化逻辑只写在了"首次扫描"之外的条件里，就可能出现上电后一直连不上的情况。

我做H5U的Modbus TCP Demo时，就遇到过类似的情况：在线调试一切正常，断电重启后通讯就断了。排查原因，是程序里建连逻辑放在了检测某个中间继电器置位之后才执行，而这个中间继电器初始状态下是被复位的，导致建连请求永远不会发出。后来把建连逻辑放在上电初始化块中执行，问题才解决。

类似的坑在RTU模式的从站配置上也有：有些PLC的串口参数在断电后不会立即生效，需要程序里重新触发一次初始化。所以复现"断电-上电"这个动作，能让你的Demo从"能跑"变为"真正能交付"。

汇川PLC的Modbus通讯Demo，说到底就是一个把协议、通路、数据映射三者对齐的过程。程式码只是最后一步，更花时间的是前面的参数核对、地址换算和现场排查。每一次通讯失败，都值得按"物理层—参数层—数据层"的顺序走一轮排查，比反复改程序效率高得多。希望这篇文章的拆解，能帮你下次少走几个弯路。

本文还有配套的精品资源，点击获取