企业官网建设流程全解析

前阵子在做一条小型装配线的上下料改造，柜子里一台信捷PLC负责夹具和输送带的动作，旁边一台爱普生六轴机器人要按节拍抓放件，操作工还希望触摸屏上能看到机器人当前位置、报警代码，并且能一键切换自动和手动模式。三个设备，三种控制出身，绕不开的核心问题就一个：它们之间怎么用以太网把数据稳定地通起来。

翻阅资料的时候发现相关的说明书大多各讲各的——PLC手册只讲PLC侧指令，机器人手册只讲机器人侧函数，很少有一篇内容把PLC、触摸屏、机器人放在一起说清楚：谁做客户端、谁做服务端、帧格式怎么约定、断线了怎么恢复。这篇文章就专门补这个缺口，把我在现场跑通的一套信捷PLC与爱普生机器人以太网通讯方案完整拆开，包括网络规划、PLC梯形图逻辑、机器人SPEL+程序、触摸屏调试界面，以及联调中几次把产线卡住的真实踩坑记录。

1. 这套网络要解决什么问题：PLC、触摸屏、机器人各自的角色

1.1 三条数据流，搞清楚谁和谁说话

先把三个设备的职责理清楚。PLC是整个系统的逻辑大脑，负责气缸、电磁阀、输送电机这类现场执行器，同时还要根据机器人返回的状态决定下一步动作。机器人在这个方案里是纯执行机构，接到指令就抓取、放料，干完活要告诉PLC“我到位了”。触摸屏则是一块交互窗口，操作工在上面按启动、看报警、切模式，顺便监视刚才说的每一条通讯链路是否还活着。

数据流其实就是三条：

很多人第一次做这种集成的时候，容易一上来就写程序，但其实最需要先画清楚的恰恰是这三条数据流。谁主动、谁被动，决定了后面选Socket还是Modbus TCP，也决定了帧格式里的功能码要设计成什么样。我见过有同行把机器人状态回传设计成PLC轮询去读，结果PLC一个扫描周期只有十几毫秒，轮询占用大量Socket通信时间，反而把真正关键的指令下发给挤掉了。所以我的原则是：所有控制指令由PLC主动发，机器人只做应答和主动上报；触摸屏只和PLC交互，不直接碰机器人。

1.2 为什么不继续用IO点硬接线或串口

说完数据流，用一个反常识的事实开头：现在很多老产线改自动化，第一反应还是“用IO点对接”。机器人给PLC一个“运行中”信号，PLC给机器人一个“启动”信号，上下料点位少的话，十几根线确实够了。但这种方案在功能上有一个巨大天花板——IO点只能传0和1，你无法通过一根线告诉PLC“机器人报警是E201还是E306”，也传不了坐标、速度、循环次数这些真正有价值的运行数据。

等到调试阶段就会发现更痛苦的事情：只要机器人或PLC任何一个程序逻辑改动涉及信号重定义，就要改接线、改点位表、改两边程序，三份文档来回对。串口RS485方案稍好一些，能传字符串了，但波特率通常只有9600或19200，一条产线上有触摸屏、有PLC、有机器人，串口主从轮询的逻辑本身就够写半天，而且一旦触摸屏也要占用这个串口链路，整个系统的通讯周期就会被拉得很难看。

以太网方案的好处在于：一根网线把三台设备全部并联进同一个局域网，数据量从“0/1状态”直接升级成“最多一次收发几百字节的自定义报文”，而且还能在触摸屏上做连接诊断——哪条链路断了、多久没收到心跳，一目了然。下面这套方案，本质上就是用一根网线和两段几百行的逻辑，替换掉原先需要几十根线外加三份点位表才能干完的活。

2. Socket自由口和Modbus TCP，我为什么选前者

2.1 两种协议的差异和适用场景

以太网通讯方案不是只有一种，实际工程里最常摆上台面的是两个选项：Socket自由口通讯和Modbus TCP。我把它们的适用场景放在一起对比一下。

