信捷PLC与爱普生机器人Modbus TCP通讯配置实例

1. 项目整体思路：信捷PLC与爱普生机器人如何建起一条数据高速路

做产线集成这些年，遇到最多的通讯需求之一，就是信捷PLC和爱普生机器人之间的数据交换。现场要连的还不只是这两个家伙，旁边往往还挂着一台触摸屏，人机交互、状态监控、指令下发都得靠它。今天这篇就围绕这套组合——信捷PLC、信捷触摸屏、爱普生机器人，用Modbus TCP走以太网，把整个通讯链路从零到一梳理清楚。

我最早接触这类项目时，机器人跟PLC之间基本都是硬接线：你给几个输入点，我给你几个输出点，做一个启停联锁就完事。可一旦信号多了，比如要传当前工件编号、料盘位置、作业模式、报警代码、产量数据，十几根甚至几十根线接过去，脑袋都要炸。而且线越长越容易被干扰，检修起来想死的心都有。以太网通讯最大的价值就在这儿：一根网线，几百个数据点随便传，扩展也容易。

1.1 现场痛点还原：信号太多，硬接线撑不住了

拿一个典型的上下料工位来说：爱普生SCARA负责从料盘抓取工件放到加工工位，信捷PLC侧控制气缸、夹爪、传送带、安全门。触摸屏摆在旁边，操作员要看当前产量、设备状态，要能暂停、复位、切换配方。

机器人需要知道的事情：PLC是否允许下料、当前目标料盘号、夹具是否夹紧。PLC需要知道的事情：机器人是否到位、是否完成取放、有没有报警、当前循环次数。触摸屏要显示和下发的东西就更多了。这些数据要是靠IO点，至少五六十个点打底，布线、测试、故障排查全都麻烦，所以走通讯是最理性的选择。

另外一个隐性需求是远程监控。企业做数字化改造时，总想去车间管理平台实时收集每台设备的产量和运行状态。IO点的数据只能到PLC，想往上走还得靠PLC的通讯口转发。以太网方案天然就是为这个准备的，一步到位。

1.2 协议选型实录：为什么我选了Modbus TCP

在选型上，我最终用了Modbus TCP。原因有几个：第一，信捷PLC的以太网口原生支持Modbus TCP主站，在XDPPro里做配置和指令编程都很顺；第二，爱普生RC系列控制器的RC+软件里，Modbus TCP Server的配置非常成熟，不需要额外授权；第三，Modbus TCP是最开放的工业以太网协议，协议简单、报文透明，调试的时候拿一个Modbus Poll这种PC小工具就能模拟主站或从站，定位问题特别方便。

EtherNet/IP其实也可以，爱普生控制器支持常用工业协议，信捷部分高端型号也支持。但EtherNet/IP的组态比较繁琐，需要定义目标地址、路径、实例，两个品牌之间对表比较麻烦，没有Modbus TCP那么直白。自由协议Socket功能灵活，但功能块要自己写，轮询逻辑、分帧、超时、重试都要自己处理，开发周期长。如果现场用的就是信捷PLC加爱普生机器人，Modbus TCP是性价比最高的选择。

我补充一个对比表，方便大家做技术评审时有底气：

做技术方案最忌讳选一个看着高级但不顺手的东西。Modbus TCP看着不花哨，但它耐造、通用、可控，现场出问题能快速定位。对工程师来说，稳比新重要得多。

2. 硬件准备与网络参数规划

2.1 三台设备的选型与清单

我带过的模拟项目X里，核心设备是这样配的：

信捷XD系列里，我建议选带两个网口或者以太网口和总线口都齐的型号。双网口的好处是：一个网口走机器人和触摸屏这一路业务，另一个网口可以留给后续接上位机或者远程维护，网络隔离做起来方便，不会互相挤占带宽。

爱普生这边，RC90控制器基本是标配，不管带的是LS系列还是T系列都是同一个控制平台。RC+软件对Modbus TCP Server的支持很完整，只做从站的话，不需要另外买通讯选件。这个项目里机器人本体选的是爱普生LS6系列，属于中等负载的SCARA，六轴和四轴在这里区别不大，通讯逻辑完全一致。

交换机这里要特别提醒一句：别用那种几十块钱的家用路由器顶上。工业交换机的导轨安装、宽电压输入、抗电磁干扰特性，是现场长期稳定运行的基本保障。家用交换机在电柜里被变频器干扰到频繁丢包，这种事我见过不止一次。

