企业官网建设流程全解析

简介：面向.NET上位机开发人员及工业自动化工程师的汇川PLC Modbus TCP通讯示例工程，基于VB.NET语言，展示上位机通过Modbus协议与汇川PLC实现数据交互的完整流程。压缩包共33个文件、141KB，包含8个VB源码文件（主窗体、Modbus TCP封装类、文件操作类等）、exe可执行程序、dll动态库、sln解决方案以及xml配置与资源文件，项目结构完整，可在Visual Studio中直接打开调试，也适合按模块提取复用。目前已有1135人学习浏览，是理解工业通讯协议与上位机开发的实用参考。Demo重点演示了构造Modbus请求、读写PLC寄存器、解析响应报文等核心操作，同时给出错误处理、界面交互和文件操作等辅助实现。开发者既可借此学习VB.NET环境下Modbus TCP的报文结构与编程技巧，也能将其作为实际自动化项目的基础框架快速搭建通信链路，降低工业现场集成门槛。示例还包含了生成的可执行程序，便于先运行再对照代码理解运行机理。 自动化项目做多了会发现，现场联调最耗时间的事情，往往不是控制逻辑本身，而是设备之间的“通信”。前几天一个朋友接了个改造项目，汇川PLC要跟一台第三方温控器走Modbus RTU通讯，折腾了两天没通，找我看报文。我帮他把RS485的A/B线换了，参数一统一，十分钟搞定。这类事情太典型了，所以我干脆把手上这套汇川PLC的Modbus通讯Demo完整梳理了一遍，从硬件接线、软件配置、程序实现到调试工具的使用，一步不落写出来。不管你是准备对接变频器、伺服驱动器，还是仪表、温控器，只要对方支持Modbus RTU或Modbus TCP，这份流程都可以直接参考。

1. 整体设计与思路拆解

1.1 为什么通讯方案选了Modbus

先说选择协议的逻辑。工业通讯方案一大把：Profinet、EtherCAT、CC-Link、CANopen，每个性能都不差，但问题在于你的设备不一定支持。我到现场对接过的大多数第三方设备，尤其是中小型仪表和驱动器，Modbus基本是“标配协议”，有些甚至只支持Modbus。这就是我为什么在绝大多数跨品牌通讯项目里首选Modbus——不是因为它最先进，而是它最不容易被拒绝。

Modbus的优点是免费、开放、简单，报文结构清晰，调试也方便。它由Modicon公司（也就是后来的施耐德电气）在1979年提出，最初用于PLC之间的通讯，后来逐渐扩展到工控领域的各个角落。你可以把它理解成“工控圈的世界语”，大家水平参差不齐，但说世界语总能沟通上。

换个角度看几种现场通讯方式的特点：

对汇川PLC来说，Modbus主站功能是标配，AutoShop软件里直接调用功能块就行，就算用RTU也只需要一个串口，本体没有就加个扩展模块，成本很低。这也是它在大量中小项目里能“一招鲜”的原因。

1.2 RTU还是TCP，这个Demo怎么选

Modbus常见实现有三类：RTU、ASCII、TCP。ASCII目前很少有人用，重点就是RTU和TCP。RTU基于RS485/RS232串口，报文用二进制传输，效率高。TCP基于以太网，用IP加端口寻址。

这个Demo我选了RTU，原因有三个：

• 现场仪表、变频器这类设备，RS485串口是“默认配置”，TCP反而不一定有。
• RS485布线简单，两芯屏蔽线就能拉几百米，抗干扰能力也不错。
• RTU涉及串口参数、字节顺序、终端电阻、轮询超时这些细节，把这些搞明白，TCP基本就是换个地址格式的事。

做个对比表更直观：

如果以后想切到TCP，把Demo里的串口初始化换成socket连接，功能码和寄存器地址的逻辑完全一样。所以先把RTU啃下来，性价比最高。

1.3 Demo整体架构

这套Demo的主角是一台汇川H5U，编程软件用AutoShop，属于IEC 61131-3平台，作为Modbus主站。从站我准备了两个方案：

• 真实从站：汇川MD800变频器，通过RS485连接；
• 软件从站：电脑上跑Modbus Slave软件，用RS485转USB接到电脑，让电脑模拟一个从站设备。

这个“软件从站”特别值得一说。很多朋友调试时手里没有真实的从站设备，程序写了半天没法验证，一到现场全是问题。用Modbus Slave先在桌面上把通讯逻辑跑通，再把真实设备挂上去，现场调试时间能减少一半以上。