选Socket方案的原因很直接：这个场景里PLC要主动控制机器人去抓取、放料、回原点，机器人在动作完成后要主动告诉PLC结果。这种双向主动、一问一答的交互用Socket自由口天然合适——你随时可以给对方发一帧自定义内容，对方也可以随时给你回一帧。Modbus TCP本质上还是一个主站轮询从站的模型，机器人扮演从站角色后，想主动报告“我报警了”还得等PLC下一次轮询到报警寄存器才能被看见，中间多了好几秒的延迟窗口。

不过我不建议把Modbus TCP一棒子打死。如果你的PLC型号以太网固件直接支持Modbus TCP主站功能，机器人侧又能通过I/O Server把它内部的内存区映射成寄存器，那在设备维护层面确实占优势——标准化协议，第三方工具随便读，触摸屏自己也能直接抓机器人寄存器。我这次主链路用Socket，同时保留了Modbus TCP通道做状态镜像，算是两条腿走路。

2.2 自定义ASCII帧格式设计

Socket自由口意味着帧格式完全由自己定义。这一步如果设计得烂，后面联调会痛不欲生。我用的方案是一个简单的HEX字节帧，结构如下：

为什么用HEX而不用纯ASCII字符串？因为HEX解析起来效率高，字符串处理函数在PLC梯形图里远不如在机器人SPEL+里方便，而且HEX的每个字节都代表确定含义，长度固定，不容易出现“字符串多了个回车换行导致解析错位”的诡异问题。

帧头一定要固定两个字节，别只用一个字节。TCP是数据流协议，不存在报文边界，接收端收到的是连续的字节流。半包、粘包是必然出现的，只有靠固定在帧头连续出现的两个特征字节来“对表”，才能在字节流里把每一帧完整切出来。怎么切呢？逻辑就是：逐字节扫描，发现0xA5 0x5A后，继续取1字节功能码、2字节长度，再把长度字段指定的字节数取完，最后校验CRC，一帧才算完整合法。

2.3 网络拓扑与IP规划参数表

下面是这套系统实际的网络参数，我建议你直接抄，多数情况下不用改：

子网掩码统一255.255.255.0，网关留空。这里有个原则：纯本地局域网环境，网关不要填，填了反而可能出现设备通过网关转发数据包的超时等待。拓扑上用一个工业交换机把四台设备连起来就好，不需要路由器。

端口号选了2000和3000，都是1000以上的高位端口，有效避开常见的系统服务和协议占用。PLC作为TCP客户端，不需要监听固定端口，本地端口只要不和机器人冲突就行。机器人作为服务端，监听2000端口，整个机构只需要一个监听Socket就够了。

3. 设备侧的参数配置：这一步最容易出低级问题

3.1 信捷PLC网口初始化

信捷的XDH系列PLC在XCPPro软件里配置以太网，入口在工程树的“以太网配置”或者“通信配置”里，不同固件版本菜单名略有出入。进去以后填IP地址192.168.1.10、子网掩码255.255.255.0，保存、编译、下载。写到这里必须强调一个差点让我怀疑人生的细节：信捷PLC的IP参数下载后并不会马上生效，必须整机断电重启。我印象里首次配置时，下载完成后在线监视怎么看IP都是对的，但是机器人侧连接就是超时，最后把PLC断电再上电，通讯“啪”一下就通了。

另外，用Socket通讯之前先确认PLC的固件版本支持以太网自由口通讯指令，不是所有带网口的信捷PLC都把Socket指令开放出来的。查看方法是在指令列表里搜索类似于OPEN、SEND、RECV、CLOSE这一组指令，找不到或者显示灰色不可用，说明固件版本不对，先升固件再谈通讯。

3.2 爱普生机器人网络设置

爱普生机器人控制器的IP设置通常在RC+软件的控制器配置页面里，也能在示教器的系统设置菜单中修改。改完同样需要重启控制器才能生效。这一侧比较容易忽略的是控制器内置Windows系统防火墙。我遇到过IP、端口、程序全是对的，机器人侧就是收不到任何数据的情况，最后发现是控制器防火墙默认拦截了TCP 2000端口的入站连接。解决方式是在控制器系统设置里把2000端口加入入站规则，或者内网环境下直接把防火墙关闭。

