前两天帮客户调试了一条自动上下料产线核心设备是汇川六轴机器人和一台PLC。现场要传的东西特别多机器人到位信号、夹具夹紧完成、运行模式、报警代码、当前坐标、循环计数……如果全拉硬线控制柜里得多出几十根线查线都够喝一壶的。我跟设备厂家说这种多数据、多状态实时交换的场景别犹豫直接用ModbusTCP。等把通信真正打通、程序跑顺之后我发现这个案例特别典型参数配置、寄存器映射、报文调试、故障排查每一步都有坑。今天这篇就把整个流程完整拆出来从网络规划到机器人侧配置再到PLC侧编程和现场调试一次讲透。1. 项目背景与方案选型为什么是ModbusTCP做工业通信这么多年我越来越觉得选型不是越高级越好而是越适合越好。这个案例就是个典型场景汇川机器人和PLC之间要交换的数据量不算特别大但类型杂、实时性要求不算苛刻现场也没有专用的工业总线硬件支持。1.1 这个案例到底要解决什么问题先还原一下现场工况。产线是一台汇川六轴机器人负责上下料机器人旁边有一台PLC控制着输送线、气缸夹具和几个报警灯。机器人从料盘抓料放到加工位等待加工完成后再抓回来放回料盘。这个过程中机器人需要知道的信息有输送线是否就位、夹具是否夹紧、允许启动信号是否给出、当前是自动模式还是手动模式。PLC需要知道的信息有机器人是否已抓料完成、是否已放料完成、当前坐标、当前报警代码、循环次数、机器人是运行中还是空闲。如果只靠IO硬接点最简单的启动、停止、急停、到位这些信号少说也要十几路。再加上坐标数据、报警代码这些数值型信息IO方案根本没法传。而且现场控制柜到机器人柜之间要走线槽多一根线就多一份施工和排查成本。所以这个案例的核心需求是用一根网线把开关量信号和数值型数据一起打包传过去而且要稳定、要能诊断、要方便以后的扩展。1.2 ModbusTCP相比IO硬线和专用总线的优势ModbusTCP本质上就是把传统的Modbus协议跑在TCP/IP网络之上端口固定是502。它跟硬接线的对比很直观硬接线是“一根线一个信号”ModbusTCP是“一根网线传一堆信号”而且信号的增加和修改只需要改程序不用改线。跟Profinet、EtherCAT、CC-Link这些工业总线比ModbusTCP最大的优势是通用性。这些专用总线通常要求PLC侧和机器人侧都具备对应的硬件接口和授权而且不同品牌之间的组态兼容性经常让人头疼。ModbusTCP只要两边都带标准以太网口就能互通汇川机器人的控制柜标配网口PLC更不用说了几乎每一款都带以太网接口。再有一个容易被忽视的点ModbusTCP的报文结构是明文可抓包的调试时用Wireshark或者Modbus Poll就能直接看到报文内容和错误码对现场排查问题非常友好。我见过不少人调Profinet的时候只能依赖厂家工具而调ModbusTCP基本是“所见即所得”。当然ModbusTCP也不是万能的。它的实时性不如EtherCAT这种硬实时总线不能用于运动控制级别的同步。但在机器人做“动作级协调”这个场景下PLC给机器人发个“启动”指令机器人回传“运行中”状态几百毫秒的响应时间完全够用。选型的关键就是认清需求边界。2. 硬件连接与网络规划ModbusTCP通信第一步不是写程序而是把物理链路和网络参数规划好。很多人上来就写指令结果连不通回头一看IP地址都错了白白浪费时间。2.1 设备清单与基本连接方式这个案例用到的设备其实非常简单汇川六轴工业机器人一套包含机器人本体和控制柜汇川H5U系列PLC一台带以太网口支持ModbusTCP客户端工业交换机一台如果只连一台PLC和一台机器人也可以不用交换机直接用网线把控制柜网口和PLC网口对接编程电脑一台用来给PLC下载程序和调试普通超五类或六类网线若干建议用带屏蔽层的工业网线连接方式有两三种我说下最常见的接法机器人控制柜的LAN口出来接到工业交换机PLC的以太网口也接到交换机编程电脑同样接到交换机上。这三个设备在同一个局域网内互相之间都能通信。如果现场就机器人和PLC两台设备直接用一根网线对接也完全可以但我个人还是建议加交换机因为调试时电脑也要接入网络后续还会扩展触摸屏或者上位机。2.2 IP地址规划的几个原则IP地址规划是整个项目里最不起眼但最容易出问题的环节。我见过有人把PLC和机器人设成同一个IP折腾半天找不到原因。规划时坚持几个原则所有设备在同一个网段比如都用192.168.1.x子网掩码统一255.255.255.0。每个设备的IP固定并且记录到项目台账上尽量不要用DHCP动态分配因为设备重启后IP变了通信就直接断了。端口号默认用502除非特殊情况不要去改它。给网络预留扩展空间比如192.168.1.1到192.168.1.20留给人机界面、上位机、打印机这类设备192.168.1.50之后留给现场设备。这个案例我实际规划的地址是这样的设备IP地址端口角色汇川机器人控制柜192.168.1.10502ModbusTCP服务端从站ServerPLC汇川H5U192.168.1.20502ModbusTCP客户端主站Client编程调试电脑192.168.1.100自动工具这里有个角色概念要特别说清楚在这个案例里机器人侧打开ModbusTCP服务器功能PLC作为客户端主动去连接机器人。这样的好处是PLC掌握通信主动权通信周期由PLC扫描决定机器人侧只需要保证服务端在线即可。如果你反过来让机器人主动连PLC也可以但汇川机器人目前多数型号的ModbusTCP服务端功能更成熟稳定所以一般让PLC做客户端更省事。3. 汇川机器人侧参数配置全流程机器人侧的ModbusTCP配置是整个项目最先要做的事因为它是通信的服务端服务端没准备好客户端连上来也是白搭。3.1 在示教器上开启ModbusTCP服务汇川机器人的示教器操作逻辑和大多数工业机器人品牌类似都是在系统参数或通信设置里找网络相关的配置项。不同软件版本的菜单名称会略有差异但核心设置项是固定的。我以现场接触到的汇川机器人系统为例操作路径大概是示教器主菜单 → 系统参数 → 通信设置 → 网络服务然后找到ModbusTCP的开关选项。这里要配置的参数有四个使能ModbusTCP服务设为打开相当于告诉机器人“我要在这个端口上等别人来连我”。本地IP地址填192.168.1.10必须和PLC在一个网段。子网掩码填255.255.255.0。端口号默认是502不用改。从站IDUnit ID一般填1或者255。这个值要记住后面PLC侧配置要填一模一样的。配置完成之后很多型号需要重启服务或者重启机器人系统才能生效。建议保存参数后做一次完整的重启别嫌麻烦不然就会出现“明明配置了但PLC连不上”的诡异问题。提示如果你在现场遇到“配置了ModbusTCP但通信还是不通”的情况第一件事就是检查机器人的网络服务是否真的处于运行状态。有的示教器界面会显示服务状态服务没启动的话Ping都能通但502端口就是连不上。3.2 把机器人变量映射到Modbus寄存器开启服务只是第一步真正核心的工作是把机器人内部的系统变量、IO信号、位置数据映射到Modbus寄存器上。这一步决定了PLC能读到什么、能写入什么。在汇川机器人的ModbusTCP配置里一般会提供一张映射表你可以把不同的数据源绑定到不同的寄存器地址上。映射的数据源通常有几类系统变量类运行模式手动/自动、运行状态、报警代码、急停状态等。IO信号类机器人侧的数字量输入输出点比如机器人抓料完成信号、夹具到位信号等。位置类当前关节坐标、笛卡尔空间的X/Y/Z坐标、速度等。控制类PLC下发的启动指令、复位指令、暂停指令等。我建议把开关量信号和数值量信号分开管理。下面是一个现场实测非常稳定的映射方案寄存器地址PLC侧显示寄存器地址协议侧偏移数据类型读写属性数据含义40001016位无符号整数只读机器人状态字1空闲2运行4报警40002116位无符号整数只读机器人当前模式1手动2自动40003232位浮点高16位只读当前X坐标40004332位浮点低16位只读当前X坐标40005432位浮点高16位只读当前Y坐标40006532位浮点低16位只读当前Y坐标40007632位浮点高16位只读当前Z坐标40008732位浮点低16位只读当前Z坐标4010110016位无符号整数读写PLC下发控制字1启动2暂停4复位4010210116位无符号整数读写允许机器人抓取信号4010310216位无符号整数读写允许机器人放料信号这里要特别注意地址显示的问题PLC侧很多人习惯用40001这种“数据块偏移”的方式也就是实际协议报文里的地址偏移是0对应到PLC的数据映射里显示为40001地址偏移是1就显示为40002。而在机器人侧配置界面上填的通常是协议侧的偏移量0、1、2。两边差一个“1”的换算关系这是新手最容易踩的坑。我见过有人把机器人侧映射到地址1PLC侧也填40001结果读写一直错位查了半天才发现是地址对不齐。3.3 关于字节序的确认再补一个非常关键的细节32位浮点数的字节顺序。Modbus协议本身规定了一个字的内部字节顺序也就是一个16位寄存器内部先传高8位还是低8位而多个寄存器组合成32位浮点数时哪个寄存器是高16位、哪个是低16位协议里是没有强制规定的完全看设备厂家的实现。汇川机器人这边我实测过常用的映射模式下是“大端在前”也就是先高16位寄存器、再低16位寄存器。所以我在映射表里把X坐标放在40003高16位和40004低16位。如果你换一个品牌比如西门子和某些第三方网关设备顺序完全可能是反过来的。这个不要凭记忆写程序一定要在联调时用实际值验证一下。具体验证方法后面调试部分我会详细讲。4. PLC侧通信程序设计与实现机器人侧的服务器配置完之后重头戏就轮到PLC了。PLC作为ModbusTCP客户端要主动去连接机器人的502端口然后周期性地读写寄存器。这段代码写得好不好直接决定了通信是否稳定、程序是否好维护。4.1 PLC侧网络参数设置以汇川H5U为例先把以太网口的IP地址设置好。打开汇川的PLC编程软件在硬件配置里找到以太网口把IP地址设成192.168.1.20子网掩码255.255.255.0保存并下载到PLC。有一点要提醒H5U的以太网口既做编程口也做ModbusTCP通信口这两者的IP是同一个。所以你在软件里下载程序用的IP和通信用的IP是同一个不用额外分配但要确保下载程序和通信不在同一时刻抢断连接否则偶发性的断线可能会造成误报。4.2 调用ModbusTCP客户端功能块汇川H5U的指令库里包含了ModbusTCP通信的功能块常用的是MBUS_TCP_CLIENT。这类功能块本质上就是一个状态机负责建立TCP连接、发送Modbus请求帧、接收响应帧然后把状态和错误码反馈给用户程序。功能块的关键输入输出参数大概是下面几类REQ触发通信请求的上升沿信号。CONNECT连接使能信号一般上电后通过置位指令让它一直为真。IP_ADDR从站IP地址这里填机器的IP“192.168.1.10”。PORT端口号默认502。SLAVE_ID从站ID和机器人侧填的一致这里是1。FUNC_CODE功能码读保持寄存器是3写单个保持寄存器是6写多个保持寄存器是16。START_ADDR起始地址偏移量对应机器人侧映射表中的偏移量。LEN读取或写入的数据长度单位是字。DATA_ADDR本地数据缓冲区地址也就是读上来的数据要存放的地方或者要写出的数据所在的地方。下面是一段结构化文本的示意图描述了一个读请求的调用逻辑// 读机器人状态数据从地址0开始连续读8个保持寄存器 IF xReadTrigger THEN MBUS_TCP_CLIENT( REQ : xReadTrigger, CONNECT : xConnectEnable, IP_ADDR : 192.168.1.10, PORT : 502, SLAVE_ID : 1, FUNC_CODE : 16#03, START_ADDR : 0, LEN : 8, DATA_ADDR : pRobotDataBuffer, DONE : xReadDone, ERROR : xReadError, STATUS : dwReadStatus ); END_IF;要注意DATA_ADDR这里需要填的是PLC内部存储区的指针地址读上来的8个字会按顺序填进这个缓冲区。第0个字对应机器人状态字第1个字对应模式第2和第3个字组成X坐标浮点数以此类推。4.3 对字节序问题做一次程序修正如果机器人侧确认了是大端模式而PLC内部的小端处理机制不同读上来的32位浮点就可能是乱的。最稳妥的做法是不要依赖PLC的自动转换而是手动重组。比如读到的两个字低字是MB0高字是MB1那么真实的浮点数值应该是先取高字再取低字组合。我这里用ST写一个通用的小函数把两个16位寄存器合并成一个32位浮点FUNCTION_BLOCK FB_WordToReal VAR_INPUT wHigh : WORD; wLow : WORD; END_VAR VAR_OUTPUT rValue : REAL; END_VAR VAR dwTemp : DWORD; END_VAR dwTemp : SHL(TO_DWORD(wHigh), 16); dwTemp : dwTemp OR TO_DWORD(wLow); rValue : TO_REAL(dwTemp);如果你不确定机器人是哪种排列就在联调时读一组已知数值的坐标用Modbus Poll先看一眼原始字再根据显示结果决定要不要重组。别闷头写转换程序先确认真实报文。4.4 读写逻辑的程序结构建议通信程序不要一整段堆在一起最好分成几个功能块状态读取、控制字写入、连接管理、故障处理。我常用的结构是上电后先触发一次连接使能等待连接建立成功。建立一个周期任务比如每隔100ms触发一次读请求读取机器人状态寄存器组。控制字写入用触发式写比如PLC检测到启动按钮上升沿就给机器人控制字地址写1等机器人返回反馈后再操作别的逻辑。读和写最好不要同时在一个扫描周期里触发避免功能块状态机冲突。H5U的客户端功能块同一时间内只能处理一个请求你要等上一个请求的状态位Done或Error结束以后再触发下一个请求。这个“串行请求”的问题特别容易被新手忽略。我见过有人在一个程序里同时触发好几个MBUS_TCP_CLIENT功能块结果报文在PLC内部就乱套了一会儿读到对的数据一会儿读到错的数据。正确做法是做一个简单的轮询调度比如第一轮触发读状态寄存器读到Done后再触发写控制字完成后再等待下一个周期。这里给出一个简单的轮询状态机思路步骤动作转换条件0空闲等待周期定时器定时器到100ms1触发读状态寄存器功能码03Done或Error2写控制字功能码06或16Done或Error3回到步骤0等待下一个周期定时器到这样保证每一个时刻只有一个Modbus请求在网络上飞逻辑清晰也容易排查问题。4.5 超时和断线重连的处理ModbusTCP建立在TCP之上TCP连接的稳定性直接影响通信。机器人端如果重启了控制柜、或者网络短暂断开TCP连接就会断开此时PLC侧功能块可能会报错误状态。我建议做一个重连机制检测到通信功能块的Error位为真时把CONNECT信号复位延时2秒后重新置位触发重新连接。同时启动一个看门狗定时器比如如果超过500ms没有任何读取成功就认为通信故障置位报警位在触摸屏上提示“机器人通信中断”。但这里有一条底线必须讲清楚通信故障报警只能用来提示操作员绝对不能用它来替代安全回路。机器人急停、安全门状态这些信号必须用硬接线直接接入安全回路不能依赖ModbusTCP去传输。我在现场见过有人想让PLC通过通信去监控急停状态直接被设备验收方否了这个是原则性问题安全场合绝不能妥协。5. 数据验证与现场调试记录配置都做完、程序也写完剩下的就是验证和调试。这一部分其实是最考验现场经验的地方。很多人前面一切顺利一到联调就卡住很大原因是调试方法不对没有把问题分层处理。5.1 用Modbus Poll先验证机器人侧我在联调时有一个习惯先不碰PLC程序先用电脑上的Modbus Poll工具直接连接机器人验证机器人侧的服务端配置和寄存器映射是否正确。Modbus Poll是Modbus主站模拟工具你只需要在工具里填从站IP、端口、从站ID和功能码就能直接读取机器人的寄存器。比如我填IP 192.168.1.10、端口502、从站ID为1、功能码03、起始地址0、长度8如果数据能正常读出来说明机器人侧服务端完全正常。如果在这里就读不到那问题一定在机器人侧没必要去查PLC程序。这一步的目的是把机器人侧和PLC侧的问题隔离。先用工具验证服务端再单独验证PLC两边都确认没问题最后才联调。按照这个顺序排查可以把问题范围缩小至少一半。5.2 坐标数据的实测验证过程再演示一下坐标浮点数的验证过程。我先在机器人示教器上手动把机器人移动到第一个点位记下示教器上显示的X坐标比如是350.5毫米。然后用Modbus Poll读取地址2和地址3对应的两个寄存器原始值。假如读出来的是0x43AF4000这样一串十六进制我心里大概就有数了——这正好是浮点数350.5的IEEE754表示。如果读出来的两个字完全是乱的那就要检查映射地址是否错位、高低字顺序是否符合预期。确定数据格式之后再打开PLC侧的监控表查看程序中存放坐标数据的内部寄存器值是否和Modbus Poll读出来的一致。如果一致说明PLC的读取链路是通的如果不一致检查DATA_ADDR指向的缓冲区地址是否填写正确。整个验证过程就是“三层对照”示教器显示值、Modbus Poll读取值、PLC内部缓冲区值三层全部对上才说明通信链路是真的通了。5.3 常见故障排查速查表调试过程中我遇到了不少问题也帮客户排查过各种奇葩故障整理成一张速查表现场可以直接对照处理。故障现象可能原因处理方式Ping机器人IP不通网线松动、IP不在同一网段、机器人网口未启用先Ping不通就查物理连接和IP配置Ping通但502端口连接不上机器人ModbusTCP服务未开启、服务被防火墙拦截检查示教器中服务状态重启服务连接建立成功但读数据超时从站ID不一致、功能码不支持、起始地址越界核对从站ID和地址偏移量数据能读但数值明显不对字节序不对、高低字顺序反了、地址错位用Modbus Poll查原始值手动确认数据偶尔变一次偶尔不对多个Modbus请求并发功能块状态冲突改成轮询串行请求一个请求完成后再发下一个机器人重启后通信恢复不了PLC没有重连机制TCP连接断了就回不来增加CONNECT复位和延时重连逻辑写入命令没有生效目标寄存器属性是只读、写的数据长度不对检查机器人侧映射表中该地址是否允许写入5.4 关于“寄存器读写一次成功”的坑最后再说一个非常典型的坑第一次读写成功不代表整个通信程序就没问题了。ModbusTCP通信的特点是连接建立后的第一次读写往往都会成功但如果后面出现了非正常的网络断开比如机器人侧断电重启、交换机掉电连接状态就不能自动恢复。这时候即使物理链路已经恢复正常TCP连接还是处于半开状态PLC会一直报超时。解决这个问题的核心就是重连机制但这需要分情况设计。如果机器人只是一个从站被动被读取那PLC端主动重连就能解决如果机器人和PLC之间有互相写入的逻辑尤其是机器人侧偶尔会往PLC里写状态两边都要做好连接异常后的恢复逻辑。我的经验是把连接管理脚本做成一个独立功能块任何通信异常都先复位连接等待稳定后再重新建立宁可慢一点重连也不要一直卡在异常状态里。这样处理下来从设备断电重启到通信自动恢复的实际时间大概在3到5秒产线和设备验收方都能接受。6. 一点实操体会这个项目做下来最大的感受是ModbusTCP通信本身不难难的是把“通信”这件事放到整个设备的运行逻辑里去考虑。机器人和PLC通过ModbusTCP连起来只是第一步真正考验功力的是如何设计寄存器映射表、如何处理通信异常、如何规划读写周期让通信在长期运行中保持稳定可靠。个人建议任何一个新项目开始之前第一件事就是拉一张寄存器映射表把地址、数据类型、读写属性、信号含义全部列出来让机器人工程师和PLC工程师同时确认签字再开始写程序。这张表就是双方协作的契约后续所有的调试和排错都以它为基准。如果中间有修改一定要同步更新这张表并保留版本记录否则两个月后再回来维护谁都不记得哪个地址是什么信号那才是真正的灾难。另外一个小经验机器人和PLC通信的项目第一次联调之前先用Modbus Poll把机器人侧的数据全部验证一遍存档一份正常数据快照。这样一旦后面通信出问题可以快速对照到底是机器人侧数据变了还是PLC侧程序改了问题定位会快很多。这些都是在现场吃过亏之后才养成的习惯写出来供大家参考。