2.2 IP地址和端口规划：这套组合值得直接抄

IP地址是通讯的基础，我习惯用一个小段，固定IP，全部禁止DHCP。这套组合的地址建议直接抄：

规划要点有几个。第一，所有设备必须在同一网段，避免跨三层交换机或者路由器，小系统一张二层网络足够了。第二，PLC和机器人之间是直接通讯，触摸屏只跟PLC通讯，不直接访问机器人。这个分工很重要，否则机器人控制器要面对两个客户端，逻辑上乱，权限也不好控制。第三，Modbus TCP的默认端口是502，机器人侧不开特殊防火墙的话，保持默认端口最省事，PLC侧指令里填502就行。

调试电脑的IP我建议固定一个，比如192.168.1.100，这样方便反复连接。现场用DHCP不是不行，但经常出现电脑IP一变导致连不上设备，白白浪费时间。

2.3 物理链路与交换机注意事项

以太网通讯看着是软件层面的活，但物理层出问题往往是最难查的。我总结了几条实打实的注意事项：

网线要用超五类或者六类屏蔽网线，水晶头压接要牢，屏蔽层双端接地。工业现场动力线、变频器输出线、通讯线必须分开走线槽，间距至少20厘米以上，不能图方便捆在一起。通讯线一旦贴着动力线走，轻则偶发通讯超时，重则直接掉站。

交换机选非网管的就够用，但要注意供电。导轨式工业交换机一般支持9到36伏宽压输入，不要直接接220伏，要接开关电源的24伏输出。交换机放在电柜里要靠近PLC侧，网线长度不要追求极限，3米5米解决问题是最好的。

再有就是网口指示灯。正常通讯时，PLC网口、机器人控制器网口、交换机的对应端口灯都会稳定闪烁。如果某个灯完全不亮或者均匀闪烁但机器人和PLC之间就是不同步，优先怀疑水晶头接触不良或者交换机电口速率自动协商异常。这个优先级放在排查第一部分，能省很多时间。

3. 爱普生机器人侧配置：从站怎么开、程序怎么沟通

3.1 RC+中启用Modbus TCP Server的完整步骤

爱普生机器人的编程和设置都在RC+里面。连接上控制器后，打开控制器配置界面，找到Communication或者Ethernet相关设置，启用Modbus TCP Server功能。这里通常需要设置监听端口，默认502，保持默认即可。之后规划Modbus保持寄存器区域，比如开放0到49号保持寄存器作为数据交换区。保存并重启控制器，让配置生效。

这里的逻辑我展开讲讲。Modbus TCP从站就是一个“数据超市”，主站拿着地址来读写。爱普生作为从站，它的寄存器地址规则遵循标准Modbus协议：保持寄存器从0开始编号，对应协议里的40001地址区。所以PLC侧访问机器人寄存器地址0，就是Modbus标准地址40001；地址20就是40021。这个对应关系一定不能错，错了就是读错数据。

有一点容易踩坑：有些项目里，PLC侧组态软件看到的寄存器地址会自动加1，比如软件界面上写的是40001，实际指令里要传0。不同软件处理方式不一致，所以我在做点表时会专门加一列，写清楚“PLC指令地址”和“Modbus协议地址”，两边换算清楚再落程序。

启用Modbus TCP Server之后，建议做一个简单的自测：电脑上装Modbus Poll，填机器人IP和端口502，连上去读几个保持寄存器，能正常返回，说明从站已经通了。这一步单独做，可以有效隔离问题，等会和PLC联调的时候，心里就有底了。

3.2 机器人后台任务：寄存器与状态互桥的核心逻辑

有了Modbus从站之后，PLC是可以直接读写这些寄存器的。但这些寄存器跟机器人内部运行数据之间没有自动关联，必须在机器人程序里做桥接：把启动、停止、复位这些PLC下发的控制字读出来，转成机器人的内部变量或者执行动作；同时把自己运行状态、报警码、产量计数写进寄存器，供PLC读取。

下面是我在一个典型项目里用的逻辑结构，SPEL+语法，是示意性质的：