数据流大概是这样的：主站轮询读取从站运行频率、母线电压等状态寄存器，把控制命令（启动、停止、目标频率）写入从站的控制寄存器，同时可以在主站侧用Modbus Poll做旁站监控，看总线上的数据是否正常。思路讲完，下面把每一步落地过程展开。

2. 核心细节解析与实操要点

2.1 先花五分钟把Modbus数据模型记牢

我做培训时经常讲，Modbus地址搞不清楚，后面全是坑。Modbus把数据划分为四个区域：

现实里绝大多数读写操作都落在“保持寄存器”上。比如变频器的控制字、运行频率、电流电压，基本都在保持寄存器里。输入寄存器一般放只读的测量值。线圈和离散输入在设备里用得相对少。

特别注意一个容易混淆的点：协议内部寄存器地址从0x0000开始，而设备手册里的Modbus地址常从1开始（如40001）。所以手册里的“40001”对应协议地址0x0000，“40010”对应协议地址0x0009。有些手册直接给十六进制地址（如2000H），写程序时直接填0x2000。我习惯在程序里统一用十六进制，或者加上注释，免得自己后面都分不清。

举例，如果变频器手册写着“运行频率，地址2000H，可读”，那就用功能码03，起始地址0x2000，读1个寄存器。如果手册写着“命令字，地址1000H，可写”，就用功能码06写单寄存器（写一个），或者用10写多寄存器（写多个）。

功能码记忆窍门：01读线圈，05写线圈；02读离散输入；04读输入寄存器；03读保持寄存器，06写单个保持寄存器，10写多个保持寄存器。看到03、06、10，基本就是读写保持寄存器，占了日常维护的80%以上。

2.2 RTU报文与CRC校验

Modbus RTU的报文分三个部分：从站地址、功能码加数据、CRC16校验。报文本身是二进制传输，效率高，但不方便肉眼查看，调试时最好用带解析功能的工具。

读请求报文格式：从站地址（1字节）、功能码（1字节）、起始地址（2字节）、寄存器数量（2字节）、CRC16（2字节）。

以“读1号从站，从0x2000开始读2个寄存器”为例，请求帧就是：

01 03 20 00 00 02 CRC_L CRC_H

CRC16校验码由前面所有字节计算得出，低字节在前、高字节在后。我第一次抓帧时算出来的CRC跟工具显示不一致，后来才发现是高低字节顺序问题。可以用现成的CRC计算工具验证，串口调试助手里很多自带这个功能。

从站正常响应帧是：从站地址、功能码、字节数、数据、CRC。如果出错，从站返回的功能码最高位置1，比如0x83，后面跟一个错误码（01非法功能码、02非法数据地址、03非法数据值等）。这个错误码是排查问题的金钥匙，看到0x83就一定不是物理链路问题，而是请求内容有误。

2.3 汇川H5U的通讯资源与前置准备

汇川H5U是AutoShop平台下的主力PLC，本身支持Modbus TCP，本体串口支持Modbus RTU，也可以扩展串口模块。AutoShop软件里已经内置了Modbus相关功能库，不需要额外安装。

使用时按这几个步骤来：

1. 确认硬件串口位置和引脚定义，看硬件手册，不同型号有差异；
2. 在AutoShop里建立并配置工程，添加Modbus库；
3. 配置串口参数，包括波特率、数据位、校验位、停止位；
4. 程序里调用功能块，填从站地址、功能码、寄存器地址。

这里有个容易忽略的点：不同汇川PLC平台的Modbus库名称和功能块签名略有差别，H3U/H5U/Easy系列走AutoShop，AM系列（AM401/402这类）是Codesys平台，功能块叫法都不一样。所以代码不要死记，理解原理后换平台只是“翻译”一下。

3. 实操过程与核心环节实现

3.1 硬件接线，最容易翻车的环节

RS485接线看起来简单，但很多通讯问题就出在这。RS485是差分信号，通常有两根线：A（也叫A+、D+）和B（也叫B-、D-）。连接原则是主站A接从站A，主站B接从站B。

我踩过最大的坑是不同品牌对A/B的标法不一样。有的设备把A标成“+”，有的却反过来。有一次接一个仪表，怎么调参数都没响应，最后用万用表量了电平才发现A/B接反。解决办法很简单：如果通讯不上，先把A/B对调试试，零成本，却是最快排除法。

