汇川机器人与PLC通信这件事我最早是在一条自动化产线上被逼着搞明白的。当时项目进度已经卡到交付节点现场机器人要跟产线主控做数据交换设备厂家给的手册翻到发黄上面写支持ModbusTCP可真到要配置从站地址、映射寄存器、对齐字节序的时候各种坑接踵而至。后来跑通了再回头看汇川机器人通过ModbusTCP和PLC通信其实是一条特别成熟的路径只要把协议层面的几个关键点捋清楚配置过程完全可以做到一次成功。这篇博文就把我实测过的完整案例拆开讲从组网规划到寄存器映射再到报文排查和现场抗干扰覆盖你从零开始要做到稳定运行的每一步。适合刚接触汇川机器人集成、或者对ModbusTCP通信只停留在听过没用过阶段的电气工程师和自动化调试人员也适合手里正拿着手册但不知道从哪下手的现场朋友。1. 通信方案的整体设计与选型思路1.1 为什么选ModbusTCP而不是其他协议汇川机器人控制柜本身支持多种以太网通信方式包括ModbusTCP、EtherNet/IP、Profinet等。但在很多中小型项目中ModbusTCP反而是最务实的选择。原因不复杂ModbusTCP协议栈在PLC和机器人两端都有极其成熟的实现几乎所有主流PLC西门子、三菱、欧姆龙、汇川自家H系列都原生支持不需要额外购买通信模块或授权。而且它是基于标准TCP/IP的协议调试工具极其丰富一台笔记本装个Modbus Poll就能把通信问题看得明明白白。相比之下EtherNet/IP需要EDS文件Profinet需要GSDML文件这些文件的配置和版本匹配在跨品牌设备互联时经常出幺蛾子。ModbusTCP的报文格式简单到可以手工拼写排查问题时能省下大量精力。我在现场见过不少工程师用Wireshark抓包分析ModbusTCP报文几个关键字段一看就定位到问题这种透明性是其他协议很难比的。从成本角度看ModbusTCP不需要额外硬件网线直连或者通过交换机组网即可PLC侧不需要加通信模块机器人侧只需要在示教器上勾选启用。整体投入几乎为零特别适合预算敏感又要求快速交付的项目。1.2 组网结构与地址规划标准的汇川机器人PLC ModbusTCP组网有两种方式一种是PLC和机器人控制柜通过网线直连适合通信距离短、只有一组设备的场景另一种是两者都接到工业交换机上适合多设备组网、后续要扩展传感器或上位机的场景。实际项目里我优先推荐走交换机原因在于直连虽然省一个交换机但调试时笔记本要抓包分析就得反复拔插网线非常痛苦。接交换机后笔记本、PLC、机器人三个设备在同一网段随时可以并行监控。地址规划是整个通信方案的灵魂。我在第一个项目里吃过亏PLC侧和机器人侧的网络地址不在同一网段导致通信一直建立不起来。后来规范成固定套路PLC设为192.168.1.10机器人控制柜设为192.168.1.20子网掩码统一255.255.255.0笔记本调试地址设为192.168.1.100。这样默认网关都不用配三层交换机都不需要纯二层网络就能跑得很稳。端口号方面ModbusTCP标准端口是502汇川机器人也是用这个默认端口。需要注意的是一台PLC如果同时跟多台机器人通信每台机器人的IP地址不同即可端口可以保持一致。如果PLC上还有其他服务占用502端口那就需要改机器人侧的自定义端口同时PLC侧的连接参数也要跟着改两边必须严格一致。1.3 通信数据量的评估与寄存器区划分在设计通信方案时第一步就要想清楚到底要传什么数据。机器人发给PLC的主要是运行状态、报警代码、当前坐标、程序行号、完成信号等PLC发给机器人的主要是启动命令、暂停命令、复位命令、目标坐标或工艺参数等。把这些数据整理成一个数据表列清楚信号名称、数据类型、数据方向、更新频率然后才能确定寄存器区怎么划分。汇川机器人的ModbusTCP从站功能里寄存器的规划逻辑跟标准Modbus协议一致输入寄存器3x区域用于机器人向外部输出数据保持寄存器4x区域用于外部向机器人写入数据。线圈和离散输入的用法相对少一些但汇川也支持可以用来传输开关量信号。实际项目里我习惯把连续的寄存器块按照功能分段例如保持寄存器区分配为0到49为控制命令区50到99为参数设定区输入寄存器区分配为0到49为状态反馈区50到99为运行数据区。这样PLC编程时地址直观后续维护也方便。寄存器数据量的估算有个简单公式每个16位寄存器可以承载一个整型数据两个连续寄存器可以拼接成一个32位数据。如果机器人的坐标值需要精确到小数两种方案可选一种是PLC和机器人约定将数值乘以10或100后以整数传输另一种是用32位浮点数拆分到两个寄存器。前者通信效率高、程序简单后者精度高但占用寄存器多。大部分工艺场景用第一种方案就够了比如位置误差在0.1毫米内可以接受的话乘以10传整数完全没问题。2. 核心细节解析与实操配置要点2.1 汇川机器人侧的参数配置汇川机器人侧启用ModbusTCP从站功能的入口在示教器的系统配置里不同型号的界面文字略有差异但核心参数是一致的。关键要配置的有三项本地IP地址、端口号、从站站号。站号在ModbusTCP里其实不影响通信寻址因为是IP寻址但很多PLC组态软件会要求填写所以建议固定设为1避免后续排查时产生混淆。启用从站功能后要紧的是理解寄存器映射关系。汇川机器人把PLC想要读写的地址映射到内部的变量区映射的核心是地址偏移和通道方向。在机器人端配置界面里每个映射条目的含义是外部PLC访问的寄存器地址X对应机器人内部的变量Y。这里的变量Y可以是位置数据、状态字、命令字也可以是用户自定义的整形变量。配置完成后PLC的读写操作实际就是在操作这些内部变量。我在配置时有个习惯先把所有要交互的变量在机器人侧的用户变量表里定义好数据类型统一用整数部分型号支持浮点但映射规则不同然后再做寄存器映射。这样逻辑清晰不容易出现地址错位。需要注意汇川机器人的寄存器地址是从0还是从1开始不同协议版本可能有差异标准Modbus的保持寄存器地址是从0开始的如果PLC侧用地址40001表示第1个保持寄存器那对应机器人侧的寄存器0这个对应关系必须理清楚。2.2 PLC侧的通信组态与地址映射PLC侧以汇川自家H5U系列为例西门子和三菱的逻辑类似组态ModbusTCP客户端时建立一个ModbusTCP主站连接填上机器人的IP地址和端口号。连接建立后需要在PLC程序里调用Modbus通信指令。汇川的编程软件里一般提供MBUS_CLIENT或类似的功能块输入参数包括触发位、从站地址、功能码、读写地址、数据长度、数据缓冲区等。这里最需要细心的是功能码和地址的搭配。读机器人状态用03号功能码读保持寄存器但如果机器人端把状态数据放在输入寄存器区那就要用04号功能码读输入寄存器。我在项目里遇到过一次状态数据一直读不到查了半天才发现PLC侧用的是读保持寄存器而机器人端映射的是输入寄存器区两边不匹配数据通道完全对不上。PLC侧读写机器人数据时数据缓冲区往往是一个整数数组。数组元素的顺序和机器人寄存器映射顺序一一对应。配置映射时我强烈建议画一张映射表列清楚PLC侧地址、功能码、数据类型、机器人侧变量名、含义说明贴在配电柜门上或者存档到项目资料里。这张表在后续调试和运维中价值巨大能帮自己和后来者省掉大量翻手册的时间。2.3 以太网通信的字节序与数据对齐问题ModbusTCP通信里一个常见但容易被忽视的坑是字节序问题。标准Modbus协议规定寄存器传输时高字节在前、低字节在后大端序但不同PLC和机器人对16位寄存器内部两个字节的处理方式可能存在差异。特别是处理32位数据如浮点数或32位整数时两个寄存器的排列顺序各厂家定义不同有的低地址放高16位有的低地址放低16位不统一就导致数据解析出来完全不对。汇川和汇川PLC之间通信因为同源字节序基本是匹配的问题不大。但汇川机器人和西门子PLC之间通信时我遇到过浮点数高低字颠倒的情况。解决办法是提前确认两边的字节序定义在PLC侧做字节交换或者调整寄存器读取顺序。这类问题用Modbus Poll这类调试工具最容易发现观察原始寄存器值比对实际数据一眼就能看出是高低位反了还是数值缩放错了。数据对齐还涉及一个细节机器人的位置数据、速度数据通常是以内部单位存储的不是毫米也不是度而是脉冲数或0.1度等工程单位。通信时输出的原始值可能是个很大的数PLC直接拿来用会把工艺参数算错。这就需要一份详细的单位换算表例如机器人关节角度实际值为寄存器值乘以0.001弧度这样的信息必须在设计阶段就确定并写进通信规格书里。不做这个换算定义通信调通了也只是传了一堆数离数据可用还差得很远。2.4 通信超时与诊断机制的设计通信搭起来之后下一步是考虑通信异常时的表现。ModbusTCP是请求响应模式PLC作为客户端发请求机器人作为从站回响应。但如果机器人控制柜因为急停、程序异常或网络中断而没有响应PLC侧要能快速感知并进入安全状态。默认的TCP连接超时时间往往太长现场调试时发现通信断了要等几十秒才能报警这在产线上是不可接受的。我一般的做法是把PLC侧的通信超时设定在500毫秒以内并且采用周期轮询而非事件触发的读写方式。通信失败或超时时立即置位通信故障标志程序里对这个标志做连锁保护。机器人侧同样建议开启通信看门狗功能如果在一定时间内没有收到PLC的请求机器人自动进入暂停或安全停止状态防止出现机器人还在动作而PLC已经失控的极端情况。这个双向看门狗机制是工业通信的保命底线。我在设计通信方案时无论项目大小都会要求加上。很多新手调试时只关注正常通信状态下数据对不对忽略异常状态下系统的行为这其实是隐患最大的地方。现场设备一旦通信闪断而没有任何保护轻则数据错乱重则设备碰撞损坏。3. 实操过程与核心环节实现3.1 直连测试与通信握手验证为了让整个调试过程可控我建议把通信调试分成两步走先用PC工具验证机器人侧从站功能再接入PLC做联调。第一步习惯用Modbus Poll工具在PC上模拟一个ModbusTCP主站填入机器人IP地址192.168.1.20端口502从站号1。连接测试的重点不是能连上就完了而是要验证机器人从站能正确响应不同功能码。我通常按顺序测试第1步读保持寄存器功能码03看返回的寄存器个数和数据是否符合预期第2步写单个保持寄存器功能码06写一个已知值再看机器人侧对应变量是否更新第3步测试写多个保持寄存器功能码16模拟PLC批量下发参数的情况。三步都通过说明机器人从站的基础功能正常底层的TCP服务和Modbus报文解析都没有问题。这个环节最容易遇到的问题就是连不上。排查思路很直接先ping机器人IP能通说明网络链路通再确认机器人控制柜的从站功能是否启用有些型号启用后需要重启控制柜才能生效最后看PC的防火墙是否拦截了502端口Windows防火墙经常是罪魁祸首。用Modbus Poll测试时如果请求发出后一直无响应优先检查控制柜的防火墙设置和从站服务状态。3.2 PLC通信程序的功能块封装与调用在PLC侧我不建议每次通信都写一堆指令满天飞。标准做法是封装一个通信管理功能块输入是机器人的连接参数和读写请求内部统一管理通信指令的调用、超时计数、错误码复位和状态输出。这个功能块在项目里复制到不同机器人只需要改IP地址参数大大减少重复编程的工作量。以汇川H5U为例通信功能块内部包含一个执行状态机空闲、等待请求、发送中、等待响应、处理完成。触发位上升沿进入发送流程调用MBUS_CLIENT指令发送完成后读取执行状态和错误码根据结果输出通信完成或通信故障标志。每个通信周期之间加上足够的间隔防止请求过于密集导致从站来不及响应。我实测下来PLC扫描周期设置为5毫秒左右通信读写周期控制在50毫秒级别整个系统响应速度和稳定性都很理想。功能块里一定要把错误码收集起来。ModbusTCP的错误码包括通信超时、从站无响应、从站异常应答等把错误码映射成可读的文字说明在触摸屏上显示机器人通信超时或机器人返回异常应答现场维修人员不用翻手册就能定位问题。这个细节做得好能给后续维护省很多事。3.3 寄存器映射的批量读写与数据刷新策略通信数据量少的时候PLC可以逐条读、逐条写。但数据量一大比如一次要读20个状态数据、写10个参数就必须采用批量读写策略。批量读就是一次读连续的多个寄存器批量写就是一次写连续的多个寄存器。这样做的好处不仅是通信速度快更重要的是数据一致性批量读回的20个数据是机器人同一时刻的快照分开读则会因为时间差导致数据不同步对联动控制可能造成隐患。批量读写的关键是确保PLC侧的寄存器规划跟机器人侧的映射一致。我在实际项目中会在机器人侧专门开辟一个状态区连续的50个保持寄存器映射到机器人状态变量块PLC一次读取这50个寄存器就能拿到机器人完整的实时状态。写参数的时候PLC一次写入连续的一组寄存器机器人侧等收到完整数据块后再做校验和应用避免写入一半时数据处于中间状态。数据刷新策略上把数据分成两类实时性要求高的状态字、急停状态、到位信号尽量短周期刷新建议50到100毫秒一次实时性要求低但数据量大的坐标、工艺参数用200到500毫秒的长周期刷新。这样既保证关键信号响应快又不会因为通信报文过多占用带宽导致异常。3.4 从零到联调的完整操作步骤清单为了让这篇博文可以直接抄作业我把整套调试流程整理成一份操作顺序清单。按这个顺序走可以最大限度避开我当年踩过的坑。第1步确认硬件网络连接。机器人控制柜网口和PLC以太网口或交换机用工业网线连接确保物理链路通。第2步设置网络参数。机器人设192.168.1.20PLC设192.168.1.10子网掩码一致用PC ping测两端IP都通了再往下走。第3步配置机器人从站功能。在示教器上启用ModbusTCP从站设端口502建立寄存器映射表把要交互的变量映射到对应寄存器地址。第4步用Modbus Poll做单点测试。先读后写验证每个映射地址的数据方向和数值正确重点确认字节序和数值缩放是否符合预期。第5步编写PLC通信功能块。封装连接建立、读写请求、超时处理和错误码收集根据数据表逐项创建读写任务。第6步联调。PLC和机器人同时上电观察PLC侧读到的机器人数值是否和示教器显示一致通过Modbus Poll再次抓包对比确认没有地址错位。第7步测试异常场景。拔掉网线模拟通信中断确认PLC在超时阈值内报出通信故障机器人进入安全停止状态。恢复网线后确认系统能自动恢复正常通信。第8步固化配置。把机器人侧的通信配置、PLC侧的网络参数和程序注释整理进项目文档备份PLC程序和机器人配置文件。这步做完整个通信项目才算真正收官。3.5 通信参数速查表参考调试过程中我习惯把关键参数整理成一张速查表贴在调试笔记首页。下面这张表可以直接复制到自己的项目文档里使用。参数项推荐值/设置注意事项机器人IP地址192.168.1.20需与PLC同一网段PLC IP地址192.168.1.10不要占用网段内其他设备地址子网掩码255.255.255.0全部设备统一ModbusTCP端口502改自定义端口时必须两端一致从站站号1标准化设置便于排查通信超时500ms以内过长会延误安全保护轮询周期50ms~200ms按实时性要求调整功能码03读保持寄存器用于读机器人状态区功能码06/16写保持寄存器用于写控制命令和参数字节序大端序跨品牌PLC注意高低字调整4. 常见问题与排查技巧实录4.1 通信建立后数据一直是0或异常大值的排查这类问题在我带过的项目里出现的频率非常高而且95%以上不是因为通信协议不通而是数据映射和解析出了问题。排查思路要从底层往上走先用Modbus Poll直接读机器人侧寄存器的原始值如果原始值是正常的说明问题在PLC侧的数据解析环节如果原始值就是0或异常值说明问题在机器人侧的映射配置或数据源本身。PLC侧解析最常见的问题是字节序和数据缩放。我记得有一次调试时PLC读到的数值是实际值的256倍查到最后是高低字节被反转了。还有一种情况是PLC里用的寄存器地址偏移和机器人侧映射差一位读到的全是错位的数用Modbus Poll对比一下两侧地址就能立刻定位。异常大值还有一种成因读到的寄存器是32位数据的高16位部分看起来是一个很大的随机数这和寄存器映射规划不连续有关把32位数据拆分时顺序弄错了。排查这种问题时最忌讳的就是靠感觉猜和试。正确做法是先固定机器人侧输出一个已知值比如把某个坐标寄存器手动写死为1000然后从PLC侧逐层核对数据是否等于1000不等就一步步往前查。这种定值验证法能极大缩小排查范围比盲目改参数高效得多。4.2 通信偶尔掉线、恢复后又能继续工作的原因这种幽灵掉线问题最难查也是最容易让人心态爆炸的。常见原因有三类网络环境中存在IP地址冲突另一台设备抢占了机器人或PLC的IP导致通信时断时续网络线缆或接头质量不好电磁干扰导致链路层不稳定PLC通信请求过于频繁机器人侧来不及响应导致超时。排查这类问题时先用Wireshark进行长时间抓包观察掉线瞬间的报文交互情况。如果是TCP层频繁重传说明物理链路有问题检查网线和水晶头有条件的话换成带屏蔽的工业网线。如果掉线前出现的是请求发出后长时间没有响应、然后TCP重置大概率是通信周期设置太短机器人侧处理不过来适当调大PLC侧的轮询间隔就能改善。IP冲突可以通过查看交换机端口日志或者把无关设备暂时断开来判断。我见过一个比较极端的案例最终查出是现场另一个工位的设备管理员手工设置了和机器人相同的IP地址平时一直没开机所以没暴露某天开机调试直接把通信撞断了。从那以后我在所有项目里都会强调网络规划和IP管理的重要性给每台设备分配固定IP并且登记在案从源头上杜绝类似问题。4.3 重启后通信配置丢失或失效的处理思路有些项目反馈机器人断电重启后通信就失效了但重新配置一遍就好。这种情况多半是机器人侧的通信配置没有写入永久存储区只运行在临时内存中。汇川机器人的示教器在修改系统配置后一般会提示是否保存并重启生效如果没有确认保存断电后配置就会丢失。除确认保存外备份机器人配置文件到U盘或PC端也是必要的步骤防止控制柜存储单元损坏导致配置彻底丢失。PLC侧重启后通信失效的情况则重点检查通信功能块是否有可保持的启动逻辑。有些PLC程序里通信指令只有在特定触发位为ON时才执行而这个触发位如果来自一个不可保持的中间变量PLC重启后通信就不运行了。解决方法是把通信使能信号设计成上电自动置位或者放到初始化程序段里确保PLC运行开始即自动建立通信。这类问题往往都不是技术难度高而是逻辑设计上的疏漏。但它造成的停产损失和现场压力却不小所以我在联调阶段一定会做断电重启测试机器人断电重启后通信是否自动恢复PLC断电重启后通信是否自动恢复两个顺序都测一遍。4.4 常见问题速查表现象可能原因排查方法ping不通对端网线松动、IP不在同一网段检查物理连接核对IP和掩码ping通但Modbus不响应从站功能未启用、端口被防火墙拦截检查机器人从站开关关闭PC防火墙数据全为0映射地址错误、PLC读错寄存器区用Modbus Poll读原始值比对数据数值偏大或偏小字节序颠倒、数值缩放未换算写定值验证法逐层核对通信间歇性失败网络干扰、IP冲突、请求过密抓包分析、调大轮询间隔、检查线缆重启后通信失效配置未保存到存储器确认保存配置备份配置文件5. 现场实战心得与抗干扰经验5.1 布线规范和接地处理对通信稳定性的实际影响ModbusTCP虽然是基于以太网的协议抗干扰能力比串口通信强不少但工业现场的电磁环境远比办公室复杂。变频器、伺服驱动器、电焊机这些设备工作时会产生强烈的电磁干扰如果网线布线不合理通信丢包和延迟抖动会明显增加。我在项目里总结了几条实战布线规范通信网线尽量远离动力电缆至少保持30厘米以上的间距如果不能避免交叉必须以垂直90度方式交叉避免长距离平行走线使用带屏蔽的工业以太网线屏蔽层在控制柜侧单端接地。接地问题比很多人想象的更影响通信。机器人控制柜、PLC、变频器之间的地电位如果存在明显差异可能会造成网口通信异常甚至损坏网络接口。我见过一个项目机器人调试时通信一直不稳定后来检测发现控制柜接地电阻超标重新做接地后问题彻底消失。所以通信调不通或者不稳定时别光盯着协议配参数用万用表量一下设备接地情况有时能省去好几天瞎折腾的时间。5.2 通信数据的安全性与权限管理ModbusTCP在工业协议里是出了名的裸奔没有加密也没有认证。只要有人能接入这台设备的以太网就可以随意读写机器人的控制寄存器。在封闭的工厂内网里风险相对可控但如果设备联了办公网或者有远程运维通道就必须考虑通信安全。最基础的做法是把PLC和机器人放在独立的工业网络里通过防火墙或网闸与办公网隔离不给非授权设备接触的机会。在PLC程序层面我还会加一道软件保护对关键控制命令启动、急停复位、参数修改增加安全字校验。PLC发送命令前先写入两个固定的校验寄存器值机器人侧先校验通过才执行命令否则丢弃。这样即使通信报文被意外或恶意构造机器人也不会执行无效指令能够在一定程度上弥补ModbusTCP本身缺乏安全机制的问题。5.3 备用通信与手动操作兜底方案很多项目在通信方案设计时没有考虑通信失效后的手动操作路径这个隐患在设备维保时会被无限放大。我的建议是通信联调完成后务必验证机器人示教器的本地手动操作功能不受影响。即便PLC通信完全断开操作人员也必须能通过示教器完成基本的手动操作和急停。这是底线不能依赖唯一的通信链路来控制所有动作。项目交付时我在操作屏上会设计一个通信状态页面显示每个机器人的连接状态、最近通信时间、错误码等状态异常时用醒目的颜色提示操作员。同时在触摸屏上给关键的机器人操作按钮加权限分级避免无关人员误操作。这些虽然不是通信本身的技术范畴但作为完整方案的一部分直接影响现场的可操作性和安全性。5.4 规范化文档与后期维护建议通信项目交付后最容易被忽视的是文档。代码写完了、通信也通了现场工程师拍屁股走人留给客户的是一堆没有注释的程序和没有归档的配置。等三个月后设备出问题接手的人面对一个黑盒排查成本极高。所以我在每个项目收尾时都会强制自己完成几份文档网络拓扑和IP地址分配表、寄存器映射表、PLC通信功能块使用说明、故障排查手册。这些文档的价值在后期维护时会被反复验证。寄存器映射表尤其重要我习惯把所有交互变量整理成Excel表格包含变量名、含义、数据类型、单位、PLC地址、机器人寄存器地址、数据方向、取值范围、默认值、备注。这份表格既是调试依据也是后续改动的基准。任何通信参数调整都先改表格再改程序确保文档和实际程序始终一致。只有做到这种程度通信系统才算是真正交付完成而不是能跑就行。6. 扩展应用与实际项目复盘6.1 多台机器人同时与一台PLC通信的注意事项如果一条产线上有多台汇川机器人都需要通过ModbusTCP和同一台PLC通信方案设计和单台场景有很大区别。PLC需要创建多个Modbus客户端连接每个连接对应一台机器人每个连接都有独立的套接字资源。PLC程序里可以使用同一个通信功能块多次实例化每个实例绑定不同的机器人IP功能块内部通过实例化数据块隔离各台机器人的通信状态和缓冲区。多台机器人的寄存器映射策略要特别注意。各台机器人内部使用相同的寄存器映射关系是可行的因为PLC侧通过不同的IP和连接来区分设备寄存器地址本身不需要全局唯一。但PLC侧的数据缓冲区必须分开否则就会出现两台机器人的数据互相覆盖读到的状态完全错乱。我在项目里一般给每台机器人分配独立的数据块比如DB1存放1号机器人的通信数据DB2存放2号机器人的通信数据程序里严格隔离。还有PLC的通信指令扫描周期问题。每增加一台机器人PLC同时轮询的客户端就多一组如果同一扫描周期内发送的请求过多可能超出PLC的处理能力或网络带宽。这时候就要调整轮询策略把不同机器人的请求交错到不同的扫描周期确保任意时刻在途的请求数量有限。调试时我习惯用Wireshark统计每秒的Modbus请求数量结合PLC的CPU使用率判断是否达到性能瓶颈。6.2 从通信升级到信息化系统的数据流转ModbusTCP通信本身只解决控制层面的数据交换但很多项目其实还有信息化的需求比如把机器人的产量、运行时间、报警记录传给MES系统。这类需求如果完全靠PLC中转PLC的程序会变得很臃肿而且PLC的存储和运算能力有限。更合理的架构是让机器人的ModbusTCP数据直接或通过PLC转发到上位机由上位机完成数据存储和上报。上位机对接的方式也很成熟用Python写一个ModbusTCP客户端程序通过pymodbus库定时读取PLC或机器人侧的数据写入MySQL或SQL Server数据库再通过ModbusTCP或OPC UA等协议与MES对接接口。这样做的好处是PLC端程序保持简单只负责控制逻辑信息化数据的采集和处理完全交给上位机互不干扰。我在多个项目里采用这种分层架构扩展性和维护性都比单靠PLC硬扛好很多。需要注意的是上位机读取数据和PLC控制通信同时访问机器人从站时从站的连接数限制要注意。多数ModbusTCP从站设备支持多个并发客户端连接但有一定上限。如果PLC、触摸屏、上位机三端同时连接机器人超过允许范围后新连接会被拒绝。我在设计时会把所有上位机数据采集需求统一汇总给PLC由PLC作为唯一数据出口减少对机器人从站连接数的消耗。这个方案虽然增加了一点PLC通信编程量但整个系统的稳定性和可管理性都有明显提升。6.3 案例复盘一次完整的产线联调经历最后分享一个实际项目供参考。某小型装配产线一台汇川机器人和一台汇川H5U PLC通信实现机器人上下料与PLC工位信号的联动。现场设计时就按上面说的方式做了完整的寄存器映射PLC写启动、急停复位、目标工位号到保持寄存器0到2机器人在每个动作节点把状态字、完成信号、报警代码写入输入寄存器区PLC用04功能码周期读取。联调时遇到了一个典型的坑PLC侧配置的读取功能码默认是03读的是保持寄存器区而机器人把状态反馈放在输入寄存器区导致状态数据一直读不到。排查了大半天最后对照映射表才发现功能码不匹配改成04后通信数据立刻正常。这个案例典型地说明了功能码和寄存器区映射在跨设备通信中的重要性也验证了提前画好映射表的价值。产线运行一年后的回访中客户反馈通信一直很稳定没有出现过异常掉线。复盘原因主要归功于双向看门狗机制和设备网络隔离做得到位。这台设备后来还增加了触摸屏远程监控功能通过PLC中转读取机器人的数据在屏上显示整体架构没有改动只是在上位机和触摸屏侧做了一点新增配置。回头看当初在通信方案设计上多花的一些心思在后续的扩展和运维中全都值回来了。