Function ModbusBridge Integer cmd, status, count Do ' 从保持寄存器0号地址读取PLC下发的控制字 cmd = GetModbusRegister(0) ' bit0 = 启动，bit1 = 停止 If (cmd And 1) Then Call StartJob EndIf If (cmd And 2) Then Call SafeStop EndIf ' 将机器人的运行状态写入20号保持寄存器 status = 0 If IsRunning() Then status = status Or 1 EndIf If IsError() Then status = status Or 8 EndIf SetModbusRegister(20, status) SetModbusRegister(21, TotalCycleCount) SetModbusRegister(22, ErrorCode) Delay 50 Loop Fend

这个程序建议在机器人启动时作为后台任务运行，不要放在主任务里阻塞运动程序的执行。爱普生的SPEL+支持多任务，把数据交换任务挂在后台，主任务专心做轨迹运动，两条线互不干扰。

我用的GetModbusRegister和SetModbusRegister是示意名称，真实环境里具体指令名可能叫ModbusGet、ModbusSet，或者从官网的指令手册里查这个名字。写程序的关键是理解数据流，而不是死记指令名——这点对PLC侧同样适用。

再补充一个容易忽略的点：控制字和状态字最好用位定义，而不是整个字直接比较。比如控制字的bit0表示启动，bit1表示停止，bit2表示复位。这样一次写一个字，能同时下发多个命令，PLC侧也方便用位操作。如果整个字做等于比较，很容易出现多个命令同时生效时逻辑绞在一起的情况。

4. 信捷PLC侧配置：做主站，程序怎么写最稳

4.1 XDPPro里的IP设置与Modbus TCP指令组

信捷的编程软件是XDPPro。把PLC的以太网参数设置成192.168.1.10后，接下来就是编写Modbus TCP通讯程序。信捷XD系列实现Modbus TCP主站，主要有两条路：一是图形化组态方式，软件里添加Modbus设备，绑定变量，这种适合简单点表；二是指令方式，用系统自带的Modbus TCP读写指令，适合需要动态控制读写时机和地址的场景。我个人更推荐指令方式，因为可控性强，发现问题好排查。

信捷的Modbus TCP指令一般包括连接建立、连接关闭、读取保持寄存器、写入保持寄存器等。核心参数如下表：

指令的具体助记符在不同型号的PLC上略有差异，以你手上版本的XDPPro指令手册为准。但从参数结构上看，各厂家大同小异，理解这张表的核心，换到其他PLC也就一通百通了。

4.2 控制字、状态字与读写时序设计

通讯程序最怕的不是指令写不出来，而是时序逻辑设计得不合理。我一般把整套通讯拆成三段：开机建立连接、周期读写数据、故障复位与连接重建。

先在PLC上电初始化里执行连接建立指令，指定目标IP和端口，成功后置位一个内部标志。然后周期任务里做两件事：一是读取机器人状态区，比如从寄存器20开始读20个字，存到PLC的D200区；二是根据逻辑需要，把控制信号写到机器人的指令区，也就是从寄存器0开始写20个字。最后，每隔一段时间做一个连接状态的检查，一旦发现通讯失败，重新执行连接建立，同时把相关输出锁断，保证安全。

关于读写时序，有一个非常关键的经验：不要每个扫描周期都去写控制字。控制字的本质是“命令”，命令只在变化的时候才需要下发。比如启动按钮按下，把控制字第0位置1，PLC置位的动作就只这一次。如果每个周期都写，一方面浪费通讯带宽，另一方面机器人那边容易收到重复触发，动作执行两次甚至状态错乱。

控制字的问题用“沿触发”概念解决最好。PLC里用按钮的上升沿去置位一个中间继电器，再把这个中间继电器合入控制字。命令执行完或者复位后，再把对应的位清掉。这样操作员点一下按钮，命令只出现一次，干净利落。

4.3 梯形图示例与关键逻辑讲解

下面一段是核心读写逻辑的示意，XDPPro中的指令块大同小异。我不逐行展开，只挑几个关键点说明。

[上电初始化] SET M100 ; 通讯连接中标志 CALL MB_CONNECT K1, "192.168.1.20", 502, M200 [周期轮询读取 - 每500ms触发] LD T10 MC_READ_H K1, K20, D200, K20, M300 ; D200开始连续20个字，存放机器人状态 [命令写入 - 按钮沿触发] LD X0 ; 启动按钮 OR X1 ; 外部启动 AND M300 ; 通讯正常 MC_WRITE_H K1, K0, D100, K20, M400 ; D100里面放控制字，bit0置位即启动

