企业官网建设流程全解析

开头先聊一个我经常被新手问到的场景：手里一台汇川H5U或者AM系列的PLC，要跟旁边的变频器、伺服、温控表或者视觉系统交换数据，对方开口就说支持Modbus。但真到InProShop里一打开库，很多人就懵了——又有Modbus RTU、又有Modbus TCP，到底用哪个？配串口还是配网口？如果选错了，小则多绕弯，大则整个方案推倒重来。这篇文章我不给你绕圈子，直接把两种实现方式的配置流程、代码写法、硬件区别、选型逻辑一次说透，新手看完能直接上手。

1. InProShop和Modbus的基本盘：先把“两条路”看清再动手

1.1 InProShop到底是什么

先说个很多人容易忽略的背景：InProShop本质上是一套基于Codesys内核开发的汇川编程环境，覆盖H5U、AM系列等。这意味着你之前在其他Codesys平台积累的不少经验，在InProShop里是能迁移的，尤其是通讯库的设计思路。

但InProShop不是简单地把Codesys原封不动搬过来，汇川在驱动库、轴控、内部变量映射上都做了自己的封装。Modbus这块同样如此，底层逻辑和通用Codesys一致，但你实际在库管理器里看到的块名称、引脚定义会有汇川自己的痕迹。所以如果你网上搜到的教程是西门子或者倍福的，可以参考原理，不能照抄引脚。

1.2 Modbus的主从机制一句话讲完

所有Modbus通讯，不管RTU还是TCP，核心都是同一套主从问答机制：主站发请求，从站回响应。主站通常是PLC或者上位机，从站是变频器、伺服、仪表、IO模块这些设备。主站去读从站的寄存器，或者往从站的寄存器里写值，从站本身不会主动往主站发数据。

打个比方，主站像项目经理，从站像执行员工。项目经理问一句“你干到哪了”，员工回答；项目经理说“把速度改成500转”，员工执行并回一句“改好了”。Modbus干的就是这件事。寄存器地址就是“干到哪了”这个问题的编号，功能码就是“读”还是“写”这个动作。

1.3 两条路：RTU走串口、TCP走网口

回到标题里的“两种方式”。在InProShop环境下，实现Modbus通讯最常见也最该先掌握的两条路是：

• Modbus RTU：物理层走RS232或者RS485串口，报文是二进制字节流，一条总线上可以挂多个从站，靠站号区分。
• Modbus TCP：物理层走以太网，直接用网线或者交换机连接，报文被封装在TCP/IP包里，端口默认502，靠IP地址加单元号区分设备。

这两条路的协议报文核心内容是同一套，但载体完全不同。这就导致它们在接线方式、参数配置、调用代码、排错方法上都不一样。下面我分两条路详细讲配置和代码，新手建议按顺序看。

2. 方式一：用RS485把Modbus RTU跑起来

2.1 硬件接线：关系到整个通讯成败的第一步

Modbus RTU最常见的物理层是RS485，两线制，A和B（有些地方标D+、D-，也有的标485+、485-）。接线注意三点：

• A接A，B接B，不能交叉。这个听起来简单，现场至少有三分之一的不通讯是因为A、B接反了。
• 通讯距离超过几十米或者从站数量多，总线两端要并接终端电阻，通常120欧姆。不要每个设备都接，只在最远的两端接。
• 总线上所有设备的参考地尽量拉通，否则共模电压过大，轻则通讯不稳定，重则烧通讯芯片。

如果你用的是H5U本体的串口，或者AM系列CPU上的COM口，线序查一下对应硬件手册，别凭经验猜。很多汇川设备的COM口是DB9或者端子排，定义不一样。

2.2 InProShop上的通讯初始化

在InProShop里跑Modbus RTU，首先得把串口“装载”出来。从站方式还算简单，主站方式需要先建立一个通讯句柄。不同版本里块名称略有差异，但逻辑离不开这几步。

// 1. 装载串口，生成通讯句柄 fbCommLoad( xEnable := TRUE, sPort := 'COM1', // 具体用哪个口，看硬件手册按通道号选 dwBaudrate := 9600, // 波特率必须和从站一致 wParity := 0, // 0无校验 1偶校验 2奇校验 wDataBits := 8, wStopBits := 1, wTimeout := 1000, xDone => xComLoadDone, xError => xComLoadError, hComm => hComm // 输出句柄，后面主站块要用 );