还有一个小坑和连接通道数量有关。爱普生的TCP Socket服务端默认允许的并发连接数有限，如果你在调试阶段开了多个调试工具反复连接机器人，之前的连接没有被正确释放，新连接可能根本建不上。遇到这种情况，最省事的做法是重启控制器，把无效连接全部清掉，再重新连接。

3.3 触摸屏入网与变量映射

触摸屏相对简单，它的角色是PLC的上位设备，不走Socket，而是通过信捷自己的以太网组态协议和PLC周期性交换数据。在触摸屏组态软件里添加一个“以太网设备”，目标IP填192.168.1.10，然后定义变量时直接勾选PLC的软元件地址（比如D区、M区），触摸屏就会自动按采集周期去读写。

这里有一个设计原则要特别讲一下：触摸屏上所有可操作项，只能写PLC的交互区地址（比如D100指令字、M100启动按钮），不能直接写状态区地址。后面第6章的踩坑里，我会专门说这个原则被破坏以后发生了什么。采集周期默认500ms或者1秒足够，不用追求太快，触摸屏写操作瞬间完成，但PLC逻辑里会有自己的去抖和互锁，通讯采集周期只要比PLC逻辑扫描周期快就行。

4. PLC端梯形图的核心逻辑：状态机与心跳缺一不可

4.1 数据交互寄存器规划

Socket通讯的梯形图写起来容易乱，极容易一坨梯形图叠下来后面维护的人想骂街。我建议先把寄存器规划成一张表，逻辑只对着表写：

这张表的第一个原则是把触摸屏交互区和程序执行区彻底分开。D100-D120是触摸屏区域，D200往上是程序运行区域。触摸屏可以读状态区但不能写，执行区的数据触摸屏一概不管都会乱套。第二个原则是每个Socket操作都要配一个忙碌标志，防止一个扫描周期内指令被重复触发，这个原则是整个PLC侧程序能不能稳定运行的核心。

4.2 Socket指令的正确触发方式

Socket自由口通讯在信捷PLC里的实现方式，是一组以太网通讯指令配合一个连接ID来管理连接。逻辑可以简化为：先执行建立连接类指令，连接成功以后再执行发送和接收。

我最想提醒的是触发方式。这类指令必须在上升沿或者完成标志的控制下执行，绝不能用普通线圈直接驱动。举个例子：如果你把一条发送指令直接接在一个常开触点上，PLC每一扫描周期都会尝试执行一次发送，Socket的发送缓冲区瞬间就会被塞满，表现就是程序下载后前几秒通讯正常，后面彻底死掉，连重启都救不回来。

正确的做法是把发送流程做成一个小状态机，保证每一时刻只有一条Socket指令在动作：

上电 -> 延时2秒 -> 建立连接 建立连接 -> 等待连接完成标志 连接完成 -> 发送心跳帧 发送完成 -> 等接收应答 收到应答 -> 刷新看门狗定时器 看门狗超时 -> 断开连接 -> 重新走建立连接流程

梯形图里具体实现就是把各个阶段做成步号，用一个当前步寄存器保存运行到哪一步了，每个扫描周期只执行当前步对应的动作，同时满足跳转条件以后才更新步号。这样做的好处是即使通讯发生异常，也能通过步号复核“现在卡在哪一步”了。

4.3 心跳与断线重连设计

以太网通讯最怕的是物理链路没有断，逻辑连接却已经死了。TCP连接在网线松动或对端程序重启的时候，本端不会立刻感知，必须靠应用层心跳来判断。

心跳设计我采用定时500ms一帧。PLC每隔500ms向机器人发一帧心跳（功能码0x10），机器人在收到任何帧之后必须立即应答。PLC侧用一个定时器做看门狗：收到任意一帧合法数据就复位定时器，定时器累计10秒没有被复位，判定断线，置M1报警，断开连接，延时3秒后重新发起连接。