这里有几个细节需要特别留意。第一，机器人状态读取要持续轮询，不要只读一次就扔在那里。触摸屏显示的是PLC的D区数据，PLC的D区质量直接决定了界面显示的真实性。第二，控制字区D100不要直接写按钮状态，要通过中间继电器构造。否则操作员一松手，启动指令就消失，机器人那边压根判断不出这是一个完整命令。第三，读取指令执行完毕后要观察M300，只有通讯成功的周期里，D区数据才更新。如果通讯中断，PLC要保留上一次有效数据，并主动置位报警区。

还要考虑PLC和机器人控制器的重启时序。实际项目里经常遇到这种情况：PLC已经启动建连，机器人还没就绪；或者机器人程序正在重启，PLC的连接请求被拒。所以PLC侧必须有连接重试机制，比如每2秒尝试一次重连，直到成功为止。我见过不少项目通讯不稳，最后发现就是建连逻辑写得太死，设备一重启就再也连不上了。

5. 触摸屏画面与间接通讯设计

5.1 信捷触摸屏添加PLC与变量绑定

触摸屏这块其实最简单，因为同品牌之间协议天然兼容。信捷触摸屏在组态软件里新建工程，添加设备时选信捷XD系列，通讯方式选以太网，填上PLC的IP 192.168.1.10即可。变量表和PLC内部软元件一一对应，D寄存器、M继电器都可以直接引用。

这里要注意的是，触摸屏的变量类型要和PLC软元件长度对齐。D寄存器默认是字变量，C变量是32位还是16位要看PLC的设定。如果对不齐，触摸屏上显示出来的数字就会有缺口，比如计数器的低16位对上了但高16位飘了。

添加完设备后，建议先用“在线模拟”功能验证一下通讯链路。触摸屏组态软件一般有模拟运行，在电脑上直接跑画面，连上PLC，能实时看到D区数据的跳动。这一步能提前发现绝大多数IP错误和设备选择错误，不用等实际下载到屏幕才发现问题。

5.2 画面功能布局与控制安全细节

画面布局我一般按功能分页，而不是把所有东西堆在一页。主画面放设备总览，状态指示灯、当前模式、急停状态；机器人控制画面放启动、停止、复位按钮，还有运行指示灯、报警指示灯；参数画面放目标料盘号、速度倍率、循环计数；报警画面放最近的报警文本和机器人错误代码。

每个画面的控制组件都要想清楚安全边界。比如触摸屏上的“数据输入”组件写D寄存器时，通讯正常的情况下操作员可能输入一个异常大的数值，导致机器人执行意外的轨迹。PLC里做范围检查是最稳妥的，在上位输入进入控制逻辑前，用比较指令夹住上下限，越界就取默认值同时给出提示。

这里有个经验：普通按钮按下瞬间，PLC对应的输入或变量会产生抖动，PLC里一定要加接通延时，或者用置位指令再配合复位按钮。否则容易造成一次按压触发多次动作。触摸屏按钮本身有按下和释放两个状态，控制字逻辑要根据实际业务选择是“按下有效”还是“按下-释放切换”，设计错了操作手感会很奇怪，还容易误触发。

5.3 触摸屏与机器人的间接通讯设计

触摸屏不直接跟机器人通讯，所有数据都经过PLC中转。这样设计的优势很明显：机器人程序的运行权限、访问周期都只针对PLC一个客户端，逻辑统一，安全性高。如果让触摸屏直接访问机器人，还得在机器人侧再开客户端许可、管理第二套地址映射，没有任何必要。

但也正因为数据经过PLC中转，触摸屏看到的状态实时性，完全取决于PLC轮询机器人的频率。我一般把状态区轮询周期控制在100到300毫秒。操作员看指示灯、看产量数字，这个延迟体感上是实时的。如果轮询周期拉到一秒以上，操作员按键后看到反馈要等半天，体验很差。

再提一个细节：触摸屏上显示的报警信息，最好在PLC里统一编码。比如机器人错误代码是16位的整数，PLC提取后映射到中文报警文本。这样触摸屏的报警画面不需要每个代码做一条记录，而且可以把机器人报警和PLC自身报警统一管理，做单一报警列表。

6. 现场排查实录：常见通讯故障这样定位

6.1 网络层排查：从灯、到ping、到抓包

通讯出问题，我永远先做网络层排查。顺序是这样的：先物理后逻辑，先本机后对端。