串口参数里，波特率、校验位、数据位、停止位四项必须和从站侧完全一致，有一点不一致就是连不通或者收乱码。跟从站参数对不上时，优先把从站侧的拨码或者调试软件截图调出来核对。

2.3 主站请求怎么写

通讯句柄建好之后，实例化一个Modbus主站块，把句柄传进去，然后发起读写请求。后面这个请求块的引脚逻辑，基本是所有Modbus通讯里最核心的部分。

// 2. 启动主站 fbModbusMaster( xEnable := TRUE, hComm := hComm, xError => xMastError ); // 3. 读保持寄存器，例如从站地址1，寄存器起始100，连续读10个 fbReadReq( xExecute := xTrigger, // 上升沿触发一次读请求 wUnitID := 1, // 从站地址/站号 wFunction := 3, // 03功能码=读保持寄存器 wStartAddr := 100, // 起始寄存器地址 wQuantity := 10, // 读取数量 pData := ADR(aReadData), // 读取结果存放数组 xDone => xReadDone, xError => xReadError );

这里有几个关键点新手容易踩：

• 站号是1到247，0是广播地址，正常通讯别填0。
• 功能码3读保持寄存器，功能码4读输入寄存器，功能码6写单个寄存器，功能码16写多个寄存器。别把读请求当成写请求发。
• pData指向的数组长度一定要够，读10个寄存器至少声明ARRAY[0..9] OF WORD，少了会越界。
• 读请求不要每个扫描周期都持续置TRUE，用上升沿触发，否则会一直刷新，干扰主站和从站之间的正常节奏。

InProShop里还支持Modbus串口从站模式。如果PLC要当从站，被上位机或者触摸屏读取，那就实例化一个从站块，把从站站号、寄存器映射区配置好就行。从站模式往往用在“PLC和视觉系统配合、视觉当主站来找PLC要数据”的场合。

2.4 RTU现场调试清单

如果你配置完了但通讯不通，按下面顺序查，绝大多数问题就出在这里：

1. 用万用表量A、B两线，看有没有接反。
2. 看波特率、校验位、数据位、停止位和从站是否一致。
3. 看站号是否与从站设置一致，有没有重复站号。
4. 短距离测试时不要接终端电阻，长距离测试时记得接上。
5. 用Modbus Poll或者串口调试助手抓报文，看主站有没有发出请求帧，从站有没有回应帧。

3. 方式二：用网口把Modbus TCP调通

3.1 网络准备

Modbus TCP就简单多了，物理上就是一根网线的事情。PLC和从站直连，或者通过交换机接到同一个局域网。

IP地址设置是重点。PLC和从站的IP必须处在同一个网段，比如PLC是192.168.1.10，从站是192.168.1.20，子网掩码都是255.255.255.0，这样才能通。很多新手连不上，是因为从站出厂默认IP是192.168.0.x，PLC却是192.168.1.x，两个网段根本不通。

我也建议先不要给网口设太复杂的VLAN或者跨网段路由，调试阶段能不改就不改。简单直连最稳。

3.2 InProShop里怎么配置TCP客户端

在InProShop里做Modbus TCP主站，核心是使用Modbus TCP库。同样先用一个块描述通讯对象，再实例化客户端，最后发请求。

// 1. 填充目标从站的网络参数 hTcp.sua := '192.168.1.20'; // 从站IP地址 hTcp.usiPort := 502; // Modbus TCP默认端口 // 2. 实例化客户端并连接 fbClient( runMode := 1, // 1表示客户端（主站） communication := hTcp, pResult := ADR(xCommReady) );

连接建立后，读写请求的写法跟RTU大同小异，区别就在于你不再需要关心波特率和校验位，而是要在请求里指定从站的单元号。

// 3. 读从站保持寄存器 fbTcpRead( xExecute := xTrigger, wUnitID := 1, // 从站单元标识，一般默认1 wFunction := 3, wStartAddr := 0, wQuantity := 10, pData := ADR(aTcpReadData), xDone => xTcpReadDone, xError => xTcpReadError );

