企业官网建设流程全解析

最近刚折腾完一个现场改造：欧姆龙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和机器人通过工业交换机相连"，而不是直连网线。直连也能通，但产线上一般还有其他设备需要访问机器人（比如工程师的调试电脑），留个交换机接口会方便很多。

网络拓扑非常简单：

• 欧姆龙NJ301：192.168.1.10，子网掩码255.255.255.0
• FANUC R-30iB Plus：192.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 Studio，FANUC相关调试软件（但机器人侧很多操作在示教器上就能完成）
• FANUC示教器

关于软件版本，有一点值得注意：EtherNet/IP通信调试，PLC侧和机器人侧的软件版本最好不要跨大版本太多。Sysmac Studio版本太低的话，内置EtherNet/IP配置界面可能缺少某些字段，比如连接模式选项里一些新特性不支持。FANUC那边则要确认控制器系统软件版本，老版本在EtherNet/IP选项的稳定性和功能完整性上有差异。这属于"平时感觉不到、出问题才后悔"的一类事，项目前期就把版本确认好，能省掉后续很多莫名奇妙的坑。

2.2 先把三张表理清楚再动手

通信调试最大的感受是：配置界面里的操作其实都还好，真正要命的是一开始没有把规划做清楚。强烈建议在打开软件之前，先把下面三张表填好。

第一张是IP地址规划表。别觉得记在脑子里就行，现场设备一多肯定乱。至少要记录：设备名称、IP地址、子网掩码、默认网关、物理端口、备注。

第二张是RPI和数据长度表。EtherNet/IP里，RPI（请求包间隔）是PLC和机器人之间数据刷新的周期，两边必须一致，单位是毫秒。这次用的是10ms输入、10ms输出。数据长度方面，机器人侧分配了输入64字节、输出64字节，对应PLC输出到机器人64字节、PLC输入从机器人读64字节。不要一上来就搞一个超大的数据区，够用就行，数据区越大网络负载越高，排查问题也越麻烦。

第三张是数据映射表，也就是"PLC里的哪个变量对应机器人里的哪个寄存器或信号"。这一步最容易被跳过，但恰恰决定了后面联调是否顺利。这次的实际需求是：PLC往机器人发16个字的命令数据（启动、复位、速度倍率、工件号等），机器人往PLC回16个字的状态数据（远程模式、运行中、报警代码、当前工步等）。

映射表长这样：

这里的关键是：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字节，输入（从远程设备读回PLC）64字节。

然后就是选取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侧的监视值。通过这种方式，不仅能验证通信，还能直观感受到RPI=10ms带来的数据平滑度。

在现场做这个测试时，发现了一个很典型的问题：方向验证时数据是对的，但把程序跑起来后，机器人侧的状态字时不时会出现旧值。排查下来，其实是PLC程序里对stsWord的读取时机和机器人的写入时机存在微小的异步差，这在EtherNet/IP这种周期刷新模式下很正常。解决办法也很简单：在通信数据里加一个递增的序列号，双方通过序列号判断数据是否为最新，如果序列号不变，就说明数据没有更新，属于正常情况。这个"序列号"思路在工业通信里很常用，简单粗暴但有效。

5.3 联调中遇到的字节序和数据错位问题

联调过程中，最折磨人的问题是数据错位。第一次配置完后，PLC侧写入0x1234，机器人R[100]读到的却是0x3412——典型的字节序问题。EtherNet/IP协议本身以Little-Endian为主，但FANUC机器人的一些数据寄存器在解释上可能和欧姆龙PLC存在差异。解决办法要看两边软件的设置：欧姆龙侧在连接配置里通常有"数据格式"或"字节顺序"的选项，FANUC侧也有类似的字节顺序设置，把两边统一成同一种格式，数据就恢复了正常。

还有一种更隐蔽的错位：输入输出长度单位不对导致的错位。这种情况连接是正常的，甚至能看到数据在动，但机器人侧的值和PLC侧的值就是"驴唇不对马嘴"。遇到这种问题，先别急着怀疑协议，老老实实把两边的数据长度单位、映射顺序从头到尾对一遍，往往问题就出在最不起眼的"字节"和"字"上。

联调验证时建议把每个通信数据的含义和单位都写到注释里，给后期维护的同事省点力气。比如这个项目里，安全回路生效时机器人会向PLC发送0x5A5A作为心跳信号，这类细节如果不写清楚，后面接手的人很可能一头雾水。

6. 常见故障排查速查表与避坑心得

6.1 八大高频通信故障及排查方向

把这轮调试中遇到和听说过的典型问题整理成一张速查表，方便在现场快速定位。

这张表不可能覆盖所有场景，但大部分EtherNet/IP联调问题都能在这里找到方向。关键思路是：先分层，再排查。先确认物理层和数据链路层是通的（ping通、状态灯正常），再检查配置层（IP、RPI、数据长度、字节序、映射），不要跳层排查，否则很容易在原地打转。

6.2 这轮测试下来的一些经验心得

最后分享几条个人比较深的心得，都是实打实用时间换来的。

第一，EtherNet/IP的配置和验证过程一定要留文档。IP地址规划表、RPI和数据长度表、数据映射表，这三张表在调试结束后要整理成正式的通信协议文档，随设备资料一起存档。别嫌麻烦，过半年保养期一到，就知道这份文档有多值钱。很多现场的通信问题，追根溯源都是当初的映射约定不清楚，后来的人只能靠猜，猜来猜去就把小问题猜成了大故障。

第二，通信数据的设计要预留扩展位。这次规划的16个字命令区，实际只用到了3个字，剩下的全部留空。后来项目加需求，需要在PLC侧给机器人下发一个"轨迹选择号"，直接启用了cmdWord[3]，连程序都不用大改。通信协议这东西，预留冗余永远比推倒重来便宜，这是做自动化项目一条很朴素的真理。

第三，联调过程中尽量用最简单的命令先验证链路，再逐渐增加复杂度。比如第一步只用固定值验证双向链路通不通，第二步才用自增计数验证刷新周期，最后再接入真实逻辑。很多人在连接刚建立时就急着把整个工艺逻辑跑起来，一旦出问题，根本分不清是通信的问题还是逻辑的问题。先把通信这一小层做干净，后面的集成才会顺利，这也是为什么我一直强调要把通信测试单独拎出来做成一个调试步骤。

这篇文章写到这里，基本把从方案选型到联调排障的全过程都梳理了一遍。EtherNet/IP本身不复杂，复杂的是两边设备各自的操作习惯，以及那些藏在细节里的字节序、单位、映射约定。希望这些经验能让你少走几次弯路。