简介面向 IO 适配器设备的 EtherNet/IP 协议栈资料适合需要与罗克韦尔自动化产品对接、理解 CIP 连接管理、报文封装与设备通信流程的 C#.NET 开发者参考。压缩包共 230 个文件约 830KB以 167 个 HTML 文档、20 个头文件、15 个 C 源码和 10 张示意图为主另含 CSS、TXT、EDS 配置、PDF、构建工程及 Makefile 等便于按文档、源码与配置模块检索。内容覆盖连接管理、IO 连接、封装层、CPF、报文路由等实现可帮助读者梳理适配器侧协议栈结构、API 组织与联调排错思路对希望研究设备发现、连接建立、数据交换、异常处理、性能优化以及通信安全与实时性取舍的读者也能从源码和文档对照中理解接口分层、配置方式与调试要点。已有 625 人学习适合作为 EtherNet/IP 入门梳理和二次开发参考。1. 从一台“灯绿但不通”的 IO 适配器说起现场最常见的故障单是扫描器侧报连接超时设备面板的网口灯却一直绿着。灯绿只说明物理层活着EtherNet/IP 的适配器Adapter/Target要活下来还得自己撑住 RegisterSession 会话、维持 Class 1 隐式连接、按 RPI 周期往回吐数据。这份 EtherNet/IP stack for IO adapter devices 就是照这个位置做的用 C#.NET 实现从站侧协议栈把自研的远程 IO、阀岛、称重模块、编码器网关以标准从站身份挂到扫描器下面去而不是去扫别人。它适合两类读者正在做 EtherNet/IP 远程 IO 从站固件或工控网关的开发者以及需要一台 PC 或工控机模拟从站、用来做上位组态联调测试的人。看完你应该能判断这份栈的对象模型、连接参数和调度方式跟自己手上的硬件对不对得上。2. 拆开适配器栈三个端口、六个对象和一次 RegisterSession刚拿到这类代码包最忌讳上来就翻 Forward Open 那一坨字节。适配器侧真正的骨架只有三样东西端口怎么分工、对象模型要暴露哪几个实例、会话状态机怎么走。这三样定了后面的显式消息和隐式连接才谈得上“按规范走”。2.1 为什么适配器侧和扫描器侧是两套完全不同的代码扫描器侧是主动方可以容忍“发出去没回应就重发”适配器侧是被动方它必须同时应付多个扫描器的并发请求还得在没人问的时候按周期主动发包。这两种职责在代码结构上几乎没有复用价值这也是很多新手拿扫描器库改适配器会卡住的原因。适配器逻辑大致分三层。最底下是传输层TCP 44818 承载显式消息UDP 2222 承载隐式 I/OUDP 44818 只做 ListIdentity 广播应答。中间是 CIP 层负责解析服务码、EPATH 路径、状态码把请求路由到具体对象实例。最上面是应用层也就是你自己的 IO 映射表和连接管理器。选 C#.NET 做这件事的现实理由也很直接Socket、Span 、BinaryPrimitives 这一套在 .NET 里已经足够写零分配的字节解析跑在一台工控机或小型网关上完全够用而且上位组态联调时经常需要在 Windows 上临时起一个从站C# 的部署成本比交叉编译到嵌入式低太多。代价是 GC 抖动所以周期发包那条循环里不要做任何 LINQ 和字符串拼接缓冲区全部预分配。适配器必须暴露的对象实例按经验至少要齐这几类类代码对象实例适配器侧的作用0x01Identity1厂商标识、设备类型、状态字、序列号0x02Message Router1所有显式请求的入口0x04Assembly按需如 100/101/150输入/输出数据的容器0x06Connection Manager1Forward Open / Close 的落点0xF5TCP/IP Interface1IP、掩码、网关、配置方式0xF6Ethernet Link1MAC、链路速率、接口状态少一个 Identity 或 Connection Manager扫描器在扫描阶段就会放弃你表现是“能找到设备但加不进组态”。TCP/IP Interface 的实例 1 属性 3 是配置方式属性 5 是接口配置很多扫描器在建立连接前会先读一遍读到异常值同样会中止。2.2 44818 和 2222三个端口各管什么端口分不清抓包时会一直怀疑自己报文写错了。实际分工是这样的TCP 44818 走显式消息是可靠字节流RegisterSession、SendRRData、Forward Open 都在这条链路上。它有个坑TCP 是流式的你不能假设一次 Receive 就正好收到一个完整报文必须先读 24 字节封装头拿到 Length再按 Length 读数据体否则报文一粘包后面全部错位。UDP 44818 只用来应答 ListIdentity 广播。扫描器在网段里发广播包找设备适配器要在极短时间内回一个 Identity 信息这个响应里带的是设备身份摘要不带会话。这条路径不参与任何连接建立。UDP 2222 是隐式 I/O 的通道Class 1 连接的周期数据全走这里。它不可靠、不重传靠的是 RPI 周期和超时倍率来兜底。适配器在这条链路上只认 Connection ID收到一个带自己 T→O Connection ID 的包就把里面的数据搬进输入缓冲区然后按自己的节奏把 O→T 数据发回去。三个端口要同时监听常见做法是开三个独立线程或者在 .NET 里用异步 Socket 的 ReceiveFromAsync共用一组只读的对象字典。注意 UDP 2222 的绑定要用 SO_REUSEADDR工控机上经常有别的服务或者上一次没退干净的进程占着这个端口。2.3 用 C# 把会话骨架立起来RegisterSession 是整条显式链路的第一步也是最容易被忽略的一步它没有会话号就没法做任何对象读写。请求报文结构很固定24 字节封装头加 4 字节数据体。public sealed class EnipSession : IDisposable { private readonly Socket _tcp; private uint _sessionHandle; public EnipSession(string adapterIp) { _tcp new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); _tcp.NoDelay true; // 显式报文多是小包关掉 Nagle 降低往返延迟 _tcp.ReceiveTimeout 3000; // 联调阶段给足 3 秒产线上可以压到 1 秒 _tcp.Connect(IPAddress.Parse(adapterIp), 44818); } public bool Register() { // 封装头固定 24 字节Command(2) Length(2) SessionHandle(4) // Status(4) SenderContext(8) Options(4) var req new byte[28]; BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(0), 0x0065); // RegisterSession BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(2), 4); // 数据体长度 BinaryPrimitives.WriteUInt32LittleEndian(req.AsSpan(4), 0); // 会话句柄必须为 0 BinaryPrimitives.WriteUInt32LittleEndian(req.AsSpan(8), 0); // 状态必须为 0 // SenderContext 8 字节保持全 0适配器原样带回 BinaryPrimitives.WriteUInt32LittleEndian(req.AsSpan(20), 0); // Options 必须为 0 BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(24), 1); // 协议版本 1 BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(26), 0); // 选项标志 0 _tcp.Send(req); var head new byte[24]; if (!ReadExactly(head)) return false; ushort cmd BinaryPrimitives.ReadUInt16LittleEndian(head.AsSpan(0)); uint status BinaryPrimitives.ReadUInt32LittleEndian(head.AsSpan(8)); _sessionHandle BinaryPrimitives.ReadUInt32LittleEndian(head.AsSpan(4)); // 命令码要回声一致状态 0 表示成功句柄非 0 才算真正建立 return cmd 0x0065 status 0 _sessionHandle ! 0; } private bool ReadExactly(byte[] buffer) { int offset 0; while (offset buffer.Length) { int n _tcp.Receive(buffer, offset, buffer.Length - offset, SocketFlags.None); if (n 0) return false; offset n; } return true; } public void Dispose() { // 先 UnRegisterSession0x0066再关连接否则适配器侧的会话要等超时才回收 if (_sessionHandle ! 0) { var req new byte[24]; BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(0), 0x0066); BinaryPrimitives.WriteUInt32LittleEndian(req.AsSpan(4), _sessionHandle); try { _tcp.Send(req); } catch { /* 关闭阶段的异常不往上抛 */ } } _tcp.Dispose(); } }代码里三处参数值得单独说。NoDelay必须开显式报文本来就是一问一答的小包开着 Nagle 会让每次往返多出几十毫秒组态软件读十几个属性就能明显卡顿。SenderContext那 8 个字节适配器会原样带回联调时可以塞一个自增序号进去用来对齐请求和响应比看时间戳可靠。ReadExactly这个循环不能省TCP 粘包在属性批量读的时候几乎必然出现很多人第一次接真实 PLC 就是栽在这里报文明明对但一直解析失败。会话建立之后同一台适配器上的显式请求都复用这个句柄。反过来说适配器实现方要把会话表做成字典因为产线上经常有组态软件和另一台 HMI 同时登记会话只留一个_sessionHandle字段的写法在真实网络里一定翻车。3. 显式消息落地EPATH 编码、SendRRData 和一次对象读写自检会话有了接下来才是真正干活的部分把服务码、路径、数据塞进一个 CIP 报文再套上 CPF 和封装头发出去。这一步的难点不在协议理解而在字节顺序和路径对齐错一位整个请求就变成“服务不支持”。3.1 EPATH 的字节结构错一个字节后面全错CIP 路径EPATH是按段segment拼的最常用的是 8 位逻辑段一个段字节加上一到两个字节的实例/属性值。类用 0x20实例用 0x24属性用 0x30连接点用 0x2C。举个实际例子读 Assembly 实例 100 的属性 3路径是20 04 24 64 30 03第一段20 04表示 Class 4Assembly Object第二段24 64表示 Instance 0x64 100第三段30 03表示 Attribute 3。拼起来共 6 字节Path Size 字段填的是“字数”而不是字节数6 字节等于 3 个 WORD所以填 3。这里有两个血泪经验。第一Path Size 的单位是 WORD2 字节对齐如果你的路径拼出来是奇数长度比如只带 Class 和 Instance 共 4 字节没问题但某些带连接点的路径是 5 字节必须在末尾补一个 0 凑成偶数同时 Path Size 向上取整。第二逻辑段的值是小端序24 64里的 0x64 在低字节超过 255 的实例号比如连接点是 0x0196就要写成两字节2C 96 01段字节本身也要从 0x24 变成 0x25 这种带“后面跟两个字节”标志的形态。我把路径拼装写成独立的小工具任何时候都走它不手工拼字节public static class CipPath { // 8 位逻辑段Class(0x20) / Instance(0x24) / Attribute(0x30) / ConnectionPoint(0x2C) public static byte[] Build(params (byte seg, uint value)[] items) { var list new Listbyte(16); foreach (var (seg, value) in items) { if (value 0xFF) { list.Add(seg); // 段字节 list.Add((byte)value); // 单字节值 } else { list.Add((byte)(seg | 0x01)); // 置 bit0 表示后跟两个字节 list.Add((byte)(value 0xFF)); list.Add((byte)((value 8) 0xFF)); } } if (list.Count % 2 ! 0) list.Add(0x00); // WORD 对齐末尾补零 return list.ToArray(); } }参数说明seg传段类型常量value传实例号或属性号。奇数长度补零这条一定要留别想着“我这次路径是偶数长度就没事”等哪天加了连接点路径变成 9 字节缺了补零就会稳定收到 0x13路径长度错误的状态码。3.2 SendRRData 的 CPF 封装CIP 报文本身只是服务码 路径长度 路径 数据外面还要套一层公共包格式CPF再套 24 字节封装头。SendRRData 的命令码是 0x006F它的数据体结构是接口句柄 4 字节、超时 2 字节、然后接 CPF。CPF 里依次是条目数 2 字节、空地址条目0x0000长度 0、未连接数据条目0x00B2长度 N内容就是 CIP 报文。这两个条目顺序不能反适配器侧很多实现是严格按顺序解析的。public byte[] SendRRData(uint sessionHandle, byte[] cipMessage) { int cpfLen 2 (2 2 0) (2 2 cipMessage.Length); var buf new byte[24 4 2 cpfLen]; var span buf.AsSpan(); // ---- 封装头 ---- BinaryPrimitives.WriteUInt16LittleEndian(span[0..], 0x006F); // SendRRData BinaryPrimitives.WriteUInt16LittleEndian(span[2..], (ushort)(4 2 cpfLen)); BinaryPrimitives.WriteUInt32LittleEndian(span[4..], sessionHandle); // 会话句柄 BinaryPrimitives.WriteUInt32LittleEndian(span[8..], 0); // 状态 BinaryPrimitives.WriteUInt32LittleEndian(span[20..], 0); // Options // ---- 接口句柄与超时 ---- BinaryPrimitives.WriteUInt32LittleEndian(span[24..], 0); // 接口句柄固定 0 BinaryPrimitives.WriteUInt16LittleEndian(span[28..], 0); // 超时0 表示用默认 // ---- CPF ---- int p 30; BinaryPrimitives.WriteUInt16LittleEndian(span[p..], 2); p 2; // 条目数 2 BinaryPrimitives.WriteUInt16LittleEndian(span[p..], 0x0000); p 2; // 空地址条目 BinaryPrimitives.WriteUInt16LittleEndian(span[p..], 0); p 2; // 长度 0 BinaryPrimitives.WriteUInt16LittleEndian(span[p..], 0x00B2); p 2; // 未连接数据条目 BinaryPrimitives.WriteUInt16LittleEndian(span[p..], (ushort)cipMessage.Length); p 2; cipMessage.CopyTo(span[p..]); _tcp.Send(buf); // 响应按同样格式解析跳过 24 字节头 4 字节句柄 2 字节超时 // 第 2 个条目0x00B2的数据体就是 CIP 响应 return ReadCipResponse(); }超时字段填 0 是常规做法表示使用连接默认超时联调时如果适配器响应慢可以改成 0x000A单位秒观察差异但正式环境别乱改某些从站会直接拒收非默认值。接口句柄固定 0没有第二个取值。还有一个容易踩的坑响应里的通用状态码在 CIP 报文第一字节之后的位置第 2 字节是“扩展状态字节数”第 3、4 字节才是通用状态。很多人直接把 CIP 响应第二个字节当状态码读结果 0x00 永远读成成功故障被吞掉。判定成功要同时看“扩展状态字节数是否为 0”和“通用状态是否为 0”。3.3 用 Identity 和 Assembly 做一次读写自检拿到一份新栈我一般先做两件事一件是读 Identity 实例 1 的属性 1厂商 ID和属性 7产品名称另一件是读一次 Assembly 实例 100 的数据长度。这两件事覆盖了 EPATH 编码、CPF 封装、响应解析三条路径任意一条错都能立刻暴露。Identity 的读请求是服务码 0x0EGet_Attribute_Single路径20 01 24 01 30 01Path Size 为 3。产品名称是属性 7值类型是短字符串长度字节在前。public string ReadProductName() { // 服务码 0x0E 路径长度 3 路径 20 01 24 01 30 07 byte[] cip { 0x0E, 0x03, 0x20, 0x01, 0x24, 0x01, 0x30, 0x07 }; var resp SendRRData(_sessionHandle, cip); // 上文的发送方法 // resp[0]服务码回声, resp[1]扩展状态字节数, resp[2..4]通用状态 if (BinaryPrimitives.ReadUInt16LittleEndian(resp.AsSpan(2)) ! 0) return null; int valueOffset 4 BinaryPrimitives.ReadByte(resp.AsSpan(1)); // 跳过扩展状态 int strLen resp[valueOffset]; // 短字符串长度字节 return Encoding.ASCII.GetString(resp, valueOffset 1, strLen); }写操作同样走 0x10Set_Attribute_Single只是路径后面要接数据段。数据段的第一字节是类型码常见类型有 0xC3BOOL、0xC4SINT、0xC6INT、0xCADINT、0xCEREAL紧跟的是数据本身。BOOL 类型的值要占满一字节别只写一位。自检的顺序建议是Identity 读 → TCP/IP Interface 属性 5 读 → Assembly 实例长度读 → 单点写一个测试 Assembly。每做完一步再去做下一步。跳过前三步直接上 Forward Open一旦连接建不起来你根本分辨不出是路径错、对象错还是连接参数错这是我在联调里最浪费时间的一种局面。4. Forward Open 之后Class 1 隐式连接的参数怎么定显式消息通了只证明你能读写对象不代表扫描器能周期性地拿数据。隐式连接靠 Forward Open 建立参数填错的表现往往不是报错而是连接建立了但数据一直不刷新或者几十秒后莫名断开比直接失败难查得多。4.1 Forward Open 的字段与 RPI / 超时的取值逻辑Forward Open 服务码是 0x54路径指向 Connection Manager 的实例 1即20 06 24 01。请求体字段依次是优先级/时间片 1 字节、超时滴答 1 字节、O→T 连接 ID 4 字节、T→O 连接 ID 4 字节、连接序列号 2 字节、发起方厂商 ID 2 字节、发起方序列号 4 字节、连接超时倍率 1 字节、保留 3 字节、O→T 的 RPI 4 字节、O→T 网络连接参数 2 字节、T→O 的 RPI 4 字节、T→O 网络连接参数 2 字节、传输类型 1 字节。适配器实现方在响应里会返回自己分配的连接 ID注意这两个 ID 是适配器分配的不是扫描器提议的。真正的坑在这里请求里的连接 ID 是“建议值”有些实现会原样带回有些会重新分配所以之后发隐式数据时必须用响应里的值不能拿请求里自己填的那个用。RPI 的单位是微秒10 毫秒就是 10000。两个方向可以设成不同的 RPI但绝大多数扫描器会请求对称值。注意 RPI 的下限由设备能力决定常见适配器实现支持到 1 到 2 毫秒再低就要在文档里明确拒绝否则扫描器请求 500 微秒、你按 500 微秒排程又跑不动只会表现为连接不稳。超时由两个字段决定超时滴答和连接超时倍率。实际超时时间 RPI × 超时倍率常见倍率是 3 或 4。倍率设 1 意味着错一个周期就断产线稍微抖一下就掉线设成 8 又会导致真正断链后要很久才被识别扫描器那边迟迟不报警。我一般取 4兼顾灵敏和容忍度。网络连接参数这 2 字节低 9 位是连接尺寸字节数第 13 位表示固定/变长第 14、15 位是传输类别Class 1 循环填 0。举例32 字节的连接尺寸就是 0x0020如果同时要求变长就置上第 13 位。public byte[] BuildForwardOpen(ushort o2tSize, ushort t2oSize, uint rpiUs, byte multiplier) { var path CipPath.Build((0x20, 0x06), (0x24, 0x01)); // Connection Manager 实例 1 var buf new Listbyte(64); buf.Add(0x54); // Forward Open buf.Add((byte)(path.Length / 2)); // 路径字数 buf.AddRange(path); buf.Add(0x0A); // 优先级 时间片 buf.Add(0x20); // 超时滴答 buf.AddRange(new byte[4]); // O→T 连接 ID适配器会覆盖 buf.AddRange(new byte[4]); // T→O 连接 ID buf.AddRange(new byte[] { 0x11, 0x22 }); // 连接序列号 buf.AddRange(new byte[] { 0x00, 0x00 }); // 发起方厂商 ID buf.AddRange(new byte[4]); // 发起方序列号 buf.Add(multiplier); // 连接超时倍率 buf.AddRange(new byte[3]); // 保留 buf.AddRange(BitConverter.GetBytes(rpiUs)); // O→T RPI微秒小端 buf.AddRange(BitConverter.GetBytes(o2tSize)); // O→T 连接尺寸低 9 位有效 buf.AddRange(BitConverter.GetBytes(rpiUs)); // T→O RPI buf.AddRange(BitConverter.GetBytes(t2oSize)); // T→O 连接尺寸 buf.Add(0xA3); // 传输类型循环 Class 1 return buf.ToArray(); }这里时序参数的含义要说清0x0A是优先级与时间片的组合字节实际排程时不靠它决定精度真正决定发包节奏的是 RPI。0x20这个超时滴答会参与连接看门狗的换算数值越大容忍度越高。如果适配器侧收到的 RPI 小于自己能力正确做法是返回 Forward Open 失败并给出通用状态而不是默默按自己的能力跑——后者的结果就是扫描器认为连接正常但数据滞后。4.2 连接尺寸与 Assembly 实例的对齐关系连接尺寸是最容易对不上的一块。它表示这条连接里每个方向搬运的字节数必须和 Assembly 实例的数据长度完全一致多一字节少一字节都会被拒。对齐规则是O→T 连接尺寸对应扫描器写入的那个 Assembly 实例长度也就是适配器的输出数据T→O 连接尺寸对应适配器上报的那个实例长度输入数据。以常见的 32 字节输入、16 字节输出为例实例 100 是输入32 字节实例 101 是输出16 字节。那么 Forward Open 里 O→T 那组参数的连接尺寸要填 16T→O 那组填 32。反着填是新手最高频的错误而且现象特别迷惑连接能建立但读写的数据完全是错位的。如果设备支持可变长度连接连接尺寸可以是最大值实际报文长度在数据段里带但很多扫描器实现会按固定长度校验所以适配器侧要能同时处理两种模式至少在 EDS 里把固定长度写清楚。4.3 周期循环Stopwatch 驱动与 Sequence Count连接建立后适配器要按 T→O 的 RPI 周期性往扫描器发数据。这里不能用 Thread.Sleep 或者 Task.Delay因为 RPI 常常是 5 毫秒、10 毫秒这种量级睡眠精度和累积误差会让抖动大到扫描器无法接受。CLOCK_MONOTONIC 是唯一可靠的时钟源.NET 下用 Stopwatch 取时间戳按 deadline 排程每次计算下一帧的目标时间点而不是“发完再睡 RPI”。private void IoLoop(int rpiMs, uint t2oConnectionId, byte[] inputBuffer) { var sw Stopwatch.StartNew(); long nextTick sw.ElapsedTicks; long periodTicks rpiMs * Stopwatch.Frequency / 1000; byte sequence 0; while (!_stop) { long now sw.ElapsedTicks; if (now nextTick) { // 留 0.2 毫秒余量避免过度自旋烧 CPU int sleepMs (int)((nextTick - now) * 1000 / Stopwatch.Frequency); if (sleepMs 1) Thread.Sleep(sleepMs - 1); continue; } // Connected Data Item: 连接 ID(4) 序列号(2) 数据 var frame BuildUnitData(t2oConnectionId, sequence, inputBuffer); _udp2222.SendTo(frame, _scannerEndPoint); sequence; // 8 位循环回绕由接收方自行处理 nextTick periodTicks; if (now - nextTick periodTicks * 3) // 落后超过 3 个周期就重新对齐 nextTick now periodTicks; } }序列号Sequence Count这条值得单独讲。它是 2 字节、独立于数据的一条递增计数接收方用它判断有没有丢包或者乱序。适配器侧要老老实实每个周期加一别图省事固定为 0——某些扫描器实现会用这个字段做重复包过滤固定值可能导致数据被当作重复丢掉。nextTick periodTicks这种写法和Thread.Sleep(rpiMs)的区别在于累积误差的来源前者误差只来自单次调度延迟且不会累积后者每个周期都吃掉一点睡眠开销跑上几分钟你就会发现实际周期比设定值大了百分之几。这个百分比在 100 毫秒的 RPI 下无关紧要在 5 毫秒下足以让扫描器报连接抖动。隐式数据走 UDP 2222报文格式是24 字节封装头命令码 0x0070、接口句柄与超时、CPF 里的连接地址条目0x00A1长度 4内容是对向连接 ID和连接数据条目0x00B1长度 N内容是序列号加数据。发出去之后不要等应答UDP 上没有确认这回事链路的活性靠扫描器那边超时判断。5. 避坑与排查五个让适配器“灯绿但不通”的现场记录这类问题最麻烦的地方是物理层、链路层全绿故障只能从协议层找。我的习惯是先抓包再改代码抓包只看三个位置封装头的命令码与长度、CIP 报文的通用状态、连接参数里的尺寸与 RPI。下面五条是按出现频率排的。5.1 五条踩坑记录第一条RegisterSession 成功但后续所有请求返回 0x01。现象是会话能建起来读任何对象都收到“连接失败”或者“不支持的封装命令”。原因多半是请求里的 SessionHandle 字段用了 0或者每次请求都重新 Register 了一次导致前面的会话被顶掉。适配器侧的会话表是以句柄为键的句柄不对就路由不到。解决办法是建立会话后把句柄存下来所有后续报文头部都填这份句柄并保证 Disconnect 之前不重复注册。第二条扫描器能找到设备但加进组态时提示对象不存在。现象是 ListIdentity 广播有回应扫描阶段设备也列出来了一到读取电子数据表或者读 TCP/IP Interface 就失败。原因通常是对象实现不全很多最小实现只做了 Identity 和 Assembly忘了 TCP/IP Interface 的实例 1或者该实例的属性 3 返回了非法值。解决办法是把 0xF5 和 0xF6 两个对象补齐属性 3配置方式至少支持 0静态或 1DHCP属性 5 的结构体长度不能填错。第三条Forward Open 返回成功但输入数据永远不刷新。现象最典型连接建立、状态正常扫描器上的输入区一直是 0 或者一直是初值。原因通常是两个方向的连接 ID 用反了或者适配器在发隐式数据时用了请求里自己提议的 ID 而不是响应里分配的 ID。还有一种情况是 T→O 的 RPI 和实际发包周期不一致发了但扫描器按自己的窗口判定为超时丢包。解决办法是抓包确认响应里的连接 ID逐字节比对实际发包用的 ID并核对 RPI 换算10000 微秒对应 10 毫秒别把微秒当毫秒填。第四条连接跑几分钟后周期性断开重连又正常。现象是稳定运行三五分钟掉一次掉完自动恢复日志里只有超时。原因通常是周期循环里做了内存分配触发了 GC或者用了 Thread.Sleep 导致累积漂移超出扫描器容忍窗口。还有一种隐蔽情况是输入缓冲区没做双缓冲写线程和发送线程抢同一块内存偶尔发出去半新半旧的数据。解决办法是周期循环里零分配、用预分配缓冲加双缓冲交换、把调度改成基于 deadline 的绝对时间排程并在应用层统计每帧实际间隔超过 RPI 的 1.5 倍就记一次告警。第五条多个扫描器同时连接时其中一个总是失败。现象是单客户端一切正常两台上位机或一台 PLC 加一个组态软件同时连后连的那个拿不到数据。原因是适配器侧只维护了一份连接状态后到的 Forward Open 直接覆盖了先前的连接 ID导致先前的连接静默失效。解决办法是把连接表做成以连接 ID 为键的字典会话和连接分开管理同时在 Fusetime 到期时主动清理别让失效连接占着槽位。5.2 抓包时先看哪几个字段Wireshark 对 EtherNet/IP 有原生解析但自动解析有时会把 CIP 层解错所以我的习惯是关掉 CIP 解析直接看原始字节。过滤条件按排查阶段分# 阶段一只看显式消息和广播发现 tcp.port 44818 || udp.port 44818 # 阶段二只看隐式 I/O用连接 ID 精确定位 udp.port 2222 udp.length 40 # 阶段三过滤出 Forward Open 请求 tcp.port 44818 tcp.payload[0:2] 54:00第一条用来确认会话有没有建立重点看响应头部的句柄字段非 0。第二条用来确认隐式数据到底有没有发出去、周期稳不稳把时间列打开看相邻包的间隔抖动一眼就能看出来。第三条用来定位连接参数重点核对连接尺寸和 RPI 的字节序。抓包之外还有两个便宜但有效的检查点。一是把适配器的对象字典做成可查询的收到不认识的 EPATH 时返回明确的通用状态而不是默默成功这样扫描器报错信息会具体很多。二是给每个连接维护一个“最后收到有效包的时间”超过 RPI 乘倍率就打印一条日志这条日志在排查“数据不刷新”时比抓包快得多。6. 用 EDS 和回环压测验收这套栈代码能跑通和能交付之间还差一步验收。我的做法是两个东西一份跟实现严格对齐的 EDS 文件和一段能统计抖动的回环脚本。EDS 里最容易和代码脱节的是三处连接尺寸、RPI 范围、Assembly 实例号。EDS 里写的输入输出字节数必须和 Forward Open 里填的一致写的 RPI 最小最大值必须和实现能力一致。我见过 EDS 写最小 1 毫秒、实现只能跑 10 毫秒的情况结果是组态软件按 1 毫秒建连运行起来就间歇性超时查半天才发现问题在电子数据表。验收时把 EDS 里的每个 Assembly 实例和代码里的对象字典逐条对一遍不要相信“上次是对齐的”。回环压测不用多复杂跑一个从站实例加一个自发自收的客户端统计三个指标就够了。指标采集方式合格线以 10 毫秒 RPI 为例平均周期相邻两帧发送时间戳之差10.0 ± 0.3 毫秒抖动 P99周期分布的分位数小于 1.5 毫秒连续运行丢帧序列号缺口计数1 小时内为 0跑满一小时再下结论。很多问题在三十秒内不出现比如 GC 触发的周期性停顿、连接表泄漏、超时清理逻辑把正常连接误杀这些都要跑到几分钟以上才会冒头。压测时把 CPU 占用一起看着如果单核长期跑满说明周期循环里的自旋比重太大减小余量或者改用异步等待。最后一条是验收的心态问题。我踩过最不值的一次坑是把一个只支持单连接的实现直接推给了现场理由是“实验室里一台组态软件连得好好的”。结果产线上线第一天工程师拿笔记本又连了一次做诊断两条连接直接互相顶掉整条线停了两小时。从那以后我每次交付前都强制走一遍“两个客户端同时连接 断开其中一个 另一个继续跑”的流程不管需求里写没写多客户端。上面这套对参数和压测的检查流程也是那之后固定下来的习惯。希望帮到你。本文还有配套的精品资源点击获取
简介面向 IO 适配器设备的 EtherNet/IP 协议栈资料适合需要与罗克韦尔自动化产品对接、理解 CIP 连接管理、报文封装与设备通信流程的 C#.NET 开发者参考。压缩包共 230 个文件约 830KB以 167 个 HTML 文档、20 个头文件、15 个 C 源码和 10 张示意图为主另含 CSS、TXT、EDS 配置、PDF、构建工程及 Makefile 等便于按文档、源码与配置模块检索。内容覆盖连接管理、IO 连接、封装层、CPF、报文路由等实现可帮助读者梳理适配器侧协议栈结构、API 组织与联调排错思路对希望研究设备发现、连接建立、数据交换、异常处理、性能优化以及通信安全与实时性取舍的读者也能从源码和文档对照中理解接口分层、配置方式与调试要点。已有 625 人学习适合作为 EtherNet/IP 入门梳理和二次开发参考。1. 从一台“灯绿但不通”的 IO 适配器说起现场最常见的故障单是扫描器侧报连接超时设备面板的网口灯却一直绿着。灯绿只说明物理层活着EtherNet/IP 的适配器Adapter/Target要活下来还得自己撑住 RegisterSession 会话、维持 Class 1 隐式连接、按 RPI 周期往回吐数据。这份 EtherNet/IP stack for IO adapter devices 就是照这个位置做的用 C#.NET 实现从站侧协议栈把自研的远程 IO、阀岛、称重模块、编码器网关以标准从站身份挂到扫描器下面去而不是去扫别人。它适合两类读者正在做 EtherNet/IP 远程 IO 从站固件或工控网关的开发者以及需要一台 PC 或工控机模拟从站、用来做上位组态联调测试的人。看完你应该能判断这份栈的对象模型、连接参数和调度方式跟自己手上的硬件对不对得上。2. 拆开适配器栈三个端口、六个对象和一次 RegisterSession刚拿到这类代码包最忌讳上来就翻 Forward Open 那一坨字节。适配器侧真正的骨架只有三样东西端口怎么分工、对象模型要暴露哪几个实例、会话状态机怎么走。这三样定了后面的显式消息和隐式连接才谈得上“按规范走”。2.1 为什么适配器侧和扫描器侧是两套完全不同的代码扫描器侧是主动方可以容忍“发出去没回应就重发”适配器侧是被动方它必须同时应付多个扫描器的并发请求还得在没人问的时候按周期主动发包。这两种职责在代码结构上几乎没有复用价值这也是很多新手拿扫描器库改适配器会卡住的原因。适配器逻辑大致分三层。最底下是传输层TCP 44818 承载显式消息UDP 2222 承载隐式 I/OUDP 44818 只做 ListIdentity 广播应答。中间是 CIP 层负责解析服务码、EPATH 路径、状态码把请求路由到具体对象实例。最上面是应用层也就是你自己的 IO 映射表和连接管理器。选 C#.NET 做这件事的现实理由也很直接Socket、Span 、BinaryPrimitives 这一套在 .NET 里已经足够写零分配的字节解析跑在一台工控机或小型网关上完全够用而且上位组态联调时经常需要在 Windows 上临时起一个从站C# 的部署成本比交叉编译到嵌入式低太多。代价是 GC 抖动所以周期发包那条循环里不要做任何 LINQ 和字符串拼接缓冲区全部预分配。适配器必须暴露的对象实例按经验至少要齐这几类类代码对象实例适配器侧的作用0x01Identity1厂商标识、设备类型、状态字、序列号0x02Message Router1所有显式请求的入口0x04Assembly按需如 100/101/150输入/输出数据的容器0x06Connection Manager1Forward Open / Close 的落点0xF5TCP/IP Interface1IP、掩码、网关、配置方式0xF6Ethernet Link1MAC、链路速率、接口状态少一个 Identity 或 Connection Manager扫描器在扫描阶段就会放弃你表现是“能找到设备但加不进组态”。TCP/IP Interface 的实例 1 属性 3 是配置方式属性 5 是接口配置很多扫描器在建立连接前会先读一遍读到异常值同样会中止。2.2 44818 和 2222三个端口各管什么端口分不清抓包时会一直怀疑自己报文写错了。实际分工是这样的TCP 44818 走显式消息是可靠字节流RegisterSession、SendRRData、Forward Open 都在这条链路上。它有个坑TCP 是流式的你不能假设一次 Receive 就正好收到一个完整报文必须先读 24 字节封装头拿到 Length再按 Length 读数据体否则报文一粘包后面全部错位。UDP 44818 只用来应答 ListIdentity 广播。扫描器在网段里发广播包找设备适配器要在极短时间内回一个 Identity 信息这个响应里带的是设备身份摘要不带会话。这条路径不参与任何连接建立。UDP 2222 是隐式 I/O 的通道Class 1 连接的周期数据全走这里。它不可靠、不重传靠的是 RPI 周期和超时倍率来兜底。适配器在这条链路上只认 Connection ID收到一个带自己 T→O Connection ID 的包就把里面的数据搬进输入缓冲区然后按自己的节奏把 O→T 数据发回去。三个端口要同时监听常见做法是开三个独立线程或者在 .NET 里用异步 Socket 的 ReceiveFromAsync共用一组只读的对象字典。注意 UDP 2222 的绑定要用 SO_REUSEADDR工控机上经常有别的服务或者上一次没退干净的进程占着这个端口。2.3 用 C# 把会话骨架立起来RegisterSession 是整条显式链路的第一步也是最容易被忽略的一步它没有会话号就没法做任何对象读写。请求报文结构很固定24 字节封装头加 4 字节数据体。public sealed class EnipSession : IDisposable { private readonly Socket _tcp; private uint _sessionHandle; public EnipSession(string adapterIp) { _tcp new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); _tcp.NoDelay true; // 显式报文多是小包关掉 Nagle 降低往返延迟 _tcp.ReceiveTimeout 3000; // 联调阶段给足 3 秒产线上可以压到 1 秒 _tcp.Connect(IPAddress.Parse(adapterIp), 44818); } public bool Register() { // 封装头固定 24 字节Command(2) Length(2) SessionHandle(4) // Status(4) SenderContext(8) Options(4) var req new byte[28]; BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(0), 0x0065); // RegisterSession BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(2), 4); // 数据体长度 BinaryPrimitives.WriteUInt32LittleEndian(req.AsSpan(4), 0); // 会话句柄必须为 0 BinaryPrimitives.WriteUInt32LittleEndian(req.AsSpan(8), 0); // 状态必须为 0 // SenderContext 8 字节保持全 0适配器原样带回 BinaryPrimitives.WriteUInt32LittleEndian(req.AsSpan(20), 0); // Options 必须为 0 BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(24), 1); // 协议版本 1 BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(26), 0); // 选项标志 0 _tcp.Send(req); var head new byte[24]; if (!ReadExactly(head)) return false; ushort cmd BinaryPrimitives.ReadUInt16LittleEndian(head.AsSpan(0)); uint status BinaryPrimitives.ReadUInt32LittleEndian(head.AsSpan(8)); _sessionHandle BinaryPrimitives.ReadUInt32LittleEndian(head.AsSpan(4)); // 命令码要回声一致状态 0 表示成功句柄非 0 才算真正建立 return cmd 0x0065 status 0 _sessionHandle ! 0; } private bool ReadExactly(byte[] buffer) { int offset 0; while (offset buffer.Length) { int n _tcp.Receive(buffer, offset, buffer.Length - offset, SocketFlags.None); if (n 0) return false; offset n; } return true; } public void Dispose() { // 先 UnRegisterSession0x0066再关连接否则适配器侧的会话要等超时才回收 if (_sessionHandle ! 0) { var req new byte[24]; BinaryPrimitives.WriteUInt16LittleEndian(req.AsSpan(0), 0x0066); BinaryPrimitives.WriteUInt32LittleEndian(req.AsSpan(4), _sessionHandle); try { _tcp.Send(req); } catch { /* 关闭阶段的异常不往上抛 */ } } _tcp.Dispose(); } }代码里三处参数值得单独说。NoDelay必须开显式报文本来就是一问一答的小包开着 Nagle 会让每次往返多出几十毫秒组态软件读十几个属性就能明显卡顿。SenderContext那 8 个字节适配器会原样带回联调时可以塞一个自增序号进去用来对齐请求和响应比看时间戳可靠。ReadExactly这个循环不能省TCP 粘包在属性批量读的时候几乎必然出现很多人第一次接真实 PLC 就是栽在这里报文明明对但一直解析失败。会话建立之后同一台适配器上的显式请求都复用这个句柄。反过来说适配器实现方要把会话表做成字典因为产线上经常有组态软件和另一台 HMI 同时登记会话只留一个_sessionHandle字段的写法在真实网络里一定翻车。3. 显式消息落地EPATH 编码、SendRRData 和一次对象读写自检会话有了接下来才是真正干活的部分把服务码、路径、数据塞进一个 CIP 报文再套上 CPF 和封装头发出去。这一步的难点不在协议理解而在字节顺序和路径对齐错一位整个请求就变成“服务不支持”。3.1 EPATH 的字节结构错一个字节后面全错CIP 路径EPATH是按段segment拼的最常用的是 8 位逻辑段一个段字节加上一到两个字节的实例/属性值。类用 0x20实例用 0x24属性用 0x30连接点用 0x2C。举个实际例子读 Assembly 实例 100 的属性 3路径是20 04 24 64 30 03第一段20 04表示 Class 4Assembly Object第二段24 64表示 Instance 0x64 100第三段30 03表示 Attribute 3。拼起来共 6 字节Path Size 字段填的是“字数”而不是字节数6 字节等于 3 个 WORD所以填 3。这里有两个血泪经验。第一Path Size 的单位是 WORD2 字节对齐如果你的路径拼出来是奇数长度比如只带 Class 和 Instance 共 4 字节没问题但某些带连接点的路径是 5 字节必须在末尾补一个 0 凑成偶数同时 Path Size 向上取整。第二逻辑段的值是小端序24 64里的 0x64 在低字节超过 255 的实例号比如连接点是 0x0196就要写成两字节2C 96 01段字节本身也要从 0x24 变成 0x25 这种带“后面跟两个字节”标志的形态。我把路径拼装写成独立的小工具任何时候都走它不手工拼字节public static class CipPath { // 8 位逻辑段Class(0x20) / Instance(0x24) / Attribute(0x30) / ConnectionPoint(0x2C) public static byte[] Build(params (byte seg, uint value)[] items) { var list new Listbyte(16); foreach (var (seg, value) in items) { if (value 0xFF) { list.Add(seg); // 段字节 list.Add((byte)value); // 单字节值 } else { list.Add((byte)(seg | 0x01)); // 置 bit0 表示后跟两个字节 list.Add((byte)(value 0xFF)); list.Add((byte)((value 8) 0xFF)); } } if (list.Count % 2 ! 0) list.Add(0x00); // WORD 对齐末尾补零 return list.ToArray(); } }参数说明seg传段类型常量value传实例号或属性号。奇数长度补零这条一定要留别想着“我这次路径是偶数长度就没事”等哪天加了连接点路径变成 9 字节缺了补零就会稳定收到 0x13路径长度错误的状态码。3.2 SendRRData 的 CPF 封装CIP 报文本身只是服务码 路径长度 路径 数据外面还要套一层公共包格式CPF再套 24 字节封装头。SendRRData 的命令码是 0x006F它的数据体结构是接口句柄 4 字节、超时 2 字节、然后接 CPF。CPF 里依次是条目数 2 字节、空地址条目0x0000长度 0、未连接数据条目0x00B2长度 N内容就是 CIP 报文。这两个条目顺序不能反适配器侧很多实现是严格按顺序解析的。public byte[] SendRRData(uint sessionHandle, byte[] cipMessage) { int cpfLen 2 (2 2 0) (2 2 cipMessage.Length); var buf new byte[24 4 2 cpfLen]; var span buf.AsSpan(); // ---- 封装头 ---- BinaryPrimitives.WriteUInt16LittleEndian(span[0..], 0x006F); // SendRRData BinaryPrimitives.WriteUInt16LittleEndian(span[2..], (ushort)(4 2 cpfLen)); BinaryPrimitives.WriteUInt32LittleEndian(span[4..], sessionHandle); // 会话句柄 BinaryPrimitives.WriteUInt32LittleEndian(span[8..], 0); // 状态 BinaryPrimitives.WriteUInt32LittleEndian(span[20..], 0); // Options // ---- 接口句柄与超时 ---- BinaryPrimitives.WriteUInt32LittleEndian(span[24..], 0); // 接口句柄固定 0 BinaryPrimitives.WriteUInt16LittleEndian(span[28..], 0); // 超时0 表示用默认 // ---- CPF ---- int p 30; BinaryPrimitives.WriteUInt16LittleEndian(span[p..], 2); p 2; // 条目数 2 BinaryPrimitives.WriteUInt16LittleEndian(span[p..], 0x0000); p 2; // 空地址条目 BinaryPrimitives.WriteUInt16LittleEndian(span[p..], 0); p 2; // 长度 0 BinaryPrimitives.WriteUInt16LittleEndian(span[p..], 0x00B2); p 2; // 未连接数据条目 BinaryPrimitives.WriteUInt16LittleEndian(span[p..], (ushort)cipMessage.Length); p 2; cipMessage.CopyTo(span[p..]); _tcp.Send(buf); // 响应按同样格式解析跳过 24 字节头 4 字节句柄 2 字节超时 // 第 2 个条目0x00B2的数据体就是 CIP 响应 return ReadCipResponse(); }超时字段填 0 是常规做法表示使用连接默认超时联调时如果适配器响应慢可以改成 0x000A单位秒观察差异但正式环境别乱改某些从站会直接拒收非默认值。接口句柄固定 0没有第二个取值。还有一个容易踩的坑响应里的通用状态码在 CIP 报文第一字节之后的位置第 2 字节是“扩展状态字节数”第 3、4 字节才是通用状态。很多人直接把 CIP 响应第二个字节当状态码读结果 0x00 永远读成成功故障被吞掉。判定成功要同时看“扩展状态字节数是否为 0”和“通用状态是否为 0”。3.3 用 Identity 和 Assembly 做一次读写自检拿到一份新栈我一般先做两件事一件是读 Identity 实例 1 的属性 1厂商 ID和属性 7产品名称另一件是读一次 Assembly 实例 100 的数据长度。这两件事覆盖了 EPATH 编码、CPF 封装、响应解析三条路径任意一条错都能立刻暴露。Identity 的读请求是服务码 0x0EGet_Attribute_Single路径20 01 24 01 30 01Path Size 为 3。产品名称是属性 7值类型是短字符串长度字节在前。public string ReadProductName() { // 服务码 0x0E 路径长度 3 路径 20 01 24 01 30 07 byte[] cip { 0x0E, 0x03, 0x20, 0x01, 0x24, 0x01, 0x30, 0x07 }; var resp SendRRData(_sessionHandle, cip); // 上文的发送方法 // resp[0]服务码回声, resp[1]扩展状态字节数, resp[2..4]通用状态 if (BinaryPrimitives.ReadUInt16LittleEndian(resp.AsSpan(2)) ! 0) return null; int valueOffset 4 BinaryPrimitives.ReadByte(resp.AsSpan(1)); // 跳过扩展状态 int strLen resp[valueOffset]; // 短字符串长度字节 return Encoding.ASCII.GetString(resp, valueOffset 1, strLen); }写操作同样走 0x10Set_Attribute_Single只是路径后面要接数据段。数据段的第一字节是类型码常见类型有 0xC3BOOL、0xC4SINT、0xC6INT、0xCADINT、0xCEREAL紧跟的是数据本身。BOOL 类型的值要占满一字节别只写一位。自检的顺序建议是Identity 读 → TCP/IP Interface 属性 5 读 → Assembly 实例长度读 → 单点写一个测试 Assembly。每做完一步再去做下一步。跳过前三步直接上 Forward Open一旦连接建不起来你根本分辨不出是路径错、对象错还是连接参数错这是我在联调里最浪费时间的一种局面。4. Forward Open 之后Class 1 隐式连接的参数怎么定显式消息通了只证明你能读写对象不代表扫描器能周期性地拿数据。隐式连接靠 Forward Open 建立参数填错的表现往往不是报错而是连接建立了但数据一直不刷新或者几十秒后莫名断开比直接失败难查得多。4.1 Forward Open 的字段与 RPI / 超时的取值逻辑Forward Open 服务码是 0x54路径指向 Connection Manager 的实例 1即20 06 24 01。请求体字段依次是优先级/时间片 1 字节、超时滴答 1 字节、O→T 连接 ID 4 字节、T→O 连接 ID 4 字节、连接序列号 2 字节、发起方厂商 ID 2 字节、发起方序列号 4 字节、连接超时倍率 1 字节、保留 3 字节、O→T 的 RPI 4 字节、O→T 网络连接参数 2 字节、T→O 的 RPI 4 字节、T→O 网络连接参数 2 字节、传输类型 1 字节。适配器实现方在响应里会返回自己分配的连接 ID注意这两个 ID 是适配器分配的不是扫描器提议的。真正的坑在这里请求里的连接 ID 是“建议值”有些实现会原样带回有些会重新分配所以之后发隐式数据时必须用响应里的值不能拿请求里自己填的那个用。RPI 的单位是微秒10 毫秒就是 10000。两个方向可以设成不同的 RPI但绝大多数扫描器会请求对称值。注意 RPI 的下限由设备能力决定常见适配器实现支持到 1 到 2 毫秒再低就要在文档里明确拒绝否则扫描器请求 500 微秒、你按 500 微秒排程又跑不动只会表现为连接不稳。超时由两个字段决定超时滴答和连接超时倍率。实际超时时间 RPI × 超时倍率常见倍率是 3 或 4。倍率设 1 意味着错一个周期就断产线稍微抖一下就掉线设成 8 又会导致真正断链后要很久才被识别扫描器那边迟迟不报警。我一般取 4兼顾灵敏和容忍度。网络连接参数这 2 字节低 9 位是连接尺寸字节数第 13 位表示固定/变长第 14、15 位是传输类别Class 1 循环填 0。举例32 字节的连接尺寸就是 0x0020如果同时要求变长就置上第 13 位。public byte[] BuildForwardOpen(ushort o2tSize, ushort t2oSize, uint rpiUs, byte multiplier) { var path CipPath.Build((0x20, 0x06), (0x24, 0x01)); // Connection Manager 实例 1 var buf new Listbyte(64); buf.Add(0x54); // Forward Open buf.Add((byte)(path.Length / 2)); // 路径字数 buf.AddRange(path); buf.Add(0x0A); // 优先级 时间片 buf.Add(0x20); // 超时滴答 buf.AddRange(new byte[4]); // O→T 连接 ID适配器会覆盖 buf.AddRange(new byte[4]); // T→O 连接 ID buf.AddRange(new byte[] { 0x11, 0x22 }); // 连接序列号 buf.AddRange(new byte[] { 0x00, 0x00 }); // 发起方厂商 ID buf.AddRange(new byte[4]); // 发起方序列号 buf.Add(multiplier); // 连接超时倍率 buf.AddRange(new byte[3]); // 保留 buf.AddRange(BitConverter.GetBytes(rpiUs)); // O→T RPI微秒小端 buf.AddRange(BitConverter.GetBytes(o2tSize)); // O→T 连接尺寸低 9 位有效 buf.AddRange(BitConverter.GetBytes(rpiUs)); // T→O RPI buf.AddRange(BitConverter.GetBytes(t2oSize)); // T→O 连接尺寸 buf.Add(0xA3); // 传输类型循环 Class 1 return buf.ToArray(); }这里时序参数的含义要说清0x0A是优先级与时间片的组合字节实际排程时不靠它决定精度真正决定发包节奏的是 RPI。0x20这个超时滴答会参与连接看门狗的换算数值越大容忍度越高。如果适配器侧收到的 RPI 小于自己能力正确做法是返回 Forward Open 失败并给出通用状态而不是默默按自己的能力跑——后者的结果就是扫描器认为连接正常但数据滞后。4.2 连接尺寸与 Assembly 实例的对齐关系连接尺寸是最容易对不上的一块。它表示这条连接里每个方向搬运的字节数必须和 Assembly 实例的数据长度完全一致多一字节少一字节都会被拒。对齐规则是O→T 连接尺寸对应扫描器写入的那个 Assembly 实例长度也就是适配器的输出数据T→O 连接尺寸对应适配器上报的那个实例长度输入数据。以常见的 32 字节输入、16 字节输出为例实例 100 是输入32 字节实例 101 是输出16 字节。那么 Forward Open 里 O→T 那组参数的连接尺寸要填 16T→O 那组填 32。反着填是新手最高频的错误而且现象特别迷惑连接能建立但读写的数据完全是错位的。如果设备支持可变长度连接连接尺寸可以是最大值实际报文长度在数据段里带但很多扫描器实现会按固定长度校验所以适配器侧要能同时处理两种模式至少在 EDS 里把固定长度写清楚。4.3 周期循环Stopwatch 驱动与 Sequence Count连接建立后适配器要按 T→O 的 RPI 周期性往扫描器发数据。这里不能用 Thread.Sleep 或者 Task.Delay因为 RPI 常常是 5 毫秒、10 毫秒这种量级睡眠精度和累积误差会让抖动大到扫描器无法接受。CLOCK_MONOTONIC 是唯一可靠的时钟源.NET 下用 Stopwatch 取时间戳按 deadline 排程每次计算下一帧的目标时间点而不是“发完再睡 RPI”。private void IoLoop(int rpiMs, uint t2oConnectionId, byte[] inputBuffer) { var sw Stopwatch.StartNew(); long nextTick sw.ElapsedTicks; long periodTicks rpiMs * Stopwatch.Frequency / 1000; byte sequence 0; while (!_stop) { long now sw.ElapsedTicks; if (now nextTick) { // 留 0.2 毫秒余量避免过度自旋烧 CPU int sleepMs (int)((nextTick - now) * 1000 / Stopwatch.Frequency); if (sleepMs 1) Thread.Sleep(sleepMs - 1); continue; } // Connected Data Item: 连接 ID(4) 序列号(2) 数据 var frame BuildUnitData(t2oConnectionId, sequence, inputBuffer); _udp2222.SendTo(frame, _scannerEndPoint); sequence; // 8 位循环回绕由接收方自行处理 nextTick periodTicks; if (now - nextTick periodTicks * 3) // 落后超过 3 个周期就重新对齐 nextTick now periodTicks; } }序列号Sequence Count这条值得单独讲。它是 2 字节、独立于数据的一条递增计数接收方用它判断有没有丢包或者乱序。适配器侧要老老实实每个周期加一别图省事固定为 0——某些扫描器实现会用这个字段做重复包过滤固定值可能导致数据被当作重复丢掉。nextTick periodTicks这种写法和Thread.Sleep(rpiMs)的区别在于累积误差的来源前者误差只来自单次调度延迟且不会累积后者每个周期都吃掉一点睡眠开销跑上几分钟你就会发现实际周期比设定值大了百分之几。这个百分比在 100 毫秒的 RPI 下无关紧要在 5 毫秒下足以让扫描器报连接抖动。隐式数据走 UDP 2222报文格式是24 字节封装头命令码 0x0070、接口句柄与超时、CPF 里的连接地址条目0x00A1长度 4内容是对向连接 ID和连接数据条目0x00B1长度 N内容是序列号加数据。发出去之后不要等应答UDP 上没有确认这回事链路的活性靠扫描器那边超时判断。5. 避坑与排查五个让适配器“灯绿但不通”的现场记录这类问题最麻烦的地方是物理层、链路层全绿故障只能从协议层找。我的习惯是先抓包再改代码抓包只看三个位置封装头的命令码与长度、CIP 报文的通用状态、连接参数里的尺寸与 RPI。下面五条是按出现频率排的。5.1 五条踩坑记录第一条RegisterSession 成功但后续所有请求返回 0x01。现象是会话能建起来读任何对象都收到“连接失败”或者“不支持的封装命令”。原因多半是请求里的 SessionHandle 字段用了 0或者每次请求都重新 Register 了一次导致前面的会话被顶掉。适配器侧的会话表是以句柄为键的句柄不对就路由不到。解决办法是建立会话后把句柄存下来所有后续报文头部都填这份句柄并保证 Disconnect 之前不重复注册。第二条扫描器能找到设备但加进组态时提示对象不存在。现象是 ListIdentity 广播有回应扫描阶段设备也列出来了一到读取电子数据表或者读 TCP/IP Interface 就失败。原因通常是对象实现不全很多最小实现只做了 Identity 和 Assembly忘了 TCP/IP Interface 的实例 1或者该实例的属性 3 返回了非法值。解决办法是把 0xF5 和 0xF6 两个对象补齐属性 3配置方式至少支持 0静态或 1DHCP属性 5 的结构体长度不能填错。第三条Forward Open 返回成功但输入数据永远不刷新。现象最典型连接建立、状态正常扫描器上的输入区一直是 0 或者一直是初值。原因通常是两个方向的连接 ID 用反了或者适配器在发隐式数据时用了请求里自己提议的 ID 而不是响应里分配的 ID。还有一种情况是 T→O 的 RPI 和实际发包周期不一致发了但扫描器按自己的窗口判定为超时丢包。解决办法是抓包确认响应里的连接 ID逐字节比对实际发包用的 ID并核对 RPI 换算10000 微秒对应 10 毫秒别把微秒当毫秒填。第四条连接跑几分钟后周期性断开重连又正常。现象是稳定运行三五分钟掉一次掉完自动恢复日志里只有超时。原因通常是周期循环里做了内存分配触发了 GC或者用了 Thread.Sleep 导致累积漂移超出扫描器容忍窗口。还有一种隐蔽情况是输入缓冲区没做双缓冲写线程和发送线程抢同一块内存偶尔发出去半新半旧的数据。解决办法是周期循环里零分配、用预分配缓冲加双缓冲交换、把调度改成基于 deadline 的绝对时间排程并在应用层统计每帧实际间隔超过 RPI 的 1.5 倍就记一次告警。第五条多个扫描器同时连接时其中一个总是失败。现象是单客户端一切正常两台上位机或一台 PLC 加一个组态软件同时连后连的那个拿不到数据。原因是适配器侧只维护了一份连接状态后到的 Forward Open 直接覆盖了先前的连接 ID导致先前的连接静默失效。解决办法是把连接表做成以连接 ID 为键的字典会话和连接分开管理同时在 Fusetime 到期时主动清理别让失效连接占着槽位。5.2 抓包时先看哪几个字段Wireshark 对 EtherNet/IP 有原生解析但自动解析有时会把 CIP 层解错所以我的习惯是关掉 CIP 解析直接看原始字节。过滤条件按排查阶段分# 阶段一只看显式消息和广播发现 tcp.port 44818 || udp.port 44818 # 阶段二只看隐式 I/O用连接 ID 精确定位 udp.port 2222 udp.length 40 # 阶段三过滤出 Forward Open 请求 tcp.port 44818 tcp.payload[0:2] 54:00第一条用来确认会话有没有建立重点看响应头部的句柄字段非 0。第二条用来确认隐式数据到底有没有发出去、周期稳不稳把时间列打开看相邻包的间隔抖动一眼就能看出来。第三条用来定位连接参数重点核对连接尺寸和 RPI 的字节序。抓包之外还有两个便宜但有效的检查点。一是把适配器的对象字典做成可查询的收到不认识的 EPATH 时返回明确的通用状态而不是默默成功这样扫描器报错信息会具体很多。二是给每个连接维护一个“最后收到有效包的时间”超过 RPI 乘倍率就打印一条日志这条日志在排查“数据不刷新”时比抓包快得多。6. 用 EDS 和回环压测验收这套栈代码能跑通和能交付之间还差一步验收。我的做法是两个东西一份跟实现严格对齐的 EDS 文件和一段能统计抖动的回环脚本。EDS 里最容易和代码脱节的是三处连接尺寸、RPI 范围、Assembly 实例号。EDS 里写的输入输出字节数必须和 Forward Open 里填的一致写的 RPI 最小最大值必须和实现能力一致。我见过 EDS 写最小 1 毫秒、实现只能跑 10 毫秒的情况结果是组态软件按 1 毫秒建连运行起来就间歇性超时查半天才发现问题在电子数据表。验收时把 EDS 里的每个 Assembly 实例和代码里的对象字典逐条对一遍不要相信“上次是对齐的”。回环压测不用多复杂跑一个从站实例加一个自发自收的客户端统计三个指标就够了。指标采集方式合格线以 10 毫秒 RPI 为例平均周期相邻两帧发送时间戳之差10.0 ± 0.3 毫秒抖动 P99周期分布的分位数小于 1.5 毫秒连续运行丢帧序列号缺口计数1 小时内为 0跑满一小时再下结论。很多问题在三十秒内不出现比如 GC 触发的周期性停顿、连接表泄漏、超时清理逻辑把正常连接误杀这些都要跑到几分钟以上才会冒头。压测时把 CPU 占用一起看着如果单核长期跑满说明周期循环里的自旋比重太大减小余量或者改用异步等待。最后一条是验收的心态问题。我踩过最不值的一次坑是把一个只支持单连接的实现直接推给了现场理由是“实验室里一台组态软件连得好好的”。结果产线上线第一天工程师拿笔记本又连了一次做诊断两条连接直接互相顶掉整条线停了两小时。从那以后我每次交付前都强制走一遍“两个客户端同时连接 断开其中一个 另一个继续跑”的流程不管需求里写没写多客户端。上面这套对参数和压测的检查流程也是那之后固定下来的习惯。希望帮到你。本文还有配套的精品资源点击获取