这里特别注意，Modbus TCP报文里因为有了IP寻址，一个从站在请求里的“单元号”实际上不像RTU那样起决定性作用。但很多从站设备在TCP模式下仍然要求你把单元号填成1，否则拒绝响应。

3.3 InProShop里做TCP服务器端的情况

如果你需要PLC作为Modbus TCP服务器，也就是让上位机、触摸屏或者第三方主站来读PLC的数据，那会在InProShop里放一个服务器功能块，然后配置端口映射，也就是把Modbus寄存器地址映射到PLC的实际变量区。这种方式在汇川AM系列里用得不少，尤其是视觉系统要跟PLC交换数据时，视觉做主站、PLC做从站。

一个注意事项：PLC做了服务器之后，它同时还能做客户端去读别的设备。这个不冲突，前提是你的网口数量足够，或者用逻辑上的多连接管理。H5U和AM系列对连接数都有上限，具体查手册，别等到现场接线接完了才发现连接数不够。

3.4 TCP调试的实用技巧

Modbus TCP调试比RTU舒服太多，因为你可以用软件直接模拟：

• 用Modbus Poll模拟TCP主站，填对IP和端口就能发起请求，看PLC从站回不回。
• 用Modbus Slave模拟TCP从站，验证PLC主站发的请求是否正确。
• 在电脑上用Wireshark抓包，直接看报文内容，连不上时一眼就能看出TCP三次握手有没有成功。

不过用Wireshark不要被吓到，你只需要关注两点：握手有没有建立，Modbus功能码和寄存器地址对不对。只要能够看到有请求发出且有响应回来，通讯就是通的。

4. 我看到的两路通讯核心对比

4.1 关键参数对比表

两种方式我列一张表，大家看得比较直观：

从表里可以看出来，RTU更“工业”，走的远，适合分布在现场各处的仪表和设备；TCP更“现代”，速度快、配置简单，适合跟上位机、视觉、MES这些有以太网接口的系统对接。

4.2 各自真正的“舒适区”

RTU的舒适区是：设备多且分散，距离几十米以上，设备本身只有串口没有网口，预算有限。像现场十几台变频器挂一条485总线，用站号区分，成本低得感人，而且很稳定。

TCP的舒适区是：设备已经具备以太网接口，或者你的数据量比较大、刷新频率要求高。比如视觉系统的结果输出、上位机MES的数据采集、多台PLC之间的以太网通讯，这些用TCP明显顺手。TCP还有一个优势是网络扩展方便，一台交换机轻松多设备管理。

5. 新手到底怎么选：选型建议与判断标准

5.1 几个实际判断标准

我给新手的建议，不要一开始就问“哪种方式好”，先问自己下面几个问题：

• 从站设备支持什么接口？翻硬件手册，看看有没有RJ45网口，有没有RS485端子。设备是支持一种还是两种都支持。
• 通讯的数据量多大？如果只是状态、启停、频率给定这种几个字的量，RTU够用；如果每次要读上百个寄存器的数据，而且刷新要几十毫秒一次，TCP更合适。
• 布线距离多远？超过100米，用网线就吃力；RS485低波特率能跑更远。
• 现场环境有没有强干扰？变频器多、动力线缆密集，RS485布线要很小心；以太网线相对抗干扰能力更好，但也别和动力电缆捆在一起走线。

有个很实际的原则：从站只有串口就老老实实走RTU，别去折腾协议转换网关；从站有网口、距离又近，优先TCP。通讯方案越简单越不会出问题，加一个网关就是加一个故障点，这是我在现场验证过很多次的结论。

5.2 我经历过的两个项目选型实例

第一个项目，一个车间里9台变频器和一台汇川AM系列PLC通讯。所有变频器分布在车间不同角落，最远的离控制柜接近400米，变频器没有网口，只有485端子。当时我毫不犹豫选了Modbus RTU，一条485总线串下去，波特率9600，非常稳。要是硬上TCP，就得给每台变频器加网关，成本直接翻几倍。

第二个项目，一台汇川H5U和一套视觉检测系统配合。视觉系统出来的是以太网口，并且它自己要当主站，要把相机坐标和OK/NG结果写给PLC。这种情况下我选择让PLC做Modbus TCP服务器，视觉系统作为客户端来写寄存器。整个过程走网线，没有485转接头那些麻烦，并且后续MES要读数据时，同一个以太网口再接一台交换机就解决了。