第一步，看灯。PLC网口、机器人控制器网口、交换机对应端口的指示灯是否常亮或正常闪烁。灯全灭，八成是网线没插好、水晶头松动，或者交换机端口坏了。灯亮但不闪，说明链路通但没数据，问题在软件层。

第二步，ping。把笔记本电脑接到同一交换机，分别ping 192.168.1.10和192.168.1.20。ping不通，查IP是否冲突、网线是否接错、设备是否没启动完。ping通则基本排除物理链路和IP层问题。

第三步，用Modbus软件做针对性测试。电脑上装Modbus Poll，作为主站连机器人的502端口，如果能正常读写机器人寄存器，说明机器人从站没问题。再用它模拟从站，看PLC能不能正常读写。这样一来，问题到底在PLC侧、机器人侧还是网络中间，立刻清晰。

这个排查顺序我称之为“通信三段法”，能覆盖九成以上的通讯故障。我见过太多人一上来就怀疑程序逻辑，其实最后发现就是一根网线松了。

6.2 数据层排查：地址偏移、字节序错位

物理链路正常、Modbus自测也通，但数据对不上，就得往数据层排查。最常见的两个坑：地址偏移和字节序错位。

地址偏移的坑是这么来的。Modbus协议里，保持寄存器地址0对应的协议编号是40001。有些软件界面显示40001，但底层指令传参要用0。还有一些设备把地址描述成0到99，另一些描述成40001到40100。两边理解不一致，读出来的数据就全错位了。我的处理方式是在点表里同时标两列：协议地址和软件地址，写程序前先对着点表确认一次。

字节序错位也很典型。Modbus TCP在传输多字节数据时是大端字节序，也就是高字节在前。如果PLC和机器人的寄存器地址明明对上了，读出来数字却是乱跳，比如100读出来变成25600，十有八九是字节序没对齐。有些设备提供字节交换设置，信捷PLC侧也可以在指令参数或地址重排上做处理。

这两个问题在爱普生和信捷的组合里尤其容易出现，因为两个品牌的寄存器视图对“地址”和“字节顺序”的表达习惯不一样。我的建议是：联调一开始就先做一个小实验，PLC往机器人寄存器写一个已知值，比如0x1234，机器人读回来看看是0x1234还是0x3412，一次就能确认字节序方向。

6.3 稳定性优化：轮询周期、断线重连与安全冗余

最后聊聊长期跑下来才看得到的稳定性问题。第一个是轮询周期。通讯不是越频繁越好。一次读写要来回几个报文，频率太高，机器人控制器忙于处理通讯中断，反而影响运动控制。我实际测试的经验是：PLC读取机器人状态区100到300毫秒一次足够，写入控制字只在命令变化时执行，不用每个周期都写。这样通讯负载小，机器人运动也稳。

第二个是断线重连。前面提过，PLC和机器人可能因为调试、停电、异常复位等原因出现重启。PLC侧的连接建立指令必须能周期性地重试，直到连接成功。我一般在PLC里加一个连接失败计数，超过三次就触发报警，同时继续尝试重连。这样不需要人工干预，系统能自愈。

第三个是安全冗余。通讯毕竟是软件通道，软件通道有失效的可能。所有跟人身安全、设备安全相关的回路，绝不允许只依赖通讯。急停、安全门、光栅这些硬回路必须单独接硬线到PLC的专用输入，同时物理串进机器人安全回路。通讯状态、机器人状态这些都只是监控信息，不能作为安全判断的唯一依据。

第四个是寄存器表版本管理。这个说多了都是泪。现场改地址、改映射太常见了，没有一张Excel点表对齐两边的寄存器定义，迟早会出一场无声的“数据鬼故事”。我的习惯是每个项目从联调第一天就维护一张寄存器映射表，改任何一边先改表再改程序，两边同步，绝不断档。

这套信捷PLC加爱普生机器人的Modbus TCP通讯方案，我在好几个项目里跑过，稳定性和调试体验都算上乘。最后分享几个长期维护的心得：一是通讯状态一定要有监视画面，别等报警了才去查；二是寄存器表用Excel做好版本管理，改一个地址，两边同步改，不然现场容易出鬼故事；三是如果现场有急停回路，千万不要把急停做成软通讯，物理回路永远是第一道防线。按这个思路去实施，这套通讯基本不会给你捅出什么大篓子。