2. EtherNet/IP协议基础与ControlLogix通信

EtherNet/IP 并不是“把以太网线插上就能通”的简单协议，它是在标准 TCP/IP 之上承载 CIP（Common Industrial Protocol，通用工业协议）的一整套工业通信体系。理解 ControlLogix 的通信行为，关键要抓住四件事：CIP 的对象模型决定了“数据以什么身份存在”，显式消息决定了“如何按需读写”，隐式 I/O 决定了“如何周期性交换”，生产者/消费者模型决定了“数据由谁产生、被谁同时消费”。这四者不是并列概念，而是层层支撑的关系。

CIP对象模型：数据不是地址，而是对象属性

在传统 PLC 通信里，我们习惯用“地址”定位数据，例如 N7:0、D100。CIP 改变了这种思维：所有可访问的数据都被组织成对象（Object），每个对象有类（Class）、实例（Instance）、属性（Attribute）三级寻址。类描述“这是什么类型”，实例描述“是哪一个”，属性描述“取它的哪个字段”。

ControlLogix 中最常打交道的几个对象包括：Identity 对象（0x01）用于标识设备身份，如厂商 ID、设备类型、产品代码、序列号和设备名称；Message Router 对象（0x02）负责把请求路由到目标对象；Assembly 对象（0x04）是隐式 I/O 数据的容器，输入装配与输出装配分别承载设备与控制器之间周期交换的数据；Connection Manager 对象（0x06）管理连接建立与断开；TCP/IP 接口对象（0xF5）和 Ethernet Link 对象（0xF6）描述网络接口状态。此外，用户自定义的 Logix 标签通过符号段（Symbolic Segment）访问，本质上是把标签名映射到控制器内部对象。

对象模型的实践意义在于：当你用 RSLinx 或 FactoryTalk Linx 浏览一台设备时，看到的不是一堆寄存器，而是一棵对象树；当你用 MSG 指令读取数据时，需要指定的是“类 + 实例 + 属性”，而不是一个裸地址。例如读取某台 PowerFlex 变频器的输出频率，实际访问的是该设备内部某个对象的特定属性，而不是“第几个字”。

显式消息：按需、可靠、可路由

显式消息是“我问你答”的通信方式。控制器发出一个请求，目标设备处理后返回响应，整个过程基于 TCP，因此可靠、有序、可确认。在 ControlLogix 中，最典型的实现是 MSG 指令。配置一条 MSG 时，需要明确几个关键参数：通信路径（Path）描述从控制器到目标设备的网络路由，例如 1, 2, 192.168.1.10 表示从背板第 1 槽的以太网模块出发，经 IP 192.168.1.10 到达设备；消息类型选择 CIP Data Table Read/Write 或 CIP Generic；对于 CIP Generic，还要指定服务码（Service Code）、类、实例、属性以及数据长度。

举例来说，读取一台 EtherNet/IP 从站的 Identity 对象序列号，服务码为 0x0E（Get Attribute Single），类 0x01，实例 1，属性 7。返回的数据按小端序解析为 32 位无符号整数。这类操作适合在程序初始化阶段执行一次，或由 HMI 按钮触发，而不适合放在高速扫描任务中反复执行。

显式消息的优点是灵活、可跨网段、可访问任意对象属性；缺点是延迟不确定、吞吐量有限、占用控制器通信资源。因此它适合配置、诊断、非实时参数读写，不适合替代 I/O 刷新。

隐式 I/O：周期性、确定性、面向连接

隐式 I/O 是 ControlLogix 与远程 I/O、变频器、伺服驱动器之间交换实时数据的主要方式。它基于 UDP，采用生产者/消费者模型，通信双方在建立连接时协商好数据格式、长度和刷新周期。这个刷新周期就是 RPI（Requested Packet Interval），例如 10 ms、20 ms、50 ms。RPI 越小，数据刷新越快，但网络和控制器负载越高。

在 Studio 5000 中添加一个 EtherNet/IP 模块时，你会看到输入装配（Input Assembly）和输出装配（Output Assembly）的实例号与数据长度。例如某台远程 I/O 适配器，输入装配实例 100，长度 32 字节；输出装配实例 101，长度 16 字节。控制器按照 RPI 周期性地把输出数据发送到适配器，同时接收输入数据并映射到控制器标签中。整个过程不需要用户编写 MSG 指令，连接建立后由通信硬件和固件自动完成。

隐式 I/O 的关键判断依据是：数据是否要求周期性、确定性刷新；是否对延迟敏感；是否属于设备控制回路的一部分。如果是，就应使用隐式 I/O；如果只是偶尔读取一个参数，则用显式消息更合适。

生产者/消费者模型：一次生产，多方消费

传统源/目的通信中，一个数据源要向多个接收方发送，就需要建立多条独立连接，数据被复制多份。生产者/消费者模型改变了这一点：数据生产者把数据打上连接 ID（Connection ID），以多播方式发送到网络；任何对该数据感兴趣的消费者只需加入同一个多播组，即可同时接收同一份数据。生产者不需要知道有多少消费者，也不需要为每个消费者单独发送。

在 EtherNet/IP 中，隐式 I/O 正是基于这一模型。控制器作为输出数据的生产者，远程 I/O 适配器作为消费者；同时适配器作为输入数据的生产者，控制器作为消费者。多个控制器可以同时消费同一台设备的数据，例如两台控制器同时监听同一台变频器的状态字，而变频器只需生产一次。这显著降低了网络带宽占用和设备处理负担。

需要特别注意的是，生产者/消费者模型依赖多播和连接管理。交换机必须正确支持 IGMP Snooping，否则多播帧会在网络中泛洪，影响其他设备。此外，连接超时（Connection Timeout）和看门狗机制决定了消费者如何判断生产者是否离线。在 ControlLogix 中，可以通过模块属性查看连接状态、RPI 实际值和超时计数，这些是排障时的重要观察点。

四者关系与典型配置参数

把四者串起来看：CIP 对象模型是数据组织方式；显式消息是访问对象属性的“按需通道”；隐式 I/O 是周期性交换装配数据的“实时通道”；生产者/消费者模型是隐式 I/O 的底层传输机制。ControlLogix 的通信配置，本质上就是在对象模型中定位数据，然后选择用显式还是隐式方式访问它。

在 Studio 5000 中实际配置一个 EtherNet/IP 设备时，典型参数包括：IP 地址、槽号或连接路径、输入/输出 Assembly 实例号、数据长度、RPI、连接超时倍率、是否使用多播。以一台远程 I/O 适配器为例，假设输入装配实例 100、长度 32 字节，输出装配实例 101、长度 16 字节，RPI 设为 20 ms，连接超时倍率 4，则实际超时时间为 80 ms。如果 80 ms 内未收到生产者数据，控制器会判定连接超时，模块进入故障状态，输入数据可能被清零或保持最后值，具体取决于模块配置。

理解这些参数之后，再看 ControlLogix 的通信故障排查就有了方向：连接建立失败，先查路径和 IP；连接频繁超时，先查 RPI 是否过小、网络是否拥塞、交换机是否支持多播；显式消息报错，先查服务码、类、实例、属性是否正确，以及目标设备是否支持该对象。把对象模型、显式消息、隐式 I/O 和生产者/消费者模型放在一起理解，才能真正看懂 ControlLogix 的通信行为。