最近刚折腾完一个现场改造欧姆龙NJ系列PLC和一台FANUC发那科机器人做EtherNet/IP通信测试。项目记录里当时随手打成了Ethrenet ip实际上就是EtherNet/IP大家理解成同一个东西就行。这种PLC和机器人之间的网络通信听起来不是什么登天难事但真到现场联调协议版本、字节顺序、RPI参数、I/O映射方向随便哪个坑都能卡住大半天。这篇文章把整个流程完整梳理了一遍从方案选型、硬件准备、PLC侧配置、机器人侧配置到联调验证和故障排查尽量写细写透。如果你正要接手欧姆龙PLC和FANUC机器人走EtherNet/IP通信的活儿或者只是想在脑子里建立一个这类项目到底怎么落地的框架都可以参考这份记录。1. 通信方案选型与整体设计思路1.1 为什么选EtherNet/IP而不是其他现场总线做PLC和机器人通信摆在桌面上的方案其实不少Modbus TCP、EtherNet/IP、Profinet甚至传统的I/O硬接线。如果设备是欧姆龙PLC配FANUC机器人EtherNet/IP往往是第一个值得认真评估的方案。原因有三。第一欧姆龙的NJ/NX系列本身就内置了EtherNet/IP端口不需要额外购买通信模块。FANUC机器人控制柜只要开通了软件选项也直接支持EtherNet/IP。两边都是原生能力软硬件成本最省。Modbus TCP虽然两边也支持但FANUC那边做数据映射时往往要绕更大的弯子Real time性能和EtherNet/IP的隐式报文模式比还是有差距。第二EtherNet/IP的数据交换基于CIP协议属于周期性实时刷新和Modbus那种一包一包请求-应答的模式完全不同。这次使用的RPI请求包间隔是10ms实际测试下来PLC到机器人的数据刷新稳定在10ms级别响应非常平滑。如果走Modbus TCP去刷同等规模的数据通讯负载、CPU占用都会明显增高。第三从长期维护角度看EtherNet/IP在北美和日系设备圈子里非常普及。后续如果产线再加设备比如AB的PLC、第三方伺服驱动器很多都能直接兼容不会把通信方案写死。这种生态通用性在项目初期看不见等到扩产升级时才知道它的价值。当然EtherNet/IP不是万能的。如果现场PLC用的是西门子博途生态Profinet往往更顺如果只传几个简单的状态字和启停信号且对实时性要求不高Modbus TCP完全够用。方案这东西永远是够用、好维护、团队熟悉优先不要为了技术上的光鲜去引入不必要的复杂度。1.2 整体网络拓扑与设备选型这次项目的具体设备配置是欧姆龙NJ301-1200 PLC带内置EtherNet/IP端口和FANUC R-30iB Plus控制柜搭配的机器人型号是M-710iC/50。通信方式选了最稳妥的PLC和机器人通过工业交换机相连而不是直连网线。直连也能通但产线上一般还有其他设备需要访问机器人比如工程师的调试电脑留个交换机接口会方便很多。网络拓扑非常简单欧姆龙NJ301192.168.1.10子网掩码255.255.255.0FANUC R-30iB Plus192.168.1.20子网掩码255.255.255.0调试电脑192.168.1.100子网掩码255.255.255.0工业交换机非网管型千兆工业交换机这次用的是一台6口小交换机有个细节值得提醒调试电脑务必和PLC、机器人在同一个网段否则后面同时打开Sysmac Studio和FANUC相关管理软件时会有一大堆设备发现不了的问题。这种低级坑往往最耗时间别问我怎么知道的。设备选型层面如果项目里的PLC是欧姆龙CP1H/CJ2M这类老型号EtherNet/IP端口不是标配需要额外加单元模块比如CJ1W-EIP21。NJ/NX系列省事内置即可。FANUC这边要特别注意EtherNet/IP功能需要软件选项出厂不一定会开通。订货时一定跟销售确认好否则到了现场才发现在线功能里根本没有EtherNet/IP这一项整个项目节奏都会被打乱。2. 通信前的软硬件准备与关键参数确认2.1 硬件清单与软件版本要求开工前把需要的东西列一个清单全部备齐再动手效率会高很多。这次用到的有欧姆龙NJ301-1200 PLC本体FANUC R-30iB Plus控制柜工业交换机一台非网管型即可网线若干根建议CAT5e以上带屏蔽的工业网线长度按现场距离预留调试电脑一台配RJ45网口软件欧姆龙Sysmac StudioFANUC相关调试软件但机器人侧很多操作在示教器上就能完成FANUC示教器关于软件版本有一点值得注意EtherNet/IP通信调试PLC侧和机器人侧的软件版本最好不要跨大版本太多。Sysmac Studio版本太低的话内置EtherNet/IP配置界面可能缺少某些字段比如连接模式选项里一些新特性不支持。FANUC那边则要确认控制器系统软件版本老版本在EtherNet/IP选项的稳定性和功能完整性上有差异。这属于平时感觉不到、出问题才后悔的一类事项目前期就把版本确认好能省掉后续很多莫名奇妙的坑。2.2 先把三张表理清楚再动手通信调试最大的感受是配置界面里的操作其实都还好真正要命的是一开始没有把规划做清楚。强烈建议在打开软件之前先把下面三张表填好。第一张是IP地址规划表。别觉得记在脑子里就行现场设备一多肯定乱。至少要记录设备名称、IP地址、子网掩码、默认网关、物理端口、备注。设备IP地址子网掩码默认网关备注欧姆龙NJ301192.168.1.10255.255.255.0无PLC内置EIP口FANUC R-30iB Plus192.168.1.20255.255.255.0无控制柜以太网口调试电脑192.168.1.100255.255.255.0无临时接线第二张是RPI和数据长度表。EtherNet/IP里RPI请求包间隔是PLC和机器人之间数据刷新的周期两边必须一致单位是毫秒。这次用的是10ms输入、10ms输出。数据长度方面机器人侧分配了输入64字节、输出64字节对应PLC输出到机器人64字节、PLC输入从机器人读64字节。不要一上来就搞一个超大的数据区够用就行数据区越大网络负载越高排查问题也越麻烦。第三张是数据映射表也就是PLC里的哪个变量对应机器人里的哪个寄存器或信号。这一步最容易被跳过但恰恰决定了后面联调是否顺利。这次的实际需求是PLC往机器人发16个字的命令数据启动、复位、速度倍率、工件号等机器人往PLC回16个字的状态数据远程模式、运行中、报警代码、当前工步等。映射表长这样数据方向PLC变量机器人侧说明PLC - 机器人cmdWord[0]R[100]命令字启动/停止PLC - 机器人cmdWord[1]R[101]速度倍率%PLC - 机器人cmdWord[2]R[102]工件号机器人 - PLCstsWord[0]R[200]状态字空闲/运行/报警机器人 - PLCstsWord[1]R[201]报警代码机器人 - PLCstsWord[2]R[202]当前工步号这里的关键是EtherNet/IP传输的是原始字节PLC和机器人之间的数据类型怎么解释完全靠两边约定。所以一开始就定义好WORD数组而且全部当作无符号整数来用不要一会儿int一会儿uint现场联调时最容易搞混的就是这个。3. 欧姆龙PLC侧配置从新建工程到建立连接3.1 在Sysmac Studio里启用EtherNet/IP主站功能这次用的PLC是NJ系列配套软件是Sysmac Studio具体步骤如下。打开Sysmac Studio新建工程把PLC型号选成NJ301-1200之后先在配置和设置里找到以太网相关选项。NJ的内置EtherNet/IP口默认是启用的但IP地址需要手动设置。在控制器设置下方的EtherNet/IP节点里先把端口的IP地址改成本地地址192.168.1.10子网掩码255.255.255.0。注意这里的设置和普通以太网设置的入口不同别在内置以太网里改完IP就以为完事了EtherNet/IP的端口配置是另一个界面。接下来要做的是创建连接。在EtherNet/IP配置界面里目标设备类型选择Scanner模式也就是主站负责发起通信。然后在连接列表里新建一条连接。这里要填写目标设备的IP地址机器人是192.168.1.20指定RPI。最初填的10ms如果PLC和机器人负载都正常这个值完全够用。还需要指定输入输出的大小输出PLC发给远程设备64字节输入从远程设备读回PLC64字节。然后就是选取EDS文件。ODVA官网或设备厂商一般会提供目标设备的EDS文件FANUC的EDS文件在机器人系统的某个目录下可以导出也可以找FANUC技术支持拿。Sysmac Studio支持从EDS文件直接导入设备信息这样就不用手动填设备的Vendor ID、设备类型、产品代码这些容易填错的信息。这次直接从FANUC那边拿到了EDS文件导入后目标设备名称出现在设备列表里省了不少事。如果没有EDS文件也可以手动填但那些ID码非常容易填错不推荐。一个值得做的操作在连接设置里把通信超时和连接重试之类的参数稍微调得宽松一点。默认值通常比较保守网络偶发抖动就可能触发连接断开联调阶段没有必要给自己增加这种干扰项。等正式稳定运行后再把这些参数收严到合理范围。3.2 将连接数据映射到PLC全局变量连接建好之后还有一个关键步骤把连接的输入输出数据映射到PLC侧的全局变量。在Sysmac Studio里每条连接会对应一组采集标签或通信地址需要把它们连接到实际的变量上。这次定义了两个WORD数组变量cmdWord长度为16用于PLC向机器人发送命令stsWord长度为16用于PLC从机器人读取状态映射关系就是在EtherNet/IP配置里把发送数据区对应到cmdWord把接收数据区对应到stsWord。这里特别提醒一句映射时注意数据类型的选择软件里可能会给字节数组和字数组两种解释方式一定要和机器人侧的数据长度单位一致。一开始就吃了这个亏机器人侧配置的输入长度是64字节在PLC侧映射时用了32个字的数组来对应乍一看数量对得上但实际联调时数据一直错位后来才发现长度的字节和字没有对齐。变量映射完成之后要把程序编译通过并下载到PLC。注意EtherNet/IP的配置修改之后必须对PLC进行一次在线同步下载并且要让PLC重新上电或复位一次连接配置才会真正生效。刚开始没经验改完配置直接点单调结果连接状态一直是正在建立浪费了不少时间。后来养成的习惯是每次改完连接配置先保存工程再在线同步同步完成后把PLC切换到PROGRAM模式再切回RUN让连接重新初始化。3.3 连接建立后的状态检查方法连接配置好后怎么看是否建立成功在Sysmac Studio里在线连接PLC后可以在EtherNet/IP配置界面里看到每条连接的状态常见状态有正在建立、已建立、超时等。测试时第一次能稳定看到已建立时心里就有底了说明PLC和机器人之间已经完成握手剩下的就是数据对不对的问题。另外在PLC程序里也可以读取系统的连接状态变量比如系统定义的EIP连接状态之类的变量把它写进触摸屏上方便现场操作和报警。这个属于加分项但对排障非常有价值以后出问题能在HMI上直接看到通信是断了还是正常就不必抱着电脑去现场抓数据了。实际做项目时这个状态变量几乎是必加的因为EtherNet/IP断链有时候是瞬时的现场人员如果没有直观指示根本发现不了。4. FANUC机器人侧配置从选项确认到I/O映射4.1 先确认EtherNet/IP选项和IP设置欧姆龙侧配置好了机器人这边如果没准备好连接照样建不起来。FANUC机器人的EtherNet/IP配置主要是在示教器上完成的前提是功能选项已经开通。怎么判断在示教器上按MENU进入设置或者I/O相关菜单看有没有EtherNet/IP这个入口。如果整个菜单里都没有说明选项没开通或者没生效需要联系厂家处理授权。确认选项存在后先设置控制柜的IP地址。FANUC的IP设置在示教器上可以通过MENU - 设置 - 以太网有的版本叫HOST COMM进入把机器人的IP设成192.168.1.20子网掩码255.255.255.0。这里注意FANUC控制柜有时候不止一个网口比如有用于视觉的专用口现场务必确认插的网口对应的是哪个IP配置界面别在A网口上配了B网口的IP。这种错位问题我见过不止一次现象就是怎么都ping不通最后发现IP配错了网口。4.2 将以太网节点配置为Adapter模式EtherNet/IP通信里这次选择让FANUC机器人作为Adapter从站由欧姆龙PLC作为主站主动和机器人建立连接机器人被动响应用户的数据交换请求。这种模式在实际产线中最常见因为机器人通常是被PLC调度的执行机构PLC掌握总线的控制权更合理。在示教器上进入EtherNet/IP配置界面后通常可以看到当前节点的运行模式设置把模式选为Adapter。然后需要配置输入输出数据的大小也就是前面提到的64字节输入、64字节输出。注意这里要和PLC侧保持一致。FANUC界面上一般显示的是输入大小和输出大小含义是以机器人为参照的机器人的输入来自PLC的数据和机器人的输出发往PLC的数据。当时的配置是输入64、输出64和PLC侧正好对应上。有些版本还需要配置设备名称、连接超时时间等参数这些一般用默认值即可不必刻意改小。连接超时时间尤其不要调得太短否则偶发网络抖动就会触发连接断开到时候排查起来非常痛苦。FANUC侧的超时如果设成100ms甚至更小可能稍微有点网络波动连接就断了重连反复折腾。4.3 把机器人的寄存器映射到EtherNet/IP数据区这是机器人侧最核心的一步。PLC和机器的数据链路已经建立但PLC发过来的64字节去了哪里机器人的状态数据从哪里取这些都需要在机器人EtherNet/IP配置界面中指定数据映射。在FANUC上最简单实用的方式是把EtherNet/IP的数据区直接映射到机器人内部的寄存器R[]和数字量信号DI/DO[]。R寄存器是16位的正好当WORD用与PLC侧的WORD数组天然对齐。这次使用的映射策略是从PLC收到的64字节按顺序映射到R[100]到R[131]共32个字发给PLC的64字节按顺序取自R[200]到R[231]共32个字这样约定之后PLC侧的cmdWord[0]对应机器人R[100]cmdWord[1]对应R[101]以此类推。两个方向各32个字用不满就留空以后扩展方便而且不会因为数据区规划太紧导致后面加需求时推倒重来。需要强调一个大家容易踩的坑在FANUC映射界面里输入和输出的数据长度单位不同系统版本可能显示为字节数也可能显示为字数一定要确认清楚。这次界面上显示的是64字节对应的R寄存器数量就是32个如果显示的是64字那R寄存器数量就是64个。单位搞错数据长度对不上连接虽然能建立但数据一定错位。这是半夜在车间对着手电筒才看明白的教训写出来希望你们不用再经历一次。5. 联机测试数据读写验证与踩坑实录5.1 首次连接状态检查两边配置完成后就可以开始联机测试了。顺序是这样的先给PLC和机器人上电确认它们各自能正常启动。然后用调试电脑分别ping一下两个地址确认它们在同一个二层网络里能互相访问。习惯是先ping通PLC再ping通机器人然后PLC侧ping机器人。如果PLC ping不通机器人那就先解决网络互通再谈通信协议不要急着去折腾配置。在Sysmac Studio里在线连接PLC查看EtherNet/IP连接状态。正常情况下连接会从正在建立变成已建立这个状态变化通常发生在几秒内。如果是连接超时或者建立失败先不要急着改参数按第6章的方法逐项排查。这里有一个观察细节首次连接建立时机器人示教器上一般也会有连接状态提示。如果两边都显示已连接就可以进行下一步的数据验证了。刚到这一步时还特意在示教器上看了一眼确认机器人的EtherNet/IP界面里显示Connected才放心往下做。5.2 数据方向与数值验证方法连接一通第一个要验证的就是数据方向是否正确。方法很简单在PLC侧通过Sysmac Studio的在线监视功能找到输出变量cmdWord[0]手动改成十六进制0x1234然后去机器人示教器上查看R[100]的值看看是不是0x1234。如果机器人R[100]读到了这个值说明PLC到机器人的数据链路是通的。同理在机器人示教器上把R[200]设成一个特征值比如0xAAAA回到PLC侧看stsWord[0]是否读到0xAAAA如果读到了说明机器人到PLC的数据链路也OK。双向通了这套通信就基本能用了。方向验证通过之后再测试数据的实时刷新。在PLC程序里写一段自增计数逻辑让cmdWord[0]每秒加一然后在机器人侧看R[100]的变化确认刷新周期是否稳定。反过来让机器人的R[200]每隔一定时间变化一次观察PLC侧的监视值。通过这种方式不仅能验证通信还能直观感受到RPI10ms带来的数据平滑度。在现场做这个测试时发现了一个很典型的问题方向验证时数据是对的但把程序跑起来后机器人侧的状态字时不时会出现旧值。排查下来其实是PLC程序里对stsWord的读取时机和机器人的写入时机存在微小的异步差这在EtherNet/IP这种周期刷新模式下很正常。解决办法也很简单在通信数据里加一个递增的序列号双方通过序列号判断数据是否为最新如果序列号不变就说明数据没有更新属于正常情况。这个序列号思路在工业通信里很常用简单粗暴但有效。5.3 联调中遇到的字节序和数据错位问题联调过程中最折磨人的问题是数据错位。第一次配置完后PLC侧写入0x1234机器人R[100]读到的却是0x3412——典型的字节序问题。EtherNet/IP协议本身以Little-Endian为主但FANUC机器人的一些数据寄存器在解释上可能和欧姆龙PLC存在差异。解决办法要看两边软件的设置欧姆龙侧在连接配置里通常有数据格式或字节顺序的选项FANUC侧也有类似的字节顺序设置把两边统一成同一种格式数据就恢复了正常。还有一种更隐蔽的错位输入输出长度单位不对导致的错位。这种情况连接是正常的甚至能看到数据在动但机器人侧的值和PLC侧的值就是驴唇不对马嘴。遇到这种问题先别急着怀疑协议老老实实把两边的数据长度单位、映射顺序从头到尾对一遍往往问题就出在最不起眼的字节和字上。联调验证时建议把每个通信数据的含义和单位都写到注释里给后期维护的同事省点力气。比如这个项目里安全回路生效时机器人会向PLC发送0x5A5A作为心跳信号这类细节如果不写清楚后面接手的人很可能一头雾水。6. 常见故障排查速查表与避坑心得6.1 八大高频通信故障及排查方向把这轮调试中遇到和听说过的典型问题整理成一张速查表方便在现场快速定位。故障现象可能原因排查方向连接一直正在建立两边IP不在同一网段用ping测试互通性连接建立后数据不刷新RPI不一致或数据长度单位不对核对两边的RPI和输入输出大小数据刷新有延迟或卡顿RPI设得过小网络拥塞适当增大RPI如10ms改20ms数据错位或字节序颠倒字节序设置不一致检查两端Little/Big Endian设置PLC写入值在机器人侧偶尔读到旧值周期性刷新的正常异步增加序列号字段判断数据新鲜度连接建立后不久自动断开超时时间太短或线路不稳定检查网线、交换机、超时设置Sysmac Studio下载后连接丢失忘记复位连接或PLC重新初始化下载完成后切PROGRAM再切RUN机器人菜单里找不到EtherNet/IP软件选项未开通联系厂家确认选项授权这张表不可能覆盖所有场景但大部分EtherNet/IP联调问题都能在这里找到方向。关键思路是先分层再排查。先确认物理层和数据链路层是通的ping通、状态灯正常再检查配置层IP、RPI、数据长度、字节序、映射不要跳层排查否则很容易在原地打转。6.2 这轮测试下来的一些经验心得最后分享几条个人比较深的心得都是实打实用时间换来的。第一EtherNet/IP的配置和验证过程一定要留文档。IP地址规划表、RPI和数据长度表、数据映射表这三张表在调试结束后要整理成正式的通信协议文档随设备资料一起存档。别嫌麻烦过半年保养期一到就知道这份文档有多值钱。很多现场的通信问题追根溯源都是当初的映射约定不清楚后来的人只能靠猜猜来猜去就把小问题猜成了大故障。第二通信数据的设计要预留扩展位。这次规划的16个字命令区实际只用到了3个字剩下的全部留空。后来项目加需求需要在PLC侧给机器人下发一个轨迹选择号直接启用了cmdWord[3]连程序都不用大改。通信协议这东西预留冗余永远比推倒重来便宜这是做自动化项目一条很朴素的真理。第三联调过程中尽量用最简单的命令先验证链路再逐渐增加复杂度。比如第一步只用固定值验证双向链路通不通第二步才用自增计数验证刷新周期最后再接入真实逻辑。很多人在连接刚建立时就急着把整个工艺逻辑跑起来一旦出问题根本分不清是通信的问题还是逻辑的问题。先把通信这一小层做干净后面的集成才会顺利这也是为什么我一直强调要把通信测试单独拎出来做成一个调试步骤。这篇文章写到这里基本把从方案选型到联调排障的全过程都梳理了一遍。EtherNet/IP本身不复杂复杂的是两边设备各自的操作习惯以及那些藏在细节里的字节序、单位、映射约定。希望这些经验能让你少走几次弯路。