为什么定10秒？太短了，机器人正常执行运动指令时是没办法及时应答通讯请求的，你让它在运动时读Socket、解析报文，又得让它同时保持轨迹精度，两个动作竞争同一个控制器资源，很容易把超时时间吃掉。太长又会让操作工失去警惕。10秒这个值兼顾了两边，我试过好几条线都用它，至今没有误报。

PLC端代码逻辑的核心代码如下，表达成步进式描述：

当连接成功标志M0=OFF且断线报警M1=OFF: 延时2秒后置位连接请求，执行OPEN指令 连接成功M0=ON: 启动0.5秒脉冲定时器，每次脉冲产生心跳发送请求 D200-D203赋值为帧头+功能码0x10+长度+校验 执行发送指令，发送完成后立即开始接收等待 接收完成标志=ON: 将接收缓冲区数据移入D300开始的一段连续区域 调用CRC校验子程序，校验通过则复位看门狗定时器 根据功能码分发处理：0x10心跳应答、0x80状态上报、其它功能码按需处理 看门狗定时器达到10秒: 置位M1断线报警，执行CLOSE指令断开连接 延时3秒后自复位M1，重新请求建立连接

5. 机器人端SPEL+程序：接收、解析、执行、回传

5.1 连接与读写的核心代码骨架

爱普生机器人用的是SPEL+语言，语法接近BASIC，对于做过PLC的工程师来说不难上手。机器人在角色上作为TCP服务端，监听端口2000，程序主循环里不断调用读Socket的函数，取到数据就进解析逻辑。代码骨架大概是这样的：

Function Main Integer ch String InData$ ch = 1 ' 打开TCP服务端，监听2000端口 OpenTCP# ch, "192.168.1.20", 2000, 0 Do ' 尝试读取最多64字节，超时设100ms ReadTCP# ch, InData$, 64, 0, 100 If InData$ <> "" Then Call ParseFrame(InData$) EndIf Delay 50 Loop Fend

注意OpenTCP#的参数顺序和含义，不同版本的RC+软件可能有差异，以你机器里的指令字典为准。但整体思路是一样的：先绑定一个通道号，然后指定IP和监听端口，打开以后进入轮询读取。

5.2 指令解析和动作执行

读到的InData$是一串字节流，可能是半包、可能是两帧粘在一起。解析函数里必须按帧头扫描的方式切帧。SPEL+里有字符串函数可以逐字节取，也可以用变量映射的方式把字节流转成数值数组。核心逻辑：

Function ParseFrame(Buffer$) Integer i, FrameLen, FuncCode Integer DataLen String Frame$ ' 从Buffer$里找到帧头0xA5 0x5A i = InStr(Buffer$, Chr(&H5A)) ' 简化示意 ' 取功能码和长度 FuncCode = Asc(Mid$(Buffer$, 3, 1)) DataLen = Asc(Mid$(Buffer$, 4, 1)) + Asc(Mid$(Buffer$, 5, 1)) * 256 ' 按长度截取完整帧 Frame$ = Mid$(Buffer$, 1, 5 + DataLen + 2) ' 校验CRC，校验通过后分发 If CheckCRC(Frame$) = 0 Then Select Case FuncCode Case &H01 Call RunPickPlace() Case &H02 Call GoHome() Case &H03 PauseProgram Case &H10 Call SendHeartbeatAck() Case Else Call SendErrorCode() EndSelect EndIf Fend

实际现场我建议把SendHeartbeatAck这种只有几个字节的应答做成一个独立子程序，不要让心跳应答和正常状态上报混在一起。机器人每收到一条心跳就回一条固定短帧，PLC那边的看门狗就能连续复位，这一链路是否健康在触摸屏上随时能看见。

5.3 状态回传与报警代码

机器人执行完一个动作以后，要把运行结果主动回传给PLC。这个动作对应功能码0x80状态上报，数据区里面至少包含三个字段：当前状态（运行中/空闲/暂停）、报警代码、机器人当前位置坐标（如果PLC需要）。

回传帧格式：

帧头0xA5 0x5A + 功能码0x80 + 数据长度0x000A + 状态字节1 + 报警代码2字节 + X坐标4字节 + 完成标志1字节 + CRC16