所以选择方式不是看“流行”什么，而是看你手里的设备和现场的工程条件。新手记住这句话，能少走很多弯路。

6. 现场踩坑记录：这些问题我全遇过

6.1 RS485接线引起的通讯不稳定

之前一套系统，PLC监控一台温控表，经常出现通讯会断几秒又自动恢复。排查半天，变频器启动时更容易触发。把两端的终端电阻接上后好了很多，但还有些小概率断连。最后发现是温控表到PLC之间将近100米的485线，中间有一段和电机电缆走在同一个线槽里，干扰耦合进去。后来把那一段485线移出来单独走管，通讯再没出过问题。

RS485看着简单，实际上线材、走线路径、接地处理都很讲究。新手如果碰到“时通时不通”的灵异问题，先怀疑布线和干扰，不要一上来就怀疑PLC程序。

6.2 TCP连不上但Ping得通

还有一个项目，PLC和一台触摸屏都支持Modbus TCP，但就是连不上。用电脑去Ping两个设备的IP都通，说明物理链路和IP都没问题，那问题就出在端口或者服务上。后来发现是触摸屏那边默认的Modbus TCP端口被改成别的，改成502就好了。如果你Ping得通但Modbus连不上，就把目光放在端口号、单元号和服务使能上。

还有一种常见情况：PLC的程序里已经把这个从站连接占用了，你再开一个新的连接去连同一个设备，部分从站会拒绝第二个连接。调试时记得先把旧的连接断掉，或者在PLC程序里只保留一个客户端实例。

6.3 从站不响应的“三板斧”排查法

不管是RTU还是TCP，只要从站不响应，我有一套固定排查顺序：

1. 看主站有没有发出请求。用Modbus Poll或者抓包工具确认请求帧是否正常发出去。如果根本没发出去，问题在主站程序。
2. 看从站有没有收到请求。这个需要看从站侧的通讯指示灯，或者从站软件里的通讯统计。
3. 看请求内容对不对。功能码、寄存器地址、数据格式，有一项不对，从站就会报异常码甚至直接不应答。

这套顺序之所以有效，是因为它把问题边界从“整个链路”缩小到“主站、从站、报文”三个环节。多排查几次，你就有了肌肉记忆。

6.4 两条路混用时的注意事项

有的项目会同时存在RTU和TCP通讯。比如PLC一边通过RS485总线采集现场仪表，一边通过以太网跟上位机交互。这种情况下，两条路互相独立，并不冲突。但要注意：串口通讯的扫描周期会影响整个PLC的任务周期，如果你把RTU读请求放在一个执行频率特别高的任务里，可能把主站块的处理时间拉长，间接影响TCP那边的实时性。

我的做法是，把RTU轮询的通讯程序单独放在一个定时任务里，不要跟运动控制或者其他高速逻辑混在一起。轮询间隔也适当放宽，比如每100ms或者200ms轮一次，大多数工艺场合是足够的。

还有一点，现场两台设备做测试时，如果RTU和TCP同时调试，最好先调通一路再去调另外一路，不要两个一起开着到处查，那样出了问题不好定位。先把简单的调通，再处理复杂的。

最后再分享一个实用技巧

我自己在InProShop里做Modbus通讯调试时，习惯在程序里专门做一个“调试页面”，把主站块和请求块的错误码全部映射到HMI上显示。这样在触摸屏上就能直接看到是连接失败、从站无响应还是功能码异常。等设备稳定运行后再把这些页面删掉或者隐藏，不影响正式程序。这个习惯帮我省掉了非常多次拿电脑现接现查的过程，同等条件下我排查通讯问题的速度比很多同事快得多。

如果你刚开始接触汇川的Modbus通讯，建议先用一个最简单的例子跑通：一台PLC加一个Modbus Slave软件作模拟从站，先试RTU，再试TCP，把两种方式各自跑一遍。跑通之后，你的心里就有底了，之后不管是接变频器、伺服还是视觉系统，思路都是一样的。选RTU还是选TCP，本质上不是技术难度问题，而是工程条件问题，把设备、距离、数据量这三个变量想清楚，答案自然就有了。