企业官网建设流程全解析

简介：工业自动化场景中，安川机器人与 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在机器人场景的适用边界

下面这张表是很多项目里实际使用的决策依据，按数据特征选协议，而不是按品牌习惯选。

有一点需要提醒：用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或简单的异或。

字节序是另一个高频坑。很多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坐标是1000（0x000003E8），PLC读出来却是16256或2608这种奇怪数值。原因基本是字节序不一致或数据类型长度不匹配。安川机器人和部分PLC在字节序上的默认习惯不同，如果一方按大端解释、另一方按小端输出，每个字节都会错位。另外，把INT（16位）数据当成DINT（32位）读，或者把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上验证一遍，真机联调时只查参数不查逻辑。这样做最大的好处是省调试时间，也避免在现场反复刷机器人程序。回头想想，早期几个项目翻车都翻在同一个点上：没把字节序和帧边界当回事，现场改来改去，最后还是靠抓包才定位到问题。通信这种黑匣子，只有靠文档和工具才能把它变白，希望这份思路帮到你落地时少踩几个坑。

本文还有配套的精品资源，点击获取