关键点在于：机器人每次回传的帧格式必须和PLC端解析逻辑完全一致，包括字节序和每个字段的位置。我在联调现场吃过字节序的亏，后面第6章专门说。这里先给一个经验性的建议：发坐标数据时，四个字节的低位在前还是高位在前，必须在协议文档里写死，并且最好用一个简单例子标明（例如坐标值12345对应的HEX字节序列是什么），不然两边工程师对字节序的理解不一致，联调时就等着崩溃吧。

5.4 断线重连策略

机器人的TCP服务端程序还有一个要在主循环里体现的细节：OpenTCP#成功之后，如果PLC断线重连，机器人侧需要能够自动识别旧连接失效并接受新连接。爱普生Socket服务端的实际行为是：如果之前建立的连接还挂着，新的连接请求是进不来的。

所以机器人端程序不要只写一个单纯的轮询循环。建议在主循环里再加上连接状态的定时检查：如果读取Socket超时超过一定时间，主动关闭当前连接，重新执行一次OpenTCP#，让服务端回到可接受新连接的状态。这样即使PLC侧完全断电重启，机器人端也能在几秒内自动恢复监听，不需要人工去按示教器。

6. 联调中真实踩过的几个坑

6.1 Socket指令不能连续触发，否则直接卡死

这是最典型的PLC侧问题。当时通讯程序刚写好，下载到PLC里，运行起来头几十秒一切正常，收发都顺畅。过了大约两分钟，机器人不再回应，心跳超时报警。我最初怀疑是机器人侧程序崩溃了，查看RC+监视窗口却发现机器人程序还在正常运行，只是接收不到东西。

后来用调试电脑模拟机器人侧抓包才发现，PLC侧程序一直在以扫描周期的高频率往Socket缓冲区里重复写数据，缓冲区撑满以后，后续发送全部失败，但PLC程序本身并不报错。排查回梯形图，发现发送指令被放在了一个普通线圈逻辑里，导致每一扫描周期都在重复触发。把发送逻辑改成上升沿触发并加上发送忙标志以后，问题一次性解决。所有Socket指令的触发务必以脉冲方式执行，一条指令没执行完，绝不触发下一条。

6.2 掉电后IP参数丢失的迷惑现象

第二个坑发生在一台新到货的PLC上。我配置完IP地址、下载完程序，当场测试一切正常。隔了一晚上，第二天开机通讯全断，在线看PLC的IP地址发现回到了默认的192.168.1.X。后来查手册才知道，信捷PLC在部分固件版本下，以太网参数只在RAM里生效，掉电以后不会再恢复，必须重新配置或者确认参数保存操作正确。

处理方式看起来很简单——重新设置并断电重启验证。但这个坑的迷惑点在于：如果程序是在办公室下载好，拉到现场才发现IP丢了，又没有随身带编程电缆，整个调试就会被迫中断。我现在每配好一台PLC的IP都会连续断电重启验证两次，确保掉电保存没问题才往现场发货。

6.3 数据错位和校验不一致的排查

还有一次是机器人回传的报警代码在触摸屏上显示成了乱码，怎么读怎么不对。用电脑抓包看数据，机器人端确实发出的是预期的数据字节。再往PLC的接收缓冲区一查，数据也没丢，但按字读取的时候高低字节反了。

问题出在字节序约定上。机器人端按“高字节在前”填充报文，而PLC梯形图处理时按小端方式把两字节合并成报警代码，结果0x0231被读成了0x3102，典型的高低字节颠倒。这个问题的麻烦在于通讯链路本身没有故障，程序也没有报错，人眼检查协议文档也能对得上，唯独合并字节顺序反了。

从那以后我养成一个习惯：协议文档里必须用一个带具体数值的示例报文，把每两个字节的排列顺序标出来。联调时先用示例报文做基准测试，两边确定读出来一致以后，再写正式的解析和组装逻辑，不然在字节序问题上耗掉几个小时是很常见的事。

6.4 触摸屏强制置位把机器人状态字给覆盖了