几点实操经验：

• 用屏蔽双绞线，屏蔽层单端接地；
• 通讯距离超过几十米，或者现场变频器多，在总线末端并联一个120Ω终端电阻；
• 有条件就把RS485的信号地GND也接上，很多干扰和电平问题会消失；
• 从站设备如果是两线接法，只接A和B也能跑，但共地能显著提高稳定性。

以汇川MD800变频器为例，RS485端子通常在控制端子排上，查手册找到A/B端子。变频器侧需要设置通讯参数：从站地址1，波特率9600，数据格式8-N-1（8数据位、无校验、1停止位）。

3.2 AutoShop工程配置步骤

打开AutoShop，新建工程，选好PLC型号，我用的是H5U系列，然后按下面步骤操作：

1. 在左侧工程树里找到“参数配置”或“系统配置”，进入串口设置；
2. 把串口模式改成Modbus RTU主站模式，波特率设为9600，校验方式按从站要求配置；
3. 保存配置并下载到PLC；
4. 在工程里确认Modbus功能库已加载。

有个细节：串口参数必须和从站的实际配置完全一致，波特率、数据位、校验位、停止位四个参数，一个不对都通讯不上。很多设备默认是9600、8、N、1，但也有不少设备默认19200或偶校验，先查手册再设置。

从站那边也要配置对应参数。MD800变频器通过面板功能码可以设置从站地址、波特率、数据格式。改完参数后，有些机型需要断电重启或重新上电才生效，这个也是现场常踩的坑。

3.3 主站程序实现（ST语言示例）

AutoShop支持ST、梯形图、SFC等语言。Modbus主站轮询逻辑用ST写比较清晰。下面是一个读保持寄存器的核心示例，不同版本的库功能块名可能有差异，重点是把握“触发—等待完成—再触发”的流程：

// 触发读请求（上升沿） bReadReq := FALSE; bReadReq := TRUE; // 调用Modbus读保持寄存器功能块 Modbus_RegRead( REQ := bReadReq, // 上升沿触发一次读取 SlaveAddr := 1, // 从站地址 FuncCode := 16#03, // 03: 读保持寄存器 StartAddr := 16#2000, // 起始地址 RegCnt := 2, // 读取寄存器数量 DataPtr := aReadData, // 数据存放区 Done => bDone, // 完成标志 Error => wError // 错误码 );

这里有两个关键点。

第一，REQ是上升沿触发的，不是电平触发。意思是每次要发一帧请求时，先给FALSE再给TRUE。如果一直给TRUE，有的功能块只会发一次请求，有的会一直发，取决于具体实现。最稳妥的写法是等上一次Done或错误码返回后再触发下一次。

第二，一次只发一帧。尤其当总线上挂了多个从站时，不要同时触发多个读请求。主站通讯逻辑通常是一个状态机：先发请求A，等Done或错误，再发请求B。这样总线上不会出现多帧叠加，从站也能稳定响应。

写控制命令的代码也类似，只是功能码和地址变化。比如用06功能码写单个保持寄存器：

// 写单个保持寄存器（06功能码） Modbus_RegWriteSingle( REQ := bWriteReq, SlaveAddr := 1, FuncCode := 16#06, // 06: 写单个保持寄存器 StartAddr := 16#1000, // 控制字地址，以手册为准 WriteValue := 16#0001, // 启动命令 Done => bWriteDone, Error => wWriteError );

写完控制字后要记得轮询状态寄存器，确认设备确实执行了。从站设备可能因为参数不对、未使能等原因拒收指令，仅看主站发送成功是不够的。

提示：REQ不要用常ON驱动，务必用上升沿触发，否则容易出现发送一次后不再动作的情况。

3.4 轮询逻辑的状态机设计

多从站通讯的轮询逻辑，我一般用一个状态变量配合CASE语句实现。伪代码逻辑如下：

CASE nStep OF 0: // 读1号从站频率 bReadReq := TRUE; nStep := 1; 1: // 等待完成 IF bDone OR wError <> 0 THEN bReadReq := FALSE; nStep := 2; END_IF 2: // 读1号从站状态 ... END_CASE

轮询周期的估算：假设9600波特率下，一帧请求加响应总共约20ms，5个从站轮流读一次约100ms，完全够用。如果从站响应慢，超时时间设大一些，比如500ms，防止误报超时。

