汇川InProShop中Modbus RTU与Modbus TCP的配置与选型指南

开头先聊一个我经常被新手问到的场景手里一台汇川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接AB接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到2470是广播地址正常通讯别填0。功能码3读保持寄存器功能码4读输入寄存器功能码6写单个寄存器功能码16写多个寄存器。别把读请求当成写请求发。pData指向的数组长度一定要够读10个寄存器至少声明ARRAY[0..9] OF WORD少了会越界。读请求不要每个扫描周期都持续置TRUE用上升沿触发否则会一直刷新干扰主站和从站之间的正常节奏。InProShop里还支持Modbus串口从站模式。如果PLC要当从站被上位机或者触摸屏读取那就实例化一个从站块把从站站号、寄存器映射区配置好就行。从站模式往往用在“PLC和视觉系统配合、视觉当主站来找PLC要数据”的场合。2.4 RTU现场调试清单如果你配置完了但通讯不通按下面顺序查绝大多数问题就出在这里用万用表量A、B两线看有没有接反。看波特率、校验位、数据位、停止位和从站是否一致。看站号是否与从站设置一致有没有重复站号。短距离测试时不要接终端电阻长距离测试时记得接上。用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.xPLC却是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 关键参数对比表两种方式我列一张表大家看得比较直观对比项Modbus RTU串口Modbus TCP网口物理连接RS232/RS485两芯或三芯线网线超五类及以上通讯速率常见9600、19200、115200bps10/100Mbps上限高得多最大从站数量32个常见限制取决于驱动能力理论上受IP地址空间限制传输距离RS485可达1200米低波特率单段网线100米加交换机扩展接线复杂度中需要A/B线、终端电阻低插上就能通抗干扰能力受布线影响大长距离要谨慎网络隔离相对好配置复杂度需匹配波特率校验位等多组参数只需要IP和端口调试工具串口调试助手类工具Modbus Poll、Wireshark典型设备对接变频器、伺服、温控表、仪表上位机、视觉系统、网关、触摸屏从表里可以看出来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只要从站不响应我有一套固定排查顺序看主站有没有发出请求。用Modbus Poll或者抓包工具确认请求帧是否正常发出去。如果根本没发出去问题在主站程序。看从站有没有收到请求。这个需要看从站侧的通讯指示灯或者从站软件里的通讯统计。看请求内容对不对。功能码、寄存器地址、数据格式有一项不对从站就会报异常码甚至直接不应答。这套顺序之所以有效是因为它把问题边界从“整个链路”缩小到“主站、从站、报文”三个环节。多排查几次你就有了肌肉记忆。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本质上不是技术难度问题而是工程条件问题把设备、距离、数据量这三个变量想清楚答案自然就有了。