引言：一个 4 字节引发的连接失败
在工业现场进行 EtherNet/IP（EIP）协议对接时，研发团队经常会遇到一种令人困惑的情况：
网络链路完全正常，Ping 测试没有问题，Scanner（主站）和 Adapter（从站）的参数配置看上去也与 EDS 文件保持一致，但连接始终无法建立。报错信息通常指向 Invalid Size 或 Path Segment Error ，让人怀疑是不是配置写错了。经过深入分析后发现，问题往往并不在于 Instance 或者 RPI，而是隐藏在一个容易被忽视的细节------Run/Idle Header。这个额外的四个字节，常常成为连接失败的根源。
现象描述
在 ESDK (Embedded Software Development Kit) 的开发实践中，即便工程师严格按照 EDS 文件配置了 Input/Output Instance 和 Size，Forward_Open 握手仍可能失败。
原因在于部分设备的要求比想象中更严格：
它们不仅需要 64 字节的业务数据，还必须在前面加上 4 字节的状态报头，总长度达到 68 字节。如果 Scanner 仅仅配置了 64 字节，或者在计算内存偏移时忽略了报头的占位，那么 Adapter 就会判定报文不完整，从而拒绝连接。
这种情况在现场非常常见，尤其是当开发者依赖默认配置时，更容易掉入这个陷阱。
Run/Idle Header 的定义与作用
Run/Idle Header 的定义来自 CIP 规范。在 Class 1（隐式报文）连接中，可以选择挂载一个 32 位（4 字节）的状态报头。它的作用是传递 Scanner 的运行状态，通常只使用最低位：
当值为 1 时表示运行态，数据有效；
当值为 0 时表示调试或停止态，从站进入保护状态。
对于部分设备，这个报头并不是可选项，而是强制性的。如果报文缺少这 4 字节，Adapter 协议栈会直接判定为残缺报文并拒绝连接。换句话说，这个报头是 Scanner 向 Adapter 传递运行状态的唯一硬逻辑渠道，不能被忽略。
内存分布与偏移逻辑
在主流 ESDK 架构中，协议栈内部维护一个连续的 IO 内存镜像空间，所有连接的数据都按顺序线性排列。这种设计是为了保证实时性，避免动态寻址带来的时延抖动。然而，这也意味着偏移量的计算必须非常精确。每一路连接的起始偏移量都取决于上一条连接的物理长度，而这个物理长度必须包含业务数据和报头。如果第一路连接的长度是 68，那么第二路连接就会从第 69 字节开始。如果第一路漏掉了报头，只按 64 字节计算，那么后续所有连接都会产生位移性污染，导致应用层数据错乱。协议层面上这种错误可能仍然"合法"，但在应用层就会表现为数据乱码。
Header 的处理逻辑
在实践中，研发团队必须明确应用层和协议栈的边界。
以ESDK为例，对于发送侧（O→T），应用层只需提供 64 字节的业务数据，协议栈会在前部自动挂载 4 字节的状态位，从而形成完整的 68 字节报文。
而在接收侧（T→O），协议栈会将收到的 68 字节原样交给应用层，这时应用层必须主动跳过前 4 字节，才能正确读取后续的 64 字节业务数据。
如果应用层忽略了这一点，数据解析必然出错。实践中，很多团队会在封装函数里增加一个开关，用来决定是否启用报头，从而在不同设备间保持逻辑一致。
结论
工业通讯的核心不仅仅是数据传输，更是对齐逻辑的把握。遇到 Size Mismatch 时，第一步应该是核对 EDS 文件中的 Real-time Format 标志位，确认是否要求报头。在设计多连接系统时，必须建立偏移感知机制，把这 4 字节视为物理占位，而不是虚拟标志。只有这样，才能避免链式偏移带来的连锁反应，确保连接稳定和数据一致性。对于研发团队而言，这不仅是一次协议细节的考验，更是一次架构思维的训练。对齐逻辑的严谨性，正是工业通讯系统能够长期稳定运行的关键。