3.5 用Modbus Slave做软件联调

在电脑上装Modbus Slave软件，用RS485转USB模块连接PLC。在Modbus Slave里新建一个从站，设置从站地址为1，选择功能码03，起始地址0x2000，然后在对应地址填入预设值，比如频率50.00Hz对应的原始值。启动从站后，在PLC侧监控读回来的数据，如果一致，说明PLC到总线的通讯链路是通的。

反过来，如果PLC支持作为Modbus从站，比如在H5U里启用Modbus从站功能，也可以用Modbus Poll软件模拟主站去读写PLC的内部寄存器，验证从站侧配置是否正确。这两款软件配合使用，基本能覆盖“主站侧调试”和“从站侧调试”两个方向。

4. 常见问题与排查技巧实录

4.1 通讯不上，先从这三方面查

遇到PLC读不到从站数据，我按这个顺序排查，几乎每次都有效。

第一，查硬件接线。A/B有没有接反，屏蔽层有没有接地，线缆有没有断裂松动。用万用表量一下A-B之间的电压，正常应该在0.2V到6V之间，空闲状态A比B高，约1.5V到5V。如果量出来是负的或者接近0，大概率是接反或者总线短路。

第二，查参数一致性。波特率、数据位、校验位、停止位、从站地址这五个参数，PLC和从站必须完全一致。注意有些设备改完协议参数后需要重启。如果改了参数但没重启，看起来和新参数一致，实际上还在用旧参数，也会导致不通。

第三，查通讯报文。用支持Modbus解析的串口调试工具，或者Modbus Poll自带的监控功能，抓总线上实际跑的帧。如果PLC发了请求但从站没回应，说明请求本身有问题，或者地址不对；如果从站回了错误码，可以直接按错误码定位。

注意：现场遇到通讯不上，第一时间对调A/B线，这是零成本且命中率最高的排查动作。

4.2 数据能通但不对，寄存器地址和字节顺序

通讯通了，但读回来的数值对不上，常见两类问题。

一是寄存器地址错位。比如在程序里填了0x2001，而设备手册写的是2000H，会差一个数据。还有手册里地址是40001这种形式，要转成协议地址后填。我的习惯是建一个Excel表，把设备手册里的每个寄存器地址、名称、功能码、数据格式列出来，程序里的地址和注释直接对应，避免临场换算出错。

二是32位数据的字节顺序。Modbus协议规定传输大端，高字节在前，但很多设备把32位数据（比如浮点频率）拆成两个16位寄存器时，先后顺序不一样。有些先存高16位，有些先存低16位。如果在程序里按16位读出来，两个寄存器的高低拼接顺序不对，数值就会非常离谱。

排查方法：先写入一个已知值，比如把一个寄存器写成100，另一个写成200，然后看PLC读回来的数据在缓冲区里怎么排列。确定顺序后，在程序里用联合体或者移位拼接即可。

4.3 常见问题速查表

整理了一张速查表，基本覆盖Modbus RTU调试中遇到的大部分问题：

4.4 几条独家调试心得

我每次调试都先用Modbus Slave在桌面上把通讯逻辑完全跑通，再拿真实设备测试。不是不相信设备，而是减少变量——桌面上环境可控，真到现场，变频器参数、接线、干扰全是变量，出了问题很难快速定位。

另外，程序里一定要做超时和错误处理。Modbus通讯一旦出问题，如果程序不处理，可能一直卡在某个请求上，后面的逻辑全部瘫痪。我的做法是：每个功能块都监控Done和Error，Error发生，或者超过设定时间没有Done，就重新初始化当前步骤，同时给一个“通讯故障”的报警，让操作员能第一时间知道。

再分享一个小技巧：调试时在PLC程序里加两个计数器，“通讯次数”和“错误次数”，通过触摸屏或监控表观察这两个值的变化。如果通讯次数稳定增长、错误次数为0，说明链路是健康的。如果错误次数在悄悄增长，说明有问题但被重试掩盖了。这种“隐性错误”很多时候比“完全不通”更阴险，计数器一加，问题立刻显形。

我在实际使用中发现，只要把接线、参数、报文这三个层面逐个确认清楚，Modbus通讯调试基本不会卡太久。这也是我每次做跨设备通讯时固定走的流程：先查线，再对齐参数，最后看报文。按照这个顺序走下来，汇川PLC和任何支持Modbus的设备打配合，都不会是难事。

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