最后一个坑比较隐蔽，而且完全是人祸。联调阶段我在触摸屏上做了一个调试页面，为了快速验证机器人状态，直接在数值显示控件里把D110设成了“可读写”，这样操作工模式下也能看到状态字实时变化。结果一次调试中，操作工在屏幕上想按下“复位”按钮，不小心通过数值框写入了0，PLC侧一个判断条件把机器人的状态识别成“空闲”，紧接着就发出了一个本不该发出的启动指令。

好在机器人本身有安全逻辑没有执行，否则整个流程就乱了。这事的根因在于调试页面和控制页面没有分清权限。现在我的做法是：触摸屏上任何写操作都只能走D100指令字，PLC在梯形图里把指令字解释成具体的启动、复位、暂停逻辑，D110这类状态字在触摸屏上永远只读。联调阶段的“强制写入”需求，也只允许通过中间变量M区做转发，绝不直接往运行状态字里写。

7. 触摸屏调试页：联调效率提升的关键

7.1 调试页要显示什么

很多工程师喜欢用PLC软件自带的在线监视功能去联调，软件界面切来切去，看机器人状态还得接着RC+监视窗口，效率很低。我强烈建议在触摸屏上专门做一页“联调监视页”，哪怕后面上线时把它隐藏起来，联调阶段的作用也不可替代。

这个页面至少要包含四个区域：

• 连接状态区：PLC与机器人的TCP连接标志M0、断线报警M1、心跳看门狗当前计数值，全部用指示灯和数值显示。
• 操作区：模拟触摸屏与PLC之间的指令字D100写入，用按钮或数值框实现，务必只写D100，不要扩展。
• 监视区：D110系统状态字每一个bit的含义做成分解指示，D120机器人报警代码直接数值显示。
• 报文区：最近10帧PLC发出的和收到的原始报文，用十六进制字符串显示。这个功能可以把PLC内部接收缓冲区里的数据原样映射出来，结合机器人侧RC+的监视窗口对照，就能立刻判断是发的问题还是收的问题。

这个页面的价值在于：联调时你站在触摸屏前面就能同时把握PLC逻辑、机器人回传、Socket链路三者的实时状态，不用在三台设备和两台电脑之间来回跑。尤其是排查那种“偶尔断一下、过一会又自己恢复”的隐性故障，没有这种汇总页面的排查会非常痛苦。

7.2 强制置位和报文监控的配合用法

联调时的常用操作套路是：先在操作区写入D100=1（启动指令），跑到报文区看PLC是否发出了对应的0x01帧；然后切到机器人侧RC+监视窗口，确认机器人收到了；机器人执行完，再看报文区有没有收到0x80状态上报帧；最后看D110的状态字bit2是否置位“运行完成”。

这套流程跑通以后，通讯链路基本就是可靠的。剩下的问题大概率集中在具体指令语义上，那是机器人运动和PLC时序逻辑之间的配合问题，跟通讯链路本身已经无关了。

如果某个环节卡住，先按“链路—格式—逻辑”三层排查法：第一层看TCP连接是否建立（M0是否ON），第二层看报文格式是否合法（帧头和校验是否通过），第三层看逻辑判断条件是否满足（D100指令字的去抖、互锁是不是有问题）。只要确保每一层都有触摸屏上能看到的数据支撑，就不会陷入“看起来哪都对但就是不动”的泥潭。

写在后面

把PLC、触摸屏、机器人三台设备拉进同一张以太网，真正困难的地方不在于某个具体指令怎么用，而在于一套所有设备都遵守的交互约定，以及一套从握手、心跳到断线重连的可靠性机制。协议要写死、字节序要统一、Socket指令触发要克制、触摸屏权限要收紧，这几条做到了，通讯这块基本就稳了。

最后再分享一个小技巧：把我的自定义帧格式画成一张大表，连同IP地址、端口、字节序示例一起打印出来，贴在控制柜门上。联调的时候所有参与的人对着同一张表说话，比任何人的记忆都可靠。以后维护人员换了一轮又一轮，这张表也能让新接手的人少走很多弯路。