简介这是一份围绕安川机器人与PLC实现UDP/TCP通信的工程指导资料覆盖协议原理、参数配置、数据收发、错误检测与恢复以及MODBUS TCP、EtherNet/IP等工业协议选型适合现场调试工程师和自动化项目开发人员。压缩包共189个文件、约81.44MB主体是C#编写的超级通信调试工具工程包含源代码、资源文件、可执行程序与PDF/TXT说明文档另附示意图与图标等辅助资料。目前已有1558人学习内容可作为搭建机器人—PLC通信测试环境的直接参考也可用于排查传输不稳定、数据丢包等实际难题工具源码结构清晰便于二次开发和集成到现有产线。总体而言这份资料把理论原理、配置流程和可运行工具整合在一起能帮助使用者快速验证UDP/TCP链路并理解双方通信机制减少现场调试时间。1. 安川机器人与PLC进行UDP通信与TCP通信协议选型决定现场调试的顺畅程度拿到一份《安川机器人与PLC进行UDP通信与TCP通信指导手册.zip》时多数人第一反应是找报文格式、端口号、指令写法。但真正在产线上跑过几年的人会告诉你UDP和TCP的选型错误比参数配置错误更容易让调试现场变成玄学现场。安川机器人YRC1000、YRC1000micro等控制器与西门子、三菱、汇川等PLC之间的以太网通信实际场景里七成问题不是“连不上”而是“连上了但数据不可靠”。这篇笔记适合两类人一类是刚接手机器人集成项目、需要在PLC与机器人之间建立联锁信号的电气工程师另一类是已经能Ping通设备、但被偶发丢包、频繁断连、乱码折腾过的现场调试人员。我会把两种协议的选型依据、落地配置、报文设计和排错路径一次讲透。2. 先做选择题UDP还是TCP区别不在速度在可靠性2.1 TCP三次握手和UDP无连接两条链路的行为差异TCP通信建立连接前要先经过三次握手Client发送SYNServer回复SYNACKClient再回ACK之后才算建立了一条可靠的字节流通道。这条通道有确认机制、超时重传和顺序控制对方没收到数据发送方会感知到。代价是连接建立有延迟、需要维护连接状态、单条连接占用资源更多。UDP则完全没有握手过程发送方只管把数据报丢到网络上不关心对方是否收到、顺序是否错乱。它的优势是协议栈开销小、发送延迟低、实现简单一台设备往多个目标发数据也很容易。代价是丢包只能靠应用层自己发现。工业现场最常见的误导是“UDP比TCP快所以机器人通信用UDP合适”。实际上对于启动、停止、复位、完成确认这类联锁信号一包数据几十个字节TCP的握手开销在微秒到毫秒级对工艺节拍几乎无影响。真正需要UDP的是高频数据流场景比如机器人实时坐标输出、焊枪电流采样每秒几十上百包这时候TCP的重传机制反而会把链路搞乱。2.2 机器人侧的现实约束控制器型号、通信选项和Socket数量选型不只是协议理论问题还得看安川机器人控制器实际给了什么能力。常见控制器如YRC1000和YRC1000micro标准配置往往带以太网口但Socket通信功能可能属于选装选项。如果现场机器人没有开通对应选项你在INFORM任务里写通信指令也执行不了这是不少调试人员第一次翻车的地方。另外要关注Socket通道数量。有些控制器型号同时只支持有限数量的Socket连接如果你既要跟PLC通信又要跟视觉系统通信还要连上位机MotoCom SDK做监控通道就可能不够用。常见做法是给PLC单独分配一条固定通道其他系统走另外的端口或干脆复用同一条连接的不同端口区分功能。还有协议栈实现的差异。机器人侧实现UDP往往比TCP简单这也是很多安川集成商的示例程序优先给UDP方案的原因。但从工程角度简单不等于可靠。如果你做的设备有安全联锁需求TCP的断线可感知特性是UDP给不了的。2.3 选型参考点位联锁走TCP高速数据流走UDP我的选型习惯可以归纳成一个判断表你可以直接抄通信内容推荐协议理由启动/停止/复位/模式切换指令TCP需要可靠送达断线要能感知机器人完成信号、报警码TCP联锁关键信号丢包后果严重实时坐标、姿态、速度数据UDP高频发送允许丢帧数据带时间戳视觉拍照触发与结果回传TCP一问一答结果不能丢日志、配方下载TCP大文件传输需要可靠性和顺序过程曲线采样UDP高频且客户端可容忍偶发丢点如果你不确定选哪个默认选TCP。现场调试时TCP链路通不通、数据到没到Wireshark和PLC侧诊断都能看到明确状态UDP链路一旦静默丢包排查起来很被动。记住一个反直觉结论在机器人通信这种低频小包场景里TCP的可靠性是白送的UDP的“高性能”你根本用不上。3. 安川机器人与PLC的UDP通信端口、报文与超时重发3.1 最小配置步骤IP规划、端口约定和任务启动安川机器人与PLC做UDP通信第一步不是写代码是把网络参数定死。我一般会在项目启动当天就输出一张接口表包含机器人IP、PLC IP、子网掩码、机器人本地端口、PLC本地端口、通信周期、报文格式。不要在现场临时拍脑袋定端口后期多一套设备就得改程序。以YRC1000控制器为例常见做法是在控制器的以太网设置画面里配置IP地址和子网掩码然后在通信参数设置里选择一个空闲端口作为机器人侧本地端口。端口号范围避开常用服务端口即可工业现场我用得比较多的是5000到9000之间的端口例如机器人侧5000PLC侧5001。PLC侧的配置逻辑类似。以三菱FX5U为例使用Socket通信功能时需要先设置对象设备连接配置把PLC侧端口绑定到指定本地端口再在程序里调用Socket通信指令打开UDP通道。西门子S7-1200则通过T块或者开放式通信指令块实现UDP收发。提示UDP没有连接状态PLC侧收不到数据时不会报错。如果你在调试时发现“对方明明发了但这边没反应”先把防火墙关掉再在两台设备上用命令行互相Ping确认二层三层通了再查应用层。3.2 报文格式设计固定长度帧让机器人侧解析最省事UDP报文格式是应用层自定义的这也是团队之间最容易扯皮的地方。我强烈建议用固定长度帧不用变长分隔符。原因很现实机器人的INFORM编程环境处理字符串解析的能力比PLC还弱固定长度帧可以按字节偏移直接截取省去查找分隔符的逻辑。我个人常用的帧结构是32字节定长偏移长度字段说明02帧头固定0x5A 0x01用于同步22命令字0x0001读状态0x0002启动0x0003停止等44数据长度有效数据字节数88时间戳毫秒级Unix时间戳用于新鲜度判断1610状态位/数据区按位定义对应具体信号266保留/校验可放CRC16低字节加填充机器人侧收到一包数据后先检查帧头再检查时间戳是否在200ms以内最后解析命令字和数据区。时间戳这个字段特别重要UDP没有顺序保证一个迟到的旧数据包可能会覆盖新状态没有时间戳你根本发现不了。3.3 PLC侧轮询收发与超时处理PLC侧做UDP通信常见做法是基于扫描周期轮询收发。以三菱FX5U为例Socket通信功能里使用SOCKOPEN打开UDP端口然后周期性调用SOCKRCV读取接收缓冲区用SOCKSND发送响应。西门子S7-1200则可以在OB1里调用UDPSEND和UDPRCV指令块。轮询周期需要跟机器人侧发送周期对齐。机器人每50ms发一包PLC每100ms轮询一次丢包率就会高如果PLC每20ms轮询一次缓冲区里还没攒够数据频繁空读也会增加CPU负担。通常的做法是PLC扫描周期在10ms到20ms之间时通信轮询独立成一个定时中断每50ms或100ms执行一次。超时重发是UDP方案里必须做的应用层逻辑。PLC发出“启动请求”后如果500ms内没有收到机器人的“启动确认”要置一个“通信超时”标志并重复发送请求重发3次仍无响应就报警停机。没有这套逻辑的UDP联锁本质上是把安全交给了运气。3.4 没有机器人也能测一种通用的UDP收发模拟脚本现场调试最头疼的是机器人还没到场PLC程序却要先行验证。我的习惯是写一个简单的UDP模拟器跑在PC上让PC扮演机器人角色。下面是一个通用脚本同时支持UDP和TCP两种模式方便你在没有实物时先把PLC侧逻辑调通。# 简易机器人通信模拟器同脚本支持UDP与TCP两种模式 import socket, argparse, time def udp_server(ip, port): s socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.bind((ip, port)) print(f[UDP] listening on {ip}:{port}) while True: data, addr s.recvfrom(1024) print(f[UDP] recv {data!r} from {addr}) # 收到启动请求(命令字0x0002)后回确认帧0x5A 0x01 0x0002 状态OK if len(data) 4 and data[2] 0x00 and data[3] 0x02: resp b\x5A\x01\x00\x02\x00\x00\x00\x01 s.sendto(resp, addr) print(f[UDP] sent ACK to {addr}) def tcp_server(ip, port): s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind((ip, port)) s.listen(1) print(f[TCP] listening on {ip}:{port}) conn, addr s.accept() print(f[TCP] connected by {addr}) while True: data conn.recv(1024) if not data: break print(f[TCP] recv {data!r}) if len(data) 4 and data[2] 0x00 and data[3] 0x02: conn.send(b\x5A\x01\x00\x02\x00\x00\x00\x01) print([TCP] sent ACK) conn.close() if __name__ __main__: ap argparse.ArgumentParser() ap.add_argument(--proto, choices[udp, tcp], defaultudp) ap.add_argument(--ip, default0.0.0.0) ap.add_argument(--port, typeint, default5000) args ap.parse_args() if args.proto udp: udp_server(args.ip, args.port) else: tcp_server(args.ip, args.port)这段代码的逻辑很简单脚本绑定本地IP和端口后进入循环收到数据先打印出来然后根据命令字判断是否回确认帧。UDP模式用recvfrom拿到发送方地址后原路返回TCP模式在accept建立连接后用recv和send收发。注意脚本里的确认帧是自造的示例格式实际使用时按你们约定的帧结构替换即可。用这个脚本调试PLC侧程序时重点验证三件事第一PLC能否正确发出发送请求第二PLC能否正确解析收到的确认帧第三PLC的超时重发逻辑是否能触发。脚本打印出的每一包数据都可以跟Wireshark抓包文件对照确认应用层和网络层行为一致。4. 安川机器人与PLC的TCP通信Server/Client角色与断线重连4.1 谁做Server谁做ClientPLC做Server机器人做Client更稳TCP通信必须先确定Server和Client角色。我的经验是让PLC做Server安川机器人做Client。理由有三点第一PLC作为产线控制核心IP地址和端口相对固定机器人程序里写死Server地址即可第二机器人任务启动时主动连接PLC连接失败可以重试不会影响PLC主程序扫描第三PLC侧Server监听多个客户端时后续增加上位机、HMI、SCADA系统都不用改机器人程序。如果反过来让机器人做ServerPLC做Client问题也不少机器人任务可能没启动PLC侧连接就会失败而PLC作为控制核心不应该去依赖一个可能没准备好的从站。产线上后期维护人员也更习惯在PLC侧看连接状态这符合“控制核心掌握连接主动权”的原则。4.2 机器人侧连接与数据交互流程握手、发送、释放TCP链路在机器人侧的标准流程是任务启动后先建立Socket连接连接成功后周期性收发数据检测到断线后延时重连。这个流程没什么玄学但有几个细节容易被忽略。连接超时时间一定要做。机器人侧connect一个不存在的IP端口时默认可能要等几十秒才会超时这个时间足够让操作工以为程序卡死了。常见做法是把连接超时设置为3到5秒超时后置一个“通信异常”标志延时5秒重新尝试连接。机器人侧发送频率要跟PLC侧接收缓冲匹配。TCP是字节流协议一次send的数据对端可能分多次收到也可能多次send的数据被合并成一次收到。很多从UDP转过来的工程师在这里踩坑他们默认“发一次就能收一次”但TCP协议栈不保证消息边界。解决办法是报文头里带上长度字段对端按“先读固定长度头再按长度读完整帧”的方式解析。断线检测也不能依赖TCP的keepalive。很多控制器的协议栈keepalive默认参数过长现场等它检测到断线焊缝都完成两个了。常见做法是应用层做心跳机器人每500ms发一个心跳帧PLC在2秒内没收到心跳就判定链路断开这样响应速度可控。4.3 PLC侧TCP收发TSEND_C/TRCV_C与Socket指令的选择PLC侧实现TCP通信主流方案有三类。西门子S7-1200/1500常用TSEND_C和TRCV_C指令块这两个块可以配置成主动连接或被动接收支持连接保持适合不需要频繁建立断开的场景。三菱FX5U则用Socket通信指令通过SOCKOPEN建立TCP连接SOCKSND和SOCKRCV收发数据指令级别的操作更灵活但需要自己管理连接状态。汇川AM系列基于Codesys平台通常用TCP_SendTo/TCP_ReceiveFrom这类库函数结构和三菱类似。不管用哪个平台我建议把TCP连接状态显式映射到一个PLC内部字。例如0表示未连接1表示连接中2表示已连接3表示通信超时4表示对端关闭。这样HMI和SCADA系统通过Modbus TCP或者OPC UA读取这个状态字就能实时监控通信健康度。注意多个PLC品牌同时连接同一台机器人的情况尽量让机器人侧一个端口只服务一个PLC。如果确实要多台PLC给每台分配独立端口否则连接串线后排查起来非常痛苦。4.4 TCP链路标定用时间戳与递增序号测延迟和丢包TCP虽然没有丢包但延迟波动是真实存在的特别是在交换机带满载、网络风暴干扰的产线上。我建议在联调阶段做一次链路标定方法很简单在PLC和机器人之间循环发送带时间戳和递增序号的数据帧连续跑1小时统计延迟分布和乱序情况。标定要覆盖几个时间段空载时、机器人满速度运动时、PLC扫描周期最忙时、其他设备通信高峰时。每个时段采集5分钟数据记录最大延迟、平均延迟、乱序次数。如果发现最大延迟超过500ms网络架构多半有问题优先检查交换机端口双工模式、网线类型、是否有广播风暴。TCP标定还有一个作用验证机器人侧的解析逻辑。递增序号可以测试对端是否重复处理了同一帧数据时间戳可以测试对端是否错误缓存了旧数据。标定做完链路质量有数据说话后续出问题也可以拿这个基线对对比避免双方互相甩锅。5. 避坑清单这五个问题占掉现场通信调试七成时间5.1 Ping通但收不到数据先分端口层还是应用层现象机器人能Ping通PLCPLC也能Ping通机器人但双方都收不到对方的应用数据。原因Ping走的是ICMP协议和应用层端口无关。最常见的原因是PLC侧Socket通信指令没有激活或者端口绑定失败。另一个高频原因是在Windows/Linux调试机上测通了但PLC侧防火墙或网络隔离策略拦了端口。解决先在本机用Python模拟脚本绑定对应端口再在对方设备上用Wireshark抓包看UDP包或TCP SYN包是否到达对端网卡。如果到了网卡但应用层没收到问题在PLC程序如果根本没到问题在网络路径或防火墙。5.2 UDP联锁任务偶发不执行请求-确认-超时重发现象机器人收到PLC的启动信号后有时执行有时不执行重新发一次就正常。原因UDP丢包导致启动请求丢失而PLC侧没有做超时重发机器人侧也没有对重复请求做幂等处理。启动信号通常只发一次丢了就是丢了。解决把“发一次”改成“发到确认”。PLC发出请求后启动500ms定时器收到机器人确认帧则清除定时器超时则重发重发3次仍无响应则报警。机器人侧对相同命令字和相同序号的数据帧做去重处理避免重复执行。5.3 TCP连接反复断开TIME_WAIT、重连周期和连接数现象机器人侧TCP连接建立后不定时断开重连后又断PLC侧监控看到连接状态频繁翻转。原因机器人侧断线重连逻辑没考虑TIME_WAIT状态。每次主动断开连接后操作系统会保留这个连接一段时间期间重建同IP同端口的连接可能失败。另外PLC侧连接数满了也会拒连。解决重连周期至少留3到5秒给前一个连接的TIME_WAIT留足时间。PLC侧主动关闭不用的连接定期清理连接资源。如果PLC和机器人之间有交换机确认交换机没有开启某种老化策略把空闲连接踢掉。5.4 收到的数据全是乱码字节序与字符集排查现象通信建立成功数据也能收到但PLC侧监控看到的数值是乱码或者特别大的负数。原因字节序不一致。PLC的WORD通常是高字节在前大端而某些控制器的协议栈按小端解析或者双方对同一字段的起始位偏移差了一个字节导致所有数据错位。还有一种情况是PLC按ASCII字符串解析机器人却发送了二进制数据。解决先在协议里约定一个测试帧比如发送01 02 03 04 05 06然后双方各自解析并打印逐字节对比。字节序问题在PLC侧用字节交换指令处理偏移问题以协议文档为准重新核对字段。字符集问题约定为纯ASCII或纯HEX不要混用。5.5 PLCSIM Advanced启动失败不报错虚拟网卡与许可证现象S7-PLCSIM Advanced V5.0创建实例后点击启动实例状态一直停在Stopped系统没有任何错误弹窗。原因PLCSIM Advanced只支持绑定到西门子虚拟网卡Siemens PLCSIM Virtual Ethernet Adapter如果电脑没安装这个虚拟网卡或网卡处于禁用状态实例就会静默启动失败。另一个原因是许可证授权问题试用许可证只能同时运行一个实例。解决确认网卡列表中是否存在Siemens PLCSIM Virtual Ethernet Adapter没有就重装软件或手动安装虚拟网卡驱动有则启用并手动指定实例绑定该网卡的IP。同时确保以管理员身份运行软件并在许可证管理器里确认实例数未超限。这类问题不报错最难查第一步永远是看网卡和许可证。6. 进阶验证用Wireshark和模拟器把链路调通再进现场6.1 抓包验证三次握手与端口过滤联调阶段Wireshark是通信调试最有效的工具。在机器人侧或PLC侧的镜像端口上抓包过滤规则可以直接锁定通信双方。UDP链路用udp.port 5000过滤指定端口的数据包TCP链路用tcp.port 5000观察完整的TCP三次握手过程SYN、SYNACK、ACK。如果只看到SYN发出去但收不到SYNACK说明对端没有监听端口或中间网络被拦。如果握手成功后出现RST包说明一方主动关闭了连接。抓包还有一个容易被忽视的价值确认应用层报文是否正确。Wireshark的“Follow Stream”功能可以还原整条TCP流的内容直接检查报文头、命令字、时间戳是否与协议约定一致。这个功能比在PLC和机器人两侧分别加日志快得多。6.2 模拟器先跑MotoSim和Process Simulate做虚拟联调没有机器人在手不代表PLC程序不能完整验证。我一般推荐两级验证第一级用前面给的Python模拟器纯测PLC侧的收发逻辑和超时重发逻辑第二级用安川的MotoSim离线仿真软件加载机器人模型配合PLC模拟器做虚拟联调。如果项目有工艺仿真需求Process Simulate这类软件可以通过OPC UA与西门子PLC通讯把机器人运动逻辑和PLC逻辑在虚拟环境里跑通。这两种方式的价值在于现场调试时间从几天压缩到半天因为通信协议、报文格式、超时逻辑这些最耗时间的部分已经在办公室用假设备验证过了。现场需要做的只是改IP地址、端口号然后把模拟器换成真机器人。6.3 一套收发任务模板UDP/TCP切换只改初始化我最后说一个对做同类项目最有用的习惯把机器人侧的通信程序分成初始化、周期收发、错误处理三段协议类型只影响初始化和连接管理部分的代码收发缓冲区处理完全共用。这样做的好处是同一套逻辑既能跑UDP也能跑TCP换PLC品牌时只需要改端口和IP不用重新写收发逻辑。我现在接手这类项目一定会先做两件事第一输出通信接口表把IP、端口、帧格式、超时时间、心跳周期全部定死第二在办公室用模拟器把PLC侧程序跑通抓包存档。这两步做完现场几乎不会出现“两个工程师隔着机器互相猜对方程序有没有BUG”的局面。数据交互的坑绝大多数在协议设计阶段就能填平。希望帮到你。本文还有配套的精品资源点击获取