简介：OpENer 2.1.0 是面向 I/O 适配器设备的 EtherNet/IP 协议栈源码包，适合工业以太网嵌入式开发者、协议栈移植人员及相关专业学习者，用于实现支持多路 I/O 连接与显式连接的 ODVA 兼容设备，并覆盖 CIP 对象与服务的基础实现。压缩包共 180 个文件、约 560KB，以 C 源码和头文件为主体，配合 C++ 代码、CMake 构建脚本、Shell/BAT 配置脚本及说明文档，整体可按协议模块、平台适配和示例配置分层查阅。已有 1065 人学习或下载。读者可据此研究 EtherNet/IP 封装、连接管理与对象模型，借助 POSIX/BSD socket 版本搭建实验环境，并参考构建脚本和说明完成裁剪、编译与联调，积累工业协议开发与排错经验。
1. 从一台扫描不上号的从站说起
做工业协议对接的开发者大多遇到过一个场面：硬件板子焊好了，指示灯也亮了，把它接到交换机和上位控制器上，扫描列表里却怎么也看不到这台设备。我们当时那台自研 IO 模块就卡在这一步。写了一半的 EtherNet/IP 从站代码能回一个 ListIdentity，但 RegisterSession 之后的显式连接、隐式 IO 连接全没打通。后来用 OpENer 这套 C 语言写的 EtherNet/IP 适配器协议栈重做了一遍，才算真正把设备送进了扫描列表。
OpENer 是一套面向 IO 适配器（Adapter）侧的 EtherNet/IP 协议栈实现，用 C 写成，包含 CIP 的对象模型、消息路由、连接管理，以及封装层从 ListIdentity 到 SendUnitData 的全部命令处理。它的适用人群很明确：手上有一台自研设备，需要让它以标准从站身份接入 EtherNet/IP 网络，又不想自己从零啃规范的那批人。做过两轮 EtherNet/IP 对接的开发者看这套分层代码，基本能在一周内让设备跑起来。
2. 分层架构与目录结构：一个 CIP 报文要穿过哪几层
EtherNet/IP 是 CIP 在以太网上的封装，这个协议栈同时要处理 TCP 上的显式消息和 UDP 上的隐式 IO 数据，因此分层设计至关重要。OpENer 的分层可以直接对应到源码目录，只要理解“哪一层负责什么”，后续改代码时才知道改动该落在哪个文件。
2.1 四层结构：从网卡到业务对象
从一根网线插上到业务变量被改写，一个报文大概要过四道关：
- 移植层：负责收发原始报文、提供毫秒级时间戳、跑主循环。这一层是平台相关的，Linux、Windows、RTOS 各有一份实现。
- 封装层：处理 EtherNet/IP 那 24 字节固定头，识别命令码，管理会话号（Session Handle），解析 CPF（Common Packet Format）里的地址段和数据段。
- CIP 层：这里才是协议的核心，包含连接管理器、消息路由、类/实例/属性三级对象模型，以及 Identity、Assembly、TCP/IP Interface 等标准对象。
- 应用层：用户自己的代码，负责把 Assembly 实例里的字节和真实的 IO 硬件、业务变量对应起来。
对照源码目录看会更清楚：
| 目录 | 所属层 | 主要职责 |
|---|---|---|
source/src/ports/posix | 移植层 | socket 收发、定时器、main入口 |
source/src/ports/win32 | 移植层 | Windows 下的等价实现 |
source/src/enet_encap | 封装层 | 24 字节头解析、命令分发、会话表 |
source/src/cip | CIP 层 | 连接管理、消息路由、对象与属性 |
source/src/utils | 工具层 | 字节序转换、错误码、链表操作 |
这种分法有一个实际好处：换平台时只动ports目录，协议逻辑一行不改；添加自定义对象时只动cip和用户配置，封装层不碰。我一般会把这四个目录当成四条边界，任何一次改动先问自己“这属于哪一层”，能省掉很多把驱动代码写进协议栈里的麻烦。
2.2 对象模型：CIP 是按“类-实例-属性”寻址的
CIP 最反直觉的地方在于它不是一个“命令 + 参数”的协议，而是面向对象的。所有可访问的数据都挂在某个类（Class）下，类下面有若干实例（Instance），实例下面有若干属性（Attribute）。上位机发过来的请求，本质是一段 E 路径（EPATH），描述“我要访问哪个类的哪个实例的哪个属性”。
一段典型的 E 路径字节是20 04 24 64 30 03，拆开看：
20 04：逻辑段，类，类码0x04（Assembly 对象）24 64：逻辑段，实例，实例号0x6430 03：逻辑段，属性，属性号0x03
所以“读 Assembly 实例 100 的属性 3”这句话，在网络层就是一串固定格式的字节。协议栈要做的事只有一件：把这串字节还原成三个数字，然后在自己的类链表里逐级查下去。
类在内存里就是一条链表，注册一个类大致是这个形状：
/* 注册一个自定义类：类码 0x64，含 3 个实例，实例数据按 8 字节算 */ CipClass *CreateDemoObjectClass(void) { CipClass *demo_class = CreateCipClass((CipUint32)kDemoClassCode, /* 类码，0x64 */ 0, /* 类属性个数，本例没有 */ 0, /* 类属性占用的字节数 */ 7, /* 最高属性编号，属性号可不连续 */ kUint8, /* 属性的默认数据格式 */ "Demo Object", /* 类名，仅调试时看 */ 1, /* revision，上位机可能校验 */ 3, /* 实例数量 */ 3); /* 最大实例号 */ if (demo_class == NULL) { return NULL; /* 内存不够或者类码冲突，这里一定要判空 */ } /* 一次性把 3 个实例建出来，实例号从 1 开始连续分配 */ AddCipInstances(demo_class, 3); /* 挂进全局类链表，之后 E 路径才能查到它 */ InsertCipClass(&g_class_list, demo_class); return demo_class; }参数里最容易搞错的是“最高属性编号”和“实例数量”。前者决定属性数组开多大，后者决定实例数组开多大，两个值都写小了，运行时会出现很隐蔽的越界写。revision也不能随便填，一致性测试里有对它的校验项。
提示：
class_id的取值要避开0x01（Identity）、0x02（Message Router）、0x04（Assembly）、0x06（Connection Manager）、0xF5（TCP/IP Interface）、0xF6（Ethernet Link）这些标准类码，自定义对象一般从厂商私有段里选。
2.3 标准对象：哪些已经现成，哪些要自己补
适配器侧要过一致性测试，光有 Assembly 远远不够。OpENer 已经把几个必需的标准对象实现了：
- Identity（0x01）：设备身份，包含厂商 ID、设备类型、产品码、序列号、设备名。上位机扫描时读的就是它。
- Message Router（0x02）：显式消息的入口，负责把请求转给目标对象。它本身没有业务数据，是个纯路由。
- Assembly（0x04）：IO 数据的容器，输入和输出各占一个实例。
- Connection Manager（0x06）：处理 ForwardOpen / ForwardClose，是隐式连接建立和拆除的中枢。
- TCP/IP Interface（0xF5）：网络配置，IP、掩码、网关、DNS 都挂在这。
- Ethernet Link（0xF6）：链路层信息，速率、双工、MAC 地址。
设备身份那一组常量在用户配置文件里，改设备名、厂商 ID 就是改这几个宏：
/* 设备身份参数，扫描列表和抓包里都会原样看到 */ #define OPENER_DEVICE_NAME "Demo EIP Adapter" #define OPENER_DEVICE_VENDOR "Demo Vendor" #define OPENER_DEVICE_VENDOR_ID 0x0001 /* 厂商号，自己做设备就随便选一个私有段 */ #define OPENER_DEVICE_TYPE 0x0C /* 12 = 通信适配器 */ #define OPENER_DEVICE_PRODUCT_CODE 0x0001 #define OPENER_DEVICE_REVISION 0x0001 #define OPENER_DEVICE_PRODUCT_NAME "Demo Adapter 16DI"这几个宏看着不起眼，但上位机侧做设备识别、GSD 类文件匹配时经常依赖它们。改产品型号的时候如果只改了硬件丝印没改这里，现场就会出现“扫描到两台同名设备”的尴尬。
3. 编译与跑通：先在 x86 上把从站跑起来
协议栈这种东西，直接在目标板上调试是很痛苦的：没有终端输出、抓包还得靠镜像口。比较省事的路径是先在 x86 Linux 上用 POSIX 移植层把整个流程跑通，确认显式消息、隐式连接都正常，再把移植层换掉交叉编译过去。
3.1 依赖与 CMake 构建
工程用 CMake 组织，依赖很轻，一个 C 编译器加标准库就够。POSIX 移植层还需要 pthread，因为接收线程和主循环是分开跑的。
cd opener/source # 单独建目录，别在源码树里就地编译 mkdir -p build && cd build # Debug 版会打开协议栈内部的断言和日志，调协议阶段一定要用它 cmake -DCMAKE_BUILD_TYPE=Debug .. # 多核并行，编译产物在 build 目录下 make -j"$(nproc)"编译完之后目录里会有一个可执行文件，这就是带 POSIX 移植层的示例从站。第一次编译常见的问题是找不到pthread，这时候检查一下CMakeLists.txt里有没有链接Threads::Threads；另一个常见问题是编译器版本偏老，协议栈里用了 C99 的指定初始化器，把-std=gnu99加上基本就过了。
3.2 启动参数与网卡绑定
从站要监听 UDP 44818（显式消息和广播发现）和 TCP 44818（会话），隐式 IO 数据走的是 UDP 2222 端口。启动时指定网卡这一步很关键，指定错了会出现“本机抓包能看到请求，设备就是不回应”的现象。
# 网卡名按实际填，eno1 / eth0 / enp3s0 都有可能 sudo ./opener -n eno1 # 也可以显式绑定 IP，多网卡机器上更保险 sudo ./opener -n eno1 -i 192.168.1.10启动参数在不同分支上可能略有差异，用-h看一眼最稳妥。跑起来之后控制台会打一行监听信息，看到这行基本说明绑定成功了。
非 root 环境下可以给可执行文件加网络能力，省掉每次sudo：
# 只授予必要的两个能力，比直接 chmod 4755 安全 sudo setcap cap_net_raw,cap_net_admin+eip ./opener注意：加了 cap 之后如果重新编译，二进制被覆盖，能力会丢失，需要重新执行一次
setcap。这个坑我踩过不止一次。
3.3 用一小段脚本确认从站真的活着
设备管理器扫描不到的时候，先别急着怀疑协议栈，用十几行 Python 直接发一个 ListIdentity 广播，能快速把问题定位在“协议栈没起来”还是“上位机配置不对”上。
import socket import struct # EtherNet/IP 封装头固定 24 字节：命令码、长度、会话号、状态、发送方上下文、选项 # 除个别字段外都是小端 header = struct.pack( '<HHII8sI', 0x0063, # ListIdentity 命令码 0, # 数据长度，ListIdentity 无附加数据 0, # 会话号，发现阶段还没有会话 0, # 状态码 b'\x00' * 8, # 发送方上下文，原样回传即可 0 # 选项字段，保留 ) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(2.0) sock.sendto(header, ('192.168.1.10', 44818)) try: data, addr = sock.recvfrom(1024) print('回包长度', len(data), '来自', addr) # 回包里带厂商 ID、设备类型、产品码、设备名，按需再解 except socket.timeout: print('两秒无回包，检查网卡绑定和防火墙')如果这段脚本能收到回包，说明封装层、Identity 对象、UDP 收发的链路都是通的，上位机那边扫不到大概率是网络分段或者 EDS 文件的问题。如果收不到，就抓包看请求到底有没有到达网卡。
3.4 交叉编译到目标板
x86 上跑通之后，把移植层换成目标平台的那份实现。OpENer 的移植接口设计得比较薄，需要实现的通常是这几件事：初始化网络、发送报文、接收报文、取毫秒时间戳、主循环里的周期任务。
工具链文件大概写成这样：
# toolchain-arm.cmake set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)# 用独立的构建目录，避免和本地 x86 产物混在一起 cmake -DCMAKE_TOOLCHAIN_FILE=toolchain-arm.cmake -B build-arm -S . cmake --build build-arm -j"$(nproc)"交叉编译之后第一件事不是接控制器，而是把目标板接到一台 PC 上，用 3.3 那段脚本再发一次 ListIdentity。很多“交叉编译能过、跑起来没反应”的问题，根子在目标平台的网卡收包方式，比如有些 RTOS 的驱动只支持轮询、没有中断回调，接收线程的节奏就完全变了。
4. 核心模块拆解：会话、连接与 IO 数据链路
跑到这一步，协议栈是能回包了，但要让它真正承载 IO 数据，得把封装层、消息路由、连接管理这三块啃下来。这三块加起来差不多是整个协议栈的主要难点，也是二次开发时改得最多的地方。
4.1 封装层：24 字节头之后的分岔路
所有 EtherNet/IP 报文开头都是 24 个字节的封装头，里面最重要的是命令码。命令码决定了后续怎么处理，也决定了这个报文走 TCP 还是 UDP。
/* 封装层的命令分发骨架，取自 enet_encap 里的处理入口 */ void HandleEncapsulationCommand(const uint8_t *const command, size_t command_length) { const EncapHeader *header = (const EncapHeader *)command; /* 前 24 字节固定头 */ switch (header->command_code) { case kEncapsulationCommandListServices: /* 0x0004，列出支持的服务 */ HandleListServicesCommand(command, command_length); break; case kEncapsulationCommandListIdentity: /* 0x0063，广播发现走这里 */ HandleListIdentityCommand(command, command_length); break; case kEncapsulationCommandRegisterSession: /* 0x0065，分配会话号 */ HandleRegisterSessionCommand(command, command_length); break; case kEncapsulationCommandSendRRData: /* 0x006F，显式消息 */ HandleSendRRDataCommand(command, command_length); break; case kEncapsulationCommandSendUnitData: /* 0x0070，隐式 IO 数据 */ HandleSendUnitDataCommand(command, command_length); break; default: /* 没实现的命令必须回错误码，静默丢弃会让上位机一直重试 */ SendEncapsulationError(header->sender_context, kEncapsulationCommandNotSupported); break; } }command_length这个参数不能省。封装头里的长度字段是网络上报上来的，直接拿去当缓冲区长度用就是一个典型的越界入口。我一般会在分发之前先校验一遍“长度字段 + 24 是否等于实际收到的字节数”，对不上直接丢包。
命令码之后是 CPF 数据，格式是“项目数 + 若干项目”，每个项目由类型 ID 和数据组成。类型0x00A1是连接的地址信息（含连接 ID），0x00B2是未连接的消息数据（含 E 路径和服务数据）。解析 CPF 是显式消息和隐式消息共用的第一步，也是很多自研实现最先出错的地方：项目数算错一次，后面的偏移全歪。
4.2 显式消息：E 路径解析与消息路由
显式消息承载的是“配置类”的读写请求，比如读设备序列号、写 IP 地址、读 Assembly 的当前值。它走 TCP，有请求有应答，可靠性由 TCP 保证。
处理链路是这样的：SendRRData 进来 → 解析 CPF 拿到未连接消息 → 剥离 E 路径 → 取出服务码和请求数据 → 按类/实例/属性三级查到目标 → 调用对应的服务处理函数。
/* 消息路由的核心：把一段 E 路径还原成 类 -> 实例 -> 属性 三级指针 */ EipStatus RouteCipMessage(const CipMessage *message, CipMessageReply *reply) { /* 第一级：按类码在全局类链表里找，比如 0x04 = Assembly */ CipClass *class = GetCipClass(GetClassCode(message)); if (class == NULL) { return kEipStatusError; /* 类不存在，回 kCipErrorServiceNotSupported 更准确 */ } /* 第二级：在该类的实例数组里按实例号找，比如 0x64 = 100 */ CipInstance *instance = GetCipInstance(class, GetInstanceNumber(message)); if (instance == NULL) { return kEipStatusError; /* 实例越界，常见于 EDS 文件写错实例号 */ } /* 第三级：属性段是可选的，只有 Get/Set Attribute Single 这类服务才带 */ CipAttribute *attribute = NULL; if (HasAttributeSegment(message)) { attribute = GetCipAttribute(instance, GetAttributeNumber(message)); if (attribute == NULL) { return kEipStatusError; } } /* 真正的服务执行，按服务码分发到 Get/Set/Reset 等处理函数 */ return ExecuteService(message->service_code, instance, attribute, reply); }这段代码看着简单，但有两个地方值得多说两句。一是GetInstanceNumber返回的是原始字节数，实例号超过 255 的时候 E 路径会用两个字节表示（25 xx xx），如果解析时固定按一字节读，实例号 300 就会被读成 44，然后报“实例不存在”。二是属性的读写权限要在ExecuteService里校验，GetAttributeSingle打到只写属性上要返回0x03（权限不足），不能直接返回数据。
4.3 隐式消息：连接管理与 IO 数据周期
IO 数据不走显式消息，而是另外建立一条隐式连接。建立过程是上位机发一个 ForwardOpen 到 Connection Manager，请求里带着请求包间隔（RPI）、数据长度、连接方向这些参数。协议栈同意之后返回两组连接 ID，之后双方就按 RPI 周期性地用 SendUnitData 互发数据。
ForwardOpen 里几个参数直接决定后续行为：
| 参数 | 含义 | 填错的后果 |
|---|---|---|
| RPI | 请求包间隔，微秒 | 太短会占满 CPU，太长上位机会判定超时 |
| T→O 长度 | 控制器到适配器的数据字节数 | 与适配器侧 Assembly 大小不一致会直接拒绝连接 |
| O→T 长度 | 适配器到控制器的数据字节数 | 同上 |
| 连接类型 | 纯数据 / 带心跳 | 选错后连接建立成功但收不到数据 |
连接建立之后，适配器侧要做的就是在主循环里按 RPI 把输入数据发出去：
/* 主循环里的生产逻辑：按 O->T 的 RPI 到期就把输入 Assembly 发出去 */ void HandleProducedData(void) { uint32_t now = GetMilliSeconds(); /* 没有活动连接时直接返回，别在主循环里空转 */ if (!g_connection.is_active) { return; } if ((now - g_last_produce_time) >= g_connection.rpi_out_ms) { g_last_produce_time = now; /* 发送前把业务侧最新的输入数据刷新到发送缓冲区 */ RefreshInputAssembly(); SendUnitData(g_connection.o_to_t_connection_id, g_input_assembly_data, g_connection.o_to_t_size); /* 长度必须和 ForwardOpen 里约定的一致 */ } }这里的rpi_out_ms是微秒换算成毫秒之后的整数。如果 RPI 是 10000 微秒（10 毫秒），主循环的调度粒度必须细于 10 毫秒，否则实际发送间隔会抖动得厉害。POSIX 移植层用select加超时来做这个调度，超时值一般设成“最近一个到期时间的差值”，而不是固定睡 1 毫秒。
4.4 消费侧：把收到的字节变成硬件动作
收到控制器发来的输出数据之后，不能直接拿指针去读，因为报文缓冲区在处理完就会被复用。正确做法是先拷贝到自己的缓冲区，再做字节序转换和长度校验。
/* 消费：控制器发来的输出数据落到业务变量，再驱动硬件 */ void ConsumeOutputData(const uint8_t *buffer, size_t length) { /* ForwardOpen 约定的长度和实际收到的长度必须一致，不一致直接丢 */ if (length < sizeof(g_outputs)) { return; } /* 先拷出来，报文缓冲区随后就会被下一次接收覆盖 */ memcpy(&g_outputs, buffer, sizeof(g_outputs)); /* CIP 的部分数据字段是大端，具体看属性定义，别一刀切 */ g_outputs.channel_mask = Swap16IfNeeded(g_outputs.channel_mask); /* 真正操作硬件的地方，注意别在这里做长耗时动作 */ ApplyToHardware(&g_outputs); }ApplyToHardware里千万不要做阻塞操作。曾经有一版代码在里面加了 20 毫秒的 I2C 等待，结果整个主循环被拖慢，控制器侧判定连接超时，反复断开重连，日志里全是 ForwardClose。
5. 避坑清单：从抓不到包到连接建好就断
协议栈跑通只是第一步，现场对接时遇到的问题往往不在协议栈本身，而在配置、时序和字节序这些细节上。下面这几条是我在实际项目里撞过、并且有明确现象和解决路径的。
5.1 扫描列表里始终没有设备
现象：Python 脚本能收到 ListIdentity 回包，但上位机的设备扫描界面一片空白。
原因：ListIdentity 是 UDP 广播，多网卡机器上广播包从哪张网卡出去由路由表决定。如果协议栈绑在eno1，而系统默认路由走的是另一张网卡，广播包就从错误的网卡发出去了。
解决：先ip route get 255.255.255.255确认广播走哪张网卡，把协议栈绑到同一张卡上；或者临时把无关网卡 down 掉再扫一次。另外检查本机防火墙，UDP 44818 被拦的情况比想象中常见。
5.2 RegisterSession 成功，紧接着连接就断
现象：抓包里能看到 RegisterSession 请求和成功应答，但上位机很快就发 ForwardClose，或者干脆重连。
原因：会话建立之后，上位机会周期性发一些查询（比如读 TCP/IP Interface 对象的状态），如果这些请求超时或者回了错误码，上位机会认为设备异常。最常见的是 TCP/IP Interface 对象里的“当前配置能力”字段和实际网络配置对不上。
解决：把会话建立之后的头几个请求全抓下来，逐个看应答码。0x08（服务不支持）通常意味着某个标准对象没注册，0x05（路径解析失败）通常是 E 路径里的类码或实例号写错。
5.3 连接建好了，IO 数据全是 0
现象：ForwardOpen 返回成功，抓包里也能看到周期性的 SendUnitData，但控制器侧读到的输入数据恒为 0。
原因：Assembly 实例里挂的是默认数据，生产回调没被调用，或者回调写了但写到了另一块缓冲区。OpENer 的 Assembly 对象把数据和属性绑定，实例数据需要显式关联到属性上。
解决：在生产和消费回调里各加一行日志，确认回调真的被调用了。如果日志没打，检查 Assembly 实例属性有没有正确关联；如果日志打了但数据还是 0，检查发送用的长度是不是和 ForwardOpen 约定的长度一致——长度大于实际填充的字节数时，尾部全是 0。
5.4 数据看着像，但数值差了 256 倍
现象：控制器收到的输入值本该是 100，显示出来是 25600。
原因：字节序。CIP 的大部分报文头字段是小端，但 IO 数据里多字节字段的字节序由属性定义决定，有些是大端。自研实现里经常统一按小端处理，就会出现整字节错位。
解决：不要自己写转换，用协议栈提供的字节序工具函数，并且确认属性定义里的数据格式。验证方法是发一个已知值（比如0x0102），抓包看线上字节是01 02还是02 01，一眼就能确认。
5.5 交叉编译后运行就崩，x86 上一切正常
现象：同样的代码在 x86 上跑得好好的，交叉编译到 ARM 之后启动就段错误，或者解析出来的类码完全不对。
原因：结构体对齐。封装头、CPF 项目这类结构是直接按内存布局映射的，如果编译器加了填充字节，字段偏移就全错了。ARM 上默认对齐策略和 x86 不同，问题就暴露出来了。
解决：给所有网络报文相关的结构体加紧凑对齐（__attribute__((packed))或者#pragma pack(1)），并在编译期加一条静态断言检查sizeof(EncapHeader) == 24。这个断言花不了五分钟，能省掉一整天的排查。
注意：加了 packed 之后，访问结构体成员可能会在某些架构上产生非对齐访问异常，读取时先拷到本地变量再用，别直接取地址。
6. 二次开发：加一个自己的 Assembly 与自定义对象
协议栈跑通之后，真正的活是把业务数据接进去。最常见的两类改造：一是改 Assembly 的大小和映射，二是加一个厂商自定义对象给上位机做参数配置。
6.1 改 Assembly 的实例号与数据长度
Assembly 是 IO 数据的容器，输入输出各一个实例。默认实例号常见是0x64（输入）和0x65（输出），长度按实际 IO 点数算。改的时候有三个地方必须同步：Assembly 实例的属性大小、ForwardOpen 里约定的长度、上位机侧的 EDS 文件。三处少改一处，连接能建起来但数据会错位。
/* 按实际 IO 点数重新计算 Assembly 长度 */ #define DEMO_INPUT_ASSEMBLY_SIZE 8 /* 16 路 DI + 状态字，8 字节 */ #define DEMO_OUTPUT_ASSEMBLY_SIZE 4 /* 16 路 DO，4 字节 */ /* 建 Assembly 实例时把长度传进去，属性大小由它决定 */ CipInstance *input_instance = AddCipInstance(g_assembly_class, 0x64); AddCipAttribute(input_instance, 3, DEMO_INPUT_ASSEMBLY_SIZE, kByteArray);属性号3是 Assembly 的数据属性，这个编号是规范固定的，别改。
6.2 自定义对象：给上位机开一个参数配置入口
设备上有些参数不适合走 IO 数据，比如滤波时间常数、通道使能位。这类参数做成自定义对象更合适，上位机可以用显式消息读写，不影响 IO 周期。
实现路径是三步：定义类并注册、给实例挂属性、在服务处理里拦截 Get/Set。第三步最关键，默认的 Get/Set 只是读写内存，业务逻辑（比如“改了滤波参数要立刻生效”）得自己挂回调。
/* 自定义属性的写回调：值落盘之后立刻刷新到硬件 */ EipStatus OnFilterTimeWrite(CipInstance *instance, CipAttribute *attribute, const void *data, size_t data_length) { if (data_length != sizeof(uint16_t)) { return kEipStatusError; /* 长度不对，回错误码，别硬写 */ } uint16_t new_value = *(const uint16_t *)data; if (new_value > 1000) { return kEipStatusError; /* 参数越界，回 0x09 更规范 */ } g_filter_time_ms = new_value; ApplyFilterTime(g_filter_time_ms); /* 立刻生效，别等到下一个周期 */ return kEipStatusOk; }6.3 验证方法：先用显式消息把对象读写一遍
改完之后不要直接上控制器。先写个小脚本，用显式消息读写一遍自定义对象，确认 E 路径能解析、属性读写权限正确、回调被调用。这一步能挡掉大部分路径和权限问题，比在控制器上反复试快得多。
我习惯的顺序是：ListIdentity 确认设备在 → RegisterSession 拿会话号 → 用 GetAttributeSingle 读一次 Identity 的序列号 → 读一次自定义对象 → 写一次自定义对象再读回来比对。五步走完，协议栈的显式消息链路就基本没问题了，剩下的才是 IO 连接的时序调优。
从那以后我每次改 Assembly 长度，都会先跑一遍这五步再动控制器，因为一旦长度不一致，控制器侧的表现是“连上了但数据不对”，从现象倒推原因特别费时间。希望这些能帮你少走点弯路。
本文还有配套的精品资源，点击获取
