拓冰网站定制 
简介工业自动化场景中安川机器人与 PLC 的实时数据交互是产线高效协同的基础。这份资料面向集成调试与设备运维工程师聚焦两者间 UDP/TCP 协议对接中的参数配置、报文收发与可靠性保障问题。压缩包共 189 个文件约 81.44MB包含 C# 超级通信调试工具的完整工程源码.cs/.sln/.resx 等、接口定义、配置示例及应用说明文档同时收录 PDF 手册、文本说明与示例文件便于对照学习。已有 1558 人浏览学习适合需要掌握 MODBUS TCP、EtherNet/IP 或自定义 Socket 通信的自动化工程师。资料从协议原理到工程实现逐层展开涵盖 IP/端口设置、连接建立与释放、数据格式化、CRC 校验、错误重传等关键环节并附有可编译运行的调试工具支持数据监控与发送可直接用于设备联调或二次开发节省前期协议验证时间。1. 安川机器人与PLC的UDP/TCP通信这本手册到底解决什么问题产线上最常见的戏码是机器人干活PLC发号施令两边靠几十根IO线互相喊话。可一旦要传位置数据、焊接参数、生产计数IO点就明显不够用了现场工程师得换一条路——走以太网。安川机器人与PLC进行UDP通信与TCP通信相关的指导手册解决的就是这个场景让机器人控制器和PLC通过UDP或TCP把数据真正传起来而不是只会闪IO。它适合机器人调试工程师、电气工程师和自动化集成商尤其是头一回碰安川控制器Socket通信的人。下面不会把手册逐页抄一遍而是按落地这类项目的顺序把选型、参数、帧格式和踩坑点一次讲清楚。2. 通信协议选型先于代码安川机器人UDP与TCP的适用边界2.1 安川机器人通信方式盘点从IO点到Socket的演变安川机器人控制器DX200、YRC1000等系列对外通信的方式不少。最基础的是IO信号机器人侧和PLC侧各挂一摊IO模块点对点接线逻辑简单但数量有限扩展一个信号就要多拉一根线改动麻烦。再往上是现场总线比如DeviceNet、Profibus、CC-Link能传的数据量和实时性都比IO好但需要额外购买总线模块和组态授权而且不同PLC品牌对总线的支持差异很大。真正放开手脚的是以太网通信。安川控制器基本都带以太网口除了接电脑做编程维护还能通过Socket功能与外部设备做UDP或TCP通信底层走的就是TCP/IP协议栈。PLC侧对应的是开放式通信功能比如三菱PLC的Socket通信指令或者西门子S7-1200/1500的开放式通信指令族。这里有一个关键认知安川机器人不会主动解析PLC的私有协议双方约定的是纯Socket数据帧协议逻辑得在机器人程序和PLC程序里分别实现。所以选型的第一步不是写代码而是想清楚UDP还是TCP。2.2 UDP与TCP协议的区别为什么机器人现场常混用UDP和TCP的差别是工程选型的核心建议不要凭感觉选。TCP面向连接通信前先三次握手建立会话数据有确认和重传机制传输可靠但握手和确认带来额外延迟UDP无连接数据报直接发出去不保证到达、不保证顺序但延迟低、开销小。在机器人现场这两种特性分别对应两类需求。一类是周期性的高速数据比如机器人实时上报当前坐标、速度、IO状态PLC以100ms甚至10ms的周期刷新读取。这类数据丢了下一周期会有新的用TCP反而可能因为重传造成数据堆积和延迟变大所以一般建议用UDP。另一类是突发性的关键指令比如启动、停止、切换程序、写入焊接参数这类指令一旦丢失就可能造成撞机或错焊必须可靠送达那就用TCP。实际项目里很多人是混用的一个UDP端口跑状态流一个TCP端口跑指令流。协议本身没有谁绝对好关键看数据是否允许重传延迟。2.3 选型决策表UDP和TCP在机器人场景的适用边界下面这张表是很多项目里实际使用的决策依据按数据特征选协议而不是按品牌习惯选。场景推荐协议理由周期上报位置、速度、IO状态50~200ms周期UDP实时性高偶发丢帧可接受下一帧自动补齐启动、停止、急停、模式切换等关键命令TCP必须可靠到达不能依赖“下一帧”批量下载焊接参数、配方数据TCP数据量大且需要完整性TCP重传机制省心机器人状态需要被多台上位机同时读取UDP无连接特性适合多点读取TCP连接数有限跨交换机远距离传输、网络质量不确定TCPUDP丢包率高时应用层补偿成本很大有一点需要提醒用UDP不等于放弃可靠性应用层要自己加序列号、时间戳和超时判断。TCP也不等于实时极端情况下重传会把延迟拉高。选型之后通信双方的帧格式必须一致这就是下一章要落地的事。3. 与PLC进行UDP通信IP、端口与数据帧设计3.1 安川机器人UDP通信参数设置端口号、IP地址与数据长度UDP通信的第一步是把机器人控制器的网络参数定下来。在示教器上进入系统设置的网络界面给控制器设固定IP比如192.168.1.10子网掩码255.255.255.0。PLC侧的IP要单独规划比如192.168.1.20确保两者在同一网段且不要和车间里其他设备冲突。端口号建议避开常用服务端口常见做法是在4000到9000之间选比如状态流用5000指令流用5001两端必须一致。安川机器人程序里UDP通信的指令链路大致是打开Socket、发送数据、接收数据、关闭Socket。不同控制器系列指令名称略有差异但参数含义有共性需要指定本机端口、对方IP、对方端口、发送缓冲区和数据长度。缓冲区长度决定了单帧数据的上限安川控制器一般支持512或1024字节规划帧格式时要把这个上限留足别设计一帧2000字节的报文到现场才发现发不出去。3.2 PLC侧UDP配置以三菱Q系列PLC为例的设置步骤PLC侧要做的事情和机器人侧对称。这里以三菱Q系列PLC为例讲流程因为安川和三菱在现场是同厂搭配的高频组合。三菱PLC使用Socket通信功能需要在参数里启用以太网模块的协议为UDP并分配端口号。程序里使用Socket指令先OPEN建立套接字再SEND发送数据到指定IP和端口RECV接收数据最后CLOSE释放。核心参数是目标IP、目标端口、本机端口和缓冲区地址。西门子S7-1200/1500的流程类似但指令不同UDP场景使用TUCON建立UDP连接TUSEND发送数据TURCV接收数据。无论哪个品牌我建议先在PC上装一个网络调试助手模拟PLC发UDP包给机器人确认机器人的收发逻辑正确后再改到PLC程序里。这样能把“机器人逻辑问题”和“PLC程序问题”这两类变量分开调试现场会少走很多弯路。3.3 数据帧格式设计字节序、数据类型与ID标识UDP通信真正容易翻车的是数据帧格式。工业设备之间通信帧格式没有统一标准必须由双方约定。我常用的帧结构是帧头2字节 长度2字节 命令字2字节 数据区N字节 校验2字节。帧头用固定的0xAA55做识别长度指从命令字到校验的总字节数命令字区分这条报文是状态请求、参数下发还是握手应答数据区放具体内容校验用CRC16或简单的异或。字段长度示例说明帧头2字节0xAA 0x55固定值用于帧同步长度2字节0x00 0x0A后续字段总长度命令字2字节0x00 0x011表示状态请求2表示参数下发数据区N字节坐标、速度、标志位按双方约定排列校验2字节CRC16低字节在前还是高字节在前要写进文档字节序是另一个高频坑。很多PLC默认小端序不少工控设备习惯大端序两边如果不一致int类型的数据读出来就会差一大截。解决手段很简单联调前先用一帧固定数据0x01020304做测试如果PLC读出的是0x04030201说明字节序反了调整转换函数。数据类型也要约定清楚SINT、INT、DINT、REAL各占多少字节、存的是原始值还是带小数位的缩放值参数文档里必须写明。格式不统一带来的问题后面第5章会专门讲。3.4 UDP通信的调试手段从ping到回环测试UDP没有连接概念调试时最容易出现的假象是“发了但没到”。建议按下面三步走。第一步先用ping确认物理链路通不通机器人侧网络不通的话ping都ping不通问题在网线或IP配置不用急着看程序。第二步用UDP调试工具给对端发测试帧比如从PC向机器人的5000端口发一条带固定内容的UDP包看机器人能否收到并在示教器上显示反过来机器人发数据到PC用调试助手查看内容是否正确。第三步做回环测试排除中间链路。让PLC给自己发UDP包确认PLC的收发逻辑本身没问题再让机器人和PLC互相发观察是否有丢帧。如果怀疑网络丢包可以用iperf3这类工具做UDP打流测试指定带宽跑一段时间看丢包率。一般情况下车间局域网UDP丢包率应该低于0.1%如果丢包率明显偏高说明交换机端口、网线或者双工模式有问题用TCP也未必稳先把链路修好再继续。4. 与PLC进行TCP通信连接管理、粘包与断线重连4.1 机器人侧TCP Server与Client的选择谁主动谁被动TCP和UDP最大的不同是有连接状态所以第一步就要定角色机器人做Server还是做Client。机器人做Server意味着机器人在指定端口上监听PLC作为Client主动发起连接。这种模式的好处是PLC掌握主动权想连就连、想断就断机器人程序只需处理连接事件和收发数据角色简单适合PLC做主站、机器人做从站的常规架构。机器人做Client则是机器人主动向PLC的IP和端口发起连接PLC做Server。这种模式适合机器人需要主动上报数据、或者PLC无法主动发起连接的场景但机器人程序里要自己管理连接状态、断线重连程序复杂度和出错概率都更高。我一般倾向让PLC做Client、机器人做Server因为PLC扫描周期固定连接管理交给PLC的通信功能块更可靠。如果是小型PLC或不支持复杂通信的型号再考虑机器人主动连接。4.2 安川机器人TCP指令链路连接、发送、接收、关闭TCP在机器人程序里的基本调用链是建立连接、发送数据、接收数据、关闭连接。这部分不同安川控制器系列指令名不完全一样但从工程角度你可以把链路理解成四个环节OPEN指定本地端口和对方IP端口建立TCP会话SEND把缓冲区数据发给对方RECV接收对方数据并存入缓冲区CLOSE主动关闭连接。实际操作中机器人程序通常放在一个循环任务里周期执行接收和发送逻辑连接建立代码只在启动或者断线重连时执行。有一点值得注意TCP连接建立后机器人侧程序如果长时间不调用接收指令对方发来的数据会堆积在系统缓冲区里可能造成通信延迟。所以机器人程序里要有一个循环任务专门做RECV收到数据后马上解析并触发相应动作。发送侧也一样SEND调用频率要控制不要在同一个扫描周期里重复发送同一份数据避免给对方PLC造成队列积压。4.3 TCP粘包与拆包机器人通信最常翻车的点TCP是字节流协议它不保证一次发送对应一次读取。如果机器人连续发送两帧数据PLC可能一次就读到两帧拼在一起的数据这叫粘包也可能一帧数据被拆成两次读这叫拆包。很多新手第一次调TCP程序看着没问题数据就是错乱十有八九是没处理消息边界。解决的思路不是让TCP不粘包而是在应用层做拆包。常见做法有两种一种是定长帧双方约定每帧固定100字节接收方凑满100字节再解析简单但浪费带宽另一种是变长帧在帧头里带长度字段接收方先解析帧头和长度再按长度取完整数据。我推荐第二种和UDP那章推荐的帧结构保持一致帧头长度命令字数据校验这样UDP和TCP可以共用同一套解析代码。解析流程通常是接收缓冲区数据追加到缓存循环检查缓存里是否有完整帧有就取出来解析没有就继续等。4.4 断线重连与看门狗让通信具备自恢复能力TCP通信建立后网线松动、PLC重启、机器人重启都会导致连接断开。现场经验是连接断开不可怕可怕的是断开后没人发现。所以一定要设计心跳机制和看门狗PLC侧周期发送心跳帧比如每500ms发一条命令字为0x0000的报文机器人侧设一个超时时间比如3秒没收到心跳就判定通信故障执行安全动作并报警。反过来PLC侧也可以监控机器人的回包超过设定时间没回包就报警停机。断线重连逻辑要分角色处理。如果PLC是Client重连逻辑写在PLC里检测到连接断开后先主动关闭旧连接再重新发起连接注意不要直接重连同一个端口否则可能连接还没释放干净。如果机器人是Client机器人程序里要包含重试循环断开后等待固定时间比如5秒再重新OPEN。连接资源很宝贵断开后不CLOSE直接OPEN在极端情况下会把控制器Socket资源耗尽表现为“TCP连接能建立但收发不正常”这一点直接在下一章展开。5. 安川机器人与PLC通信的避坑指南现场常见问题排查通信系统的故障往往不是单点问题抓包和看状态是排查的基础。下面这几条是从大量现场案例里整理出来的高发问题每一条都按“现象、原因、解决”展开排查时建议先看现象命中哪一条再动手改。5.1 现象UDP能收到请求但机器人不回复现场的典型情况是网络调试助手能收到PLC发来的UDP包机器人也收到了但就是不见回包。原因往往有两种一是机器人程序里的SEND指令指向的目标IP或端口写错了PLC发到5000端口机器人回给5001端口PLC没监听5001自然收不到二是机器人程序里的发送逻辑依赖某个条件比如需要IO信号触发才执行SEND条件没满足就一直不发。解决办法是先用网络调试助手模拟PLC给机器人发请求机器人回包后看目标IP和端口再用Wireshark抓包确认报文去向。如果发现机器人根本没发出UDP包检查SEND指令的执行条件如果机器人发了但PLC收不到重点查PLC侧监听的端口号和IP是否和机器人回包的目标一致。把这两个变量分开验证通常十分钟内能定位。5.2 现象TCP连接建立后频繁断开连接能建立说明网络层没问题但每隔几秒就断开这类问题排查起来比较费时间。常见原因有三个一是双端设置了不一致的keepalive或超时参数PLC侧连接空闲超时设得很短机器人侧还没回数据PLC就主动断开二是中间交换机启用了端口节能模式长时间无数据就把链路状态切到低功耗下一帧数据到达时恢复链路时延变大TCP重传超时导致断开三是机器人侧看门狗判定通信超时主动关闭连接。建议先抓包看FIN包是谁发的谁发FIN就是谁认为超时了再针对性调整对应侧的超时参数。交换机尽量关闭节能以太网功能并确认端口双工模式都设为自协商或全双工。手动排查时可以用ping大包测试稳定性如果大包频繁超时问题大概率在链路而不在程序。5.3 现象PLC读到的数据是乱码或字节错位这类问题最典型机器人发的X坐标是10000x000003E8PLC读出来却是16256或2608这种奇怪数值。原因基本是字节序不一致或数据类型长度不匹配。安川机器人和部分PLC在字节序上的默认习惯不同如果一方按大端解释、另一方按小端输出每个字节都会错位。另外把INT16位数据当成DINT32位读或者把REAL的四个字节用整型解析也会出现完全不可信的数值。解决办法是双方确认一张数据映射表字段名、类型、字节序、缩放系数联调前先用0x01020304和0x3F800000浮点1.0两帧测试数据做验证。如果测试帧能被正确解释说明字节序和类型没问题再排查业务字段的偏移位置如果测试帧就不对直接锁定字节序和类型定义先统一再谈业务。5.4 现象通信正常但偶发丢一帧数据通信总体正常但偶尔丢一帧UDP场景多见TCP场景偶见。UDP丢帧的原因通常是发送频率超过链路处理能力比如PLC每10ms发一帧而交换机或机器人接收侧处理一帧需要更长时间缓冲区溢出一两帧。TCP偶发丢帧多是中间链路MTU问题或两端缓冲区配置不合理。解决办法是先量化丢帧数据用iperf3 UDP打流测实际丢包率。如果丢包率正常就要调整应用层降低发送频率、适当增大机器人侧接收缓冲区并在帧格式里加序列号字段接收侧检测到序列号跳变就补发或告警。不要指望TCP和UDP绝对不丢数据应用层有检测机制才是工程能接受的方案。5.5 现象PLC重启后无法重新连上机器人TCP现场最让人头疼的故障之一PLC一断电重启TCP就再也连不上机器人除非把机器人程序也重启一遍。原因基本是机器人侧还保留着旧的TCP连接资源PLC重启时没有发FIN包机器人侧连接状态停留在ESTABLISHED或TIME_WAIT新的连接请求到达时Socket资源被旧连接占用或者系统认为同一连接还在存活拒绝了新连接。解决思路是让机器人侧具备连接状态自清理能力程序里定期检查通信超时超时后主动CLOSE并重新OPEN同时PLC侧重连逻辑要先调用关闭指令再发起新连接。这里常看到有人循环重连却不先CLOSE结果把端口彻底占死。记住一个原则重连之前先清理旧连接CLOSE再OPEN的顺序不能反。6. 把这套通信真正跑稳抓包验证与交付验收技巧6.1 用Wireshark验证UDP/TCP数据流三个关键过滤器联调阶段最依赖的工具是Wireshark。在PC上做端口镜像或在交换机上抓包可以直观看到谁发了什么、回没回。常用过滤器三件套UDP场景用udp.port 5000只看通信双方这个端口的报文TCP场景用tcp.port 5001再配合tcp.stream eq 0追踪第一条TCP连接的完整会话看三次握手和断开的FIN/ACK过程。排查丢帧时用frame.time_delta字段观察相邻帧间隔如果出现几百毫秒的间隔基本就是链路或缓冲区问题。命令行抓包时我一般用tshark把报文直接存文件再慢慢分析# 抓取 5000 端口 UDP 报文保存到 pcapng 文件 tshark -i eth0 -f udp port 5000 -w robot_comm.pcapng这里eth0要换成PC上实际抓包网卡名-f后面跟的是BPF过滤语法-w指定输出文件。加上-a duration:60可以限定只抓60秒避免现场抓包文件过大。抓完回办公室再打开看不占现场时间也比现场盯实时刷新直观得多。6.2 交付给现场的技术文档配置清单与异常恢复步骤通信联调通过只是第一步把方案交付给现场维护人员文档质量决定后面运维省不省心。我通常会在手册之外附一张配置清单表格写清楚所有网络参数机器人IP、PLC IP、子网掩码、UDP端口、TCP端口、帧头、长度字段偏移、校验方式、字节序、心跳周期、超时时间、重连次数。这张表一眼能看明白比翻几十页程序快得多。再附一页异常恢复步骤比如“TCP连不上时检查机器人程序是否处于运行状态重启前先确认PLC侧连接已经关闭”。很多半夜的紧急电话其实都是因为现场缺这样一张参数卡。6.3 一个值得保留的习惯先在电脑上把协议逻辑跑通我现在的习惯是任何机器人和PLC的通信项目都先在电脑上做一遍协议回环再上真机。用网络调试助手模拟对端把帧格式、定时器、重连逻辑在PC上验证一遍真机联调时只查参数不查逻辑。这样做最大的好处是省调试时间也避免在现场反复刷机器人程序。回头想想早期几个项目翻车都翻在同一个点上没把字节序和帧边界当回事现场改来改去最后还是靠抓包才定位到问题。通信这种黑匣子只有靠文档和工具才能把它变白希望这份思路帮到你落地时少踩几个坑。本文还有配套的精品资源点击获取 安川机器人与PLC的UDP/TCP通信：Socket数据帧与调试避坑指南
简介工业自动化场景中安川机器人与 PLC 的实时数据交互是产线高效协同的基础。这份资料面向集成调试与设备运维工程师聚焦两者间 UDP/TCP 协议对接中的参数配置、报文收发与可靠性保障问题。压缩包共 189 个文件约 81.44MB包含 C# 超级通信调试工具的完整工程源码.cs/.sln/.resx 等、接口定义、配置示例及应用说明文档同时收录 PDF 手册、文本说明与示例文件便于对照学习。已有 1558 人浏览学习适合需要掌握 MODBUS TCP、EtherNet/IP 或自定义 Socket 通信的自动化工程师。资料从协议原理到工程实现逐层展开涵盖 IP/端口设置、连接建立与释放、数据格式化、CRC 校验、错误重传等关键环节并附有可编译运行的调试工具支持数据监控与发送可直接用于设备联调或二次开发节省前期协议验证时间。1. 安川机器人与PLC的UDP/TCP通信这本手册到底解决什么问题产线上最常见的戏码是机器人干活PLC发号施令两边靠几十根IO线互相喊话。可一旦要传位置数据、焊接参数、生产计数IO点就明显不够用了现场工程师得换一条路——走以太网。安川机器人与PLC进行UDP通信与TCP通信相关的指导手册解决的就是这个场景让机器人控制器和PLC通过UDP或TCP把数据真正传起来而不是只会闪IO。它适合机器人调试工程师、电气工程师和自动化集成商尤其是头一回碰安川控制器Socket通信的人。下面不会把手册逐页抄一遍而是按落地这类项目的顺序把选型、参数、帧格式和踩坑点一次讲清楚。2. 通信协议选型先于代码安川机器人UDP与TCP的适用边界2.1 安川机器人通信方式盘点从IO点到Socket的演变安川机器人控制器DX200、YRC1000等系列对外通信的方式不少。最基础的是IO信号机器人侧和PLC侧各挂一摊IO模块点对点接线逻辑简单但数量有限扩展一个信号就要多拉一根线改动麻烦。再往上是现场总线比如DeviceNet、Profibus、CC-Link能传的数据量和实时性都比IO好但需要额外购买总线模块和组态授权而且不同PLC品牌对总线的支持差异很大。真正放开手脚的是以太网通信。安川控制器基本都带以太网口除了接电脑做编程维护还能通过Socket功能与外部设备做UDP或TCP通信底层走的就是TCP/IP协议栈。PLC侧对应的是开放式通信功能比如三菱PLC的Socket通信指令或者西门子S7-1200/1500的开放式通信指令族。这里有一个关键认知安川机器人不会主动解析PLC的私有协议双方约定的是纯Socket数据帧协议逻辑得在机器人程序和PLC程序里分别实现。所以选型的第一步不是写代码而是想清楚UDP还是TCP。2.2 UDP与TCP协议的区别为什么机器人现场常混用UDP和TCP的差别是工程选型的核心建议不要凭感觉选。TCP面向连接通信前先三次握手建立会话数据有确认和重传机制传输可靠但握手和确认带来额外延迟UDP无连接数据报直接发出去不保证到达、不保证顺序但延迟低、开销小。在机器人现场这两种特性分别对应两类需求。一类是周期性的高速数据比如机器人实时上报当前坐标、速度、IO状态PLC以100ms甚至10ms的周期刷新读取。这类数据丢了下一周期会有新的用TCP反而可能因为重传造成数据堆积和延迟变大所以一般建议用UDP。另一类是突发性的关键指令比如启动、停止、切换程序、写入焊接参数这类指令一旦丢失就可能造成撞机或错焊必须可靠送达那就用TCP。实际项目里很多人是混用的一个UDP端口跑状态流一个TCP端口跑指令流。协议本身没有谁绝对好关键看数据是否允许重传延迟。2.3 选型决策表UDP和TCP在机器人场景的适用边界下面这张表是很多项目里实际使用的决策依据按数据特征选协议而不是按品牌习惯选。场景推荐协议理由周期上报位置、速度、IO状态50~200ms周期UDP实时性高偶发丢帧可接受下一帧自动补齐启动、停止、急停、模式切换等关键命令TCP必须可靠到达不能依赖“下一帧”批量下载焊接参数、配方数据TCP数据量大且需要完整性TCP重传机制省心机器人状态需要被多台上位机同时读取UDP无连接特性适合多点读取TCP连接数有限跨交换机远距离传输、网络质量不确定TCPUDP丢包率高时应用层补偿成本很大有一点需要提醒用UDP不等于放弃可靠性应用层要自己加序列号、时间戳和超时判断。TCP也不等于实时极端情况下重传会把延迟拉高。选型之后通信双方的帧格式必须一致这就是下一章要落地的事。3. 与PLC进行UDP通信IP、端口与数据帧设计3.1 安川机器人UDP通信参数设置端口号、IP地址与数据长度UDP通信的第一步是把机器人控制器的网络参数定下来。在示教器上进入系统设置的网络界面给控制器设固定IP比如192.168.1.10子网掩码255.255.255.0。PLC侧的IP要单独规划比如192.168.1.20确保两者在同一网段且不要和车间里其他设备冲突。端口号建议避开常用服务端口常见做法是在4000到9000之间选比如状态流用5000指令流用5001两端必须一致。安川机器人程序里UDP通信的指令链路大致是打开Socket、发送数据、接收数据、关闭Socket。不同控制器系列指令名称略有差异但参数含义有共性需要指定本机端口、对方IP、对方端口、发送缓冲区和数据长度。缓冲区长度决定了单帧数据的上限安川控制器一般支持512或1024字节规划帧格式时要把这个上限留足别设计一帧2000字节的报文到现场才发现发不出去。3.2 PLC侧UDP配置以三菱Q系列PLC为例的设置步骤PLC侧要做的事情和机器人侧对称。这里以三菱Q系列PLC为例讲流程因为安川和三菱在现场是同厂搭配的高频组合。三菱PLC使用Socket通信功能需要在参数里启用以太网模块的协议为UDP并分配端口号。程序里使用Socket指令先OPEN建立套接字再SEND发送数据到指定IP和端口RECV接收数据最后CLOSE释放。核心参数是目标IP、目标端口、本机端口和缓冲区地址。西门子S7-1200/1500的流程类似但指令不同UDP场景使用TUCON建立UDP连接TUSEND发送数据TURCV接收数据。无论哪个品牌我建议先在PC上装一个网络调试助手模拟PLC发UDP包给机器人确认机器人的收发逻辑正确后再改到PLC程序里。这样能把“机器人逻辑问题”和“PLC程序问题”这两类变量分开调试现场会少走很多弯路。3.3 数据帧格式设计字节序、数据类型与ID标识UDP通信真正容易翻车的是数据帧格式。工业设备之间通信帧格式没有统一标准必须由双方约定。我常用的帧结构是帧头2字节 长度2字节 命令字2字节 数据区N字节 校验2字节。帧头用固定的0xAA55做识别长度指从命令字到校验的总字节数命令字区分这条报文是状态请求、参数下发还是握手应答数据区放具体内容校验用CRC16或简单的异或。字段长度示例说明帧头2字节0xAA 0x55固定值用于帧同步长度2字节0x00 0x0A后续字段总长度命令字2字节0x00 0x011表示状态请求2表示参数下发数据区N字节坐标、速度、标志位按双方约定排列校验2字节CRC16低字节在前还是高字节在前要写进文档字节序是另一个高频坑。很多PLC默认小端序不少工控设备习惯大端序两边如果不一致int类型的数据读出来就会差一大截。解决手段很简单联调前先用一帧固定数据0x01020304做测试如果PLC读出的是0x04030201说明字节序反了调整转换函数。数据类型也要约定清楚SINT、INT、DINT、REAL各占多少字节、存的是原始值还是带小数位的缩放值参数文档里必须写明。格式不统一带来的问题后面第5章会专门讲。3.4 UDP通信的调试手段从ping到回环测试UDP没有连接概念调试时最容易出现的假象是“发了但没到”。建议按下面三步走。第一步先用ping确认物理链路通不通机器人侧网络不通的话ping都ping不通问题在网线或IP配置不用急着看程序。第二步用UDP调试工具给对端发测试帧比如从PC向机器人的5000端口发一条带固定内容的UDP包看机器人能否收到并在示教器上显示反过来机器人发数据到PC用调试助手查看内容是否正确。第三步做回环测试排除中间链路。让PLC给自己发UDP包确认PLC的收发逻辑本身没问题再让机器人和PLC互相发观察是否有丢帧。如果怀疑网络丢包可以用iperf3这类工具做UDP打流测试指定带宽跑一段时间看丢包率。一般情况下车间局域网UDP丢包率应该低于0.1%如果丢包率明显偏高说明交换机端口、网线或者双工模式有问题用TCP也未必稳先把链路修好再继续。4. 与PLC进行TCP通信连接管理、粘包与断线重连4.1 机器人侧TCP Server与Client的选择谁主动谁被动TCP和UDP最大的不同是有连接状态所以第一步就要定角色机器人做Server还是做Client。机器人做Server意味着机器人在指定端口上监听PLC作为Client主动发起连接。这种模式的好处是PLC掌握主动权想连就连、想断就断机器人程序只需处理连接事件和收发数据角色简单适合PLC做主站、机器人做从站的常规架构。机器人做Client则是机器人主动向PLC的IP和端口发起连接PLC做Server。这种模式适合机器人需要主动上报数据、或者PLC无法主动发起连接的场景但机器人程序里要自己管理连接状态、断线重连程序复杂度和出错概率都更高。我一般倾向让PLC做Client、机器人做Server因为PLC扫描周期固定连接管理交给PLC的通信功能块更可靠。如果是小型PLC或不支持复杂通信的型号再考虑机器人主动连接。4.2 安川机器人TCP指令链路连接、发送、接收、关闭TCP在机器人程序里的基本调用链是建立连接、发送数据、接收数据、关闭连接。这部分不同安川控制器系列指令名不完全一样但从工程角度你可以把链路理解成四个环节OPEN指定本地端口和对方IP端口建立TCP会话SEND把缓冲区数据发给对方RECV接收对方数据并存入缓冲区CLOSE主动关闭连接。实际操作中机器人程序通常放在一个循环任务里周期执行接收和发送逻辑连接建立代码只在启动或者断线重连时执行。有一点值得注意TCP连接建立后机器人侧程序如果长时间不调用接收指令对方发来的数据会堆积在系统缓冲区里可能造成通信延迟。所以机器人程序里要有一个循环任务专门做RECV收到数据后马上解析并触发相应动作。发送侧也一样SEND调用频率要控制不要在同一个扫描周期里重复发送同一份数据避免给对方PLC造成队列积压。4.3 TCP粘包与拆包机器人通信最常翻车的点TCP是字节流协议它不保证一次发送对应一次读取。如果机器人连续发送两帧数据PLC可能一次就读到两帧拼在一起的数据这叫粘包也可能一帧数据被拆成两次读这叫拆包。很多新手第一次调TCP程序看着没问题数据就是错乱十有八九是没处理消息边界。解决的思路不是让TCP不粘包而是在应用层做拆包。常见做法有两种一种是定长帧双方约定每帧固定100字节接收方凑满100字节再解析简单但浪费带宽另一种是变长帧在帧头里带长度字段接收方先解析帧头和长度再按长度取完整数据。我推荐第二种和UDP那章推荐的帧结构保持一致帧头长度命令字数据校验这样UDP和TCP可以共用同一套解析代码。解析流程通常是接收缓冲区数据追加到缓存循环检查缓存里是否有完整帧有就取出来解析没有就继续等。4.4 断线重连与看门狗让通信具备自恢复能力TCP通信建立后网线松动、PLC重启、机器人重启都会导致连接断开。现场经验是连接断开不可怕可怕的是断开后没人发现。所以一定要设计心跳机制和看门狗PLC侧周期发送心跳帧比如每500ms发一条命令字为0x0000的报文机器人侧设一个超时时间比如3秒没收到心跳就判定通信故障执行安全动作并报警。反过来PLC侧也可以监控机器人的回包超过设定时间没回包就报警停机。断线重连逻辑要分角色处理。如果PLC是Client重连逻辑写在PLC里检测到连接断开后先主动关闭旧连接再重新发起连接注意不要直接重连同一个端口否则可能连接还没释放干净。如果机器人是Client机器人程序里要包含重试循环断开后等待固定时间比如5秒再重新OPEN。连接资源很宝贵断开后不CLOSE直接OPEN在极端情况下会把控制器Socket资源耗尽表现为“TCP连接能建立但收发不正常”这一点直接在下一章展开。5. 安川机器人与PLC通信的避坑指南现场常见问题排查通信系统的故障往往不是单点问题抓包和看状态是排查的基础。下面这几条是从大量现场案例里整理出来的高发问题每一条都按“现象、原因、解决”展开排查时建议先看现象命中哪一条再动手改。5.1 现象UDP能收到请求但机器人不回复现场的典型情况是网络调试助手能收到PLC发来的UDP包机器人也收到了但就是不见回包。原因往往有两种一是机器人程序里的SEND指令指向的目标IP或端口写错了PLC发到5000端口机器人回给5001端口PLC没监听5001自然收不到二是机器人程序里的发送逻辑依赖某个条件比如需要IO信号触发才执行SEND条件没满足就一直不发。解决办法是先用网络调试助手模拟PLC给机器人发请求机器人回包后看目标IP和端口再用Wireshark抓包确认报文去向。如果发现机器人根本没发出UDP包检查SEND指令的执行条件如果机器人发了但PLC收不到重点查PLC侧监听的端口号和IP是否和机器人回包的目标一致。把这两个变量分开验证通常十分钟内能定位。5.2 现象TCP连接建立后频繁断开连接能建立说明网络层没问题但每隔几秒就断开这类问题排查起来比较费时间。常见原因有三个一是双端设置了不一致的keepalive或超时参数PLC侧连接空闲超时设得很短机器人侧还没回数据PLC就主动断开二是中间交换机启用了端口节能模式长时间无数据就把链路状态切到低功耗下一帧数据到达时恢复链路时延变大TCP重传超时导致断开三是机器人侧看门狗判定通信超时主动关闭连接。建议先抓包看FIN包是谁发的谁发FIN就是谁认为超时了再针对性调整对应侧的超时参数。交换机尽量关闭节能以太网功能并确认端口双工模式都设为自协商或全双工。手动排查时可以用ping大包测试稳定性如果大包频繁超时问题大概率在链路而不在程序。5.3 现象PLC读到的数据是乱码或字节错位这类问题最典型机器人发的X坐标是10000x000003E8PLC读出来却是16256或2608这种奇怪数值。原因基本是字节序不一致或数据类型长度不匹配。安川机器人和部分PLC在字节序上的默认习惯不同如果一方按大端解释、另一方按小端输出每个字节都会错位。另外把INT16位数据当成DINT32位读或者把REAL的四个字节用整型解析也会出现完全不可信的数值。解决办法是双方确认一张数据映射表字段名、类型、字节序、缩放系数联调前先用0x01020304和0x3F800000浮点1.0两帧测试数据做验证。如果测试帧能被正确解释说明字节序和类型没问题再排查业务字段的偏移位置如果测试帧就不对直接锁定字节序和类型定义先统一再谈业务。5.4 现象通信正常但偶发丢一帧数据通信总体正常但偶尔丢一帧UDP场景多见TCP场景偶见。UDP丢帧的原因通常是发送频率超过链路处理能力比如PLC每10ms发一帧而交换机或机器人接收侧处理一帧需要更长时间缓冲区溢出一两帧。TCP偶发丢帧多是中间链路MTU问题或两端缓冲区配置不合理。解决办法是先量化丢帧数据用iperf3 UDP打流测实际丢包率。如果丢包率正常就要调整应用层降低发送频率、适当增大机器人侧接收缓冲区并在帧格式里加序列号字段接收侧检测到序列号跳变就补发或告警。不要指望TCP和UDP绝对不丢数据应用层有检测机制才是工程能接受的方案。5.5 现象PLC重启后无法重新连上机器人TCP现场最让人头疼的故障之一PLC一断电重启TCP就再也连不上机器人除非把机器人程序也重启一遍。原因基本是机器人侧还保留着旧的TCP连接资源PLC重启时没有发FIN包机器人侧连接状态停留在ESTABLISHED或TIME_WAIT新的连接请求到达时Socket资源被旧连接占用或者系统认为同一连接还在存活拒绝了新连接。解决思路是让机器人侧具备连接状态自清理能力程序里定期检查通信超时超时后主动CLOSE并重新OPEN同时PLC侧重连逻辑要先调用关闭指令再发起新连接。这里常看到有人循环重连却不先CLOSE结果把端口彻底占死。记住一个原则重连之前先清理旧连接CLOSE再OPEN的顺序不能反。6. 把这套通信真正跑稳抓包验证与交付验收技巧6.1 用Wireshark验证UDP/TCP数据流三个关键过滤器联调阶段最依赖的工具是Wireshark。在PC上做端口镜像或在交换机上抓包可以直观看到谁发了什么、回没回。常用过滤器三件套UDP场景用udp.port 5000只看通信双方这个端口的报文TCP场景用tcp.port 5001再配合tcp.stream eq 0追踪第一条TCP连接的完整会话看三次握手和断开的FIN/ACK过程。排查丢帧时用frame.time_delta字段观察相邻帧间隔如果出现几百毫秒的间隔基本就是链路或缓冲区问题。命令行抓包时我一般用tshark把报文直接存文件再慢慢分析# 抓取 5000 端口 UDP 报文保存到 pcapng 文件 tshark -i eth0 -f udp port 5000 -w robot_comm.pcapng这里eth0要换成PC上实际抓包网卡名-f后面跟的是BPF过滤语法-w指定输出文件。加上-a duration:60可以限定只抓60秒避免现场抓包文件过大。抓完回办公室再打开看不占现场时间也比现场盯实时刷新直观得多。6.2 交付给现场的技术文档配置清单与异常恢复步骤通信联调通过只是第一步把方案交付给现场维护人员文档质量决定后面运维省不省心。我通常会在手册之外附一张配置清单表格写清楚所有网络参数机器人IP、PLC IP、子网掩码、UDP端口、TCP端口、帧头、长度字段偏移、校验方式、字节序、心跳周期、超时时间、重连次数。这张表一眼能看明白比翻几十页程序快得多。再附一页异常恢复步骤比如“TCP连不上时检查机器人程序是否处于运行状态重启前先确认PLC侧连接已经关闭”。很多半夜的紧急电话其实都是因为现场缺这样一张参数卡。6.3 一个值得保留的习惯先在电脑上把协议逻辑跑通我现在的习惯是任何机器人和PLC的通信项目都先在电脑上做一遍协议回环再上真机。用网络调试助手模拟对端把帧格式、定时器、重连逻辑在PC上验证一遍真机联调时只查参数不查逻辑。这样做最大的好处是省调试时间也避免在现场反复刷机器人程序。回头想想早期几个项目翻车都翻在同一个点上没把字节序和帧边界当回事现场改来改去最后还是靠抓包才定位到问题。通信这种黑匣子只有靠文档和工具才能把它变白希望这份思路帮到你落地时少踩几个坑。本文还有配套的精品资源点击获取