简介：面向IO适配器设备开发者的EtherNet/IP协议栈实现，聚焦与罗克韦尔自动化产品兼容的工业以太网通信场景，适合已具备一定C/C++或.NET基础、希望理解适配器侧连接建立与数据交换机制的开发者。压缩包共230个文件，约830KB，以167个HTML文档、20个头文件和15个C源文件为主，另含少量配置、图片与工程文件；其中源码覆盖连接管理、CIP IO连接、封装层、报文路由和网络处理等关键模块，HTML文档便于检索接口与实现说明。已有625人学习，可作为研究EtherNet/IP适配器通信流程、梳理协议栈分层结构和排查连接问题的参考材料，帮助读者从连接管理、报文封装到IO数据交互逐层理解实现思路。
1. 一块只会"被读被写"的 IO 板卡：这套 EtherNet/IP 适配器协议栈能顶什么活
有个做检测设备的团队找过我，说他们的控制板跑着 .NET 写的采集程序，客户却要求这块板子直接出现在 PLC 的扫描列表里，像普通远程 IO 一样被周期性读写 32 字节输入、16 字节输出，硬件不改、固件不重写。剩下的路只有一条：在 .NET 里跑一套 EtherNet/IP 适配器协议栈。这次拆的这份 EtherNet/IP stack c#.net 干的就是这件事——它实现的是 adapter（也叫 target、从站）角色，被动等扫描器来建会话、开连接、周期收发光 I/O 数据，而不是主动去轮询别人。
它适合三类人：手里有自研板卡或工控网关、需要被主流 PLC 直接识别成标准 IO 设备的嵌入式/上位机开发者；想给自家设备加一个 EtherNet/IP 接口但不想上专用芯片的团队；以及做产线数据采集、想搞明白"PLC 到底隔多久来读我一次"的工程师。读完这份代码，你会清楚一个 24 字节的封装头、一个 Forward Open 请求和一条 UDP 2222 上的序列号，怎么把一堆字节变成 PLC 眼里的"远程站"。
2. 分层与目录：从 TCP 44818 到 UDP 2222，四条通道各管什么
拿到这套代码第一件事不是看类名，而是把端口和报文类型对上线。EtherNet/IP 的适配器端一共开三个口：TCP 44818 走显式报文（建会话、读对象、传配置），UDP 44818 只用来应答广播的 ListIdentity 探测，UDP 2222 才是真正跑周期 I/O 的隐式报文通道。这三条路上的报文结构完全不同，混在一起写代码必翻车，所以工程里必须分层。
2.1 四层职责：封装层、CIP 层、连接管理、数据装配
最外面是封装层（Encapsulation），负责那 24 字节的头和 Command 分发。它只认七种命令：0x0063 ListServices、0x0064 ListIdentity、0x0065 ListInterfaces、0x0066 RegisterSession、0x0067 UnRegisterSession、0x006F SendRRData、0x0070 SendUnitData。适配器端真正要实现的其实只有 ListIdentity、RegisterSession、UnRegisterSession、SendRRData 四个，SendUnitData 在适配器侧基本不会收到。封装层不理解 CIP，它只负责"把一段 CIP 字节原样交上去、把应答原样封回去"。
往内一层是 CIP 报文层。一条 CIP 消息由服务码（1 字节）、请求路径长度（1 字节，单位是字）、路径和请求数据组成。路径用段编码：0x20 是 8 位类段、0x24 是 8 位实例段、0x2C 是 8 位连接点段。比如20 04 24 65 2C 64 2C 65读作"类 0x04（Assembly）、实例 0x65（101）、再带上配置实例 0x64 和连接点 0x65"。这套段编码是排查问题的第一手信息，PLC 报错时给的一般就是 general status，你得自己把它翻译回路径。
第三层是连接管理。RegisterSession 只解决"会话句柄"，真正让 I/O 跑起来的是 Forward Open：双方协商 T→O 和 O→T 两个方向的连接 ID、RPI（Requested Packet Interval，请求包间隔，单位微秒）、连接尺寸、超时倍率。协商完成后，扫描器就按 RPI 往 UDP 2222 上发数据，你必须在 RPI × timeout multiplier 的时间内回帧，否则它直接判定连接超时。
最内层是装配对象与数据映射。Assembly 实例（常见是输入 101、输出 100、配置 103）本质上就是几段字节数组，PLC 读的是inputBytes，写的是outputBytes。把这几个数组和你的业务变量绑起来，才是这套栈对你真正有价值的部分。我一般会把这一层单独抽出来，用接口或者委托暴露给业务代码，协议栈本身不碰任何业务字段。
提示：别把"Connection Manager 类 0x06"和"连接"这个词搞混。前者是一个 CIP 对象，Forward Open 是它的一个服务（0x54），跟 TCP 连接不是一回事。
2.2 目录结构与关键类
这套代码的目录基本是按上面四层切的，看懂目录就等于看懂了调用方向：
| 目录 | 关键类 | 职责 |
|---|---|---|
| Transport/ | TcpServer、UdpIoChannel、UdpIdentityChannel | 三个套接字的生命周期、收发循环、粘包拆包 |
| Encapsulation/ | EncapsulationHeader、EncapsulationDispatcher | 24 字节头解析、Command 分发、会话句柄管理 |
| Cip/ | CipMessage、CipPath、CipServiceCode | 服务码、路径段编解码、数据类型读写 |
| Connections/ | ExplicitSession、ForwardOpenService、ImplicitConnection | 会话状态机、Forward Open/Close、连接表 |
| Assemblies/ | AssemblyInstance、IoDataMap | 输入输出字节区、变更通知、超时心跳 |
| Device/ | DeviceIdentity、EdsLoader | 厂商号、设备类型、版本、EDS 参数 |
| Hosting/ | AdapterHost | 组装上面所有东西，一行启动 |
2.3 显式与隐式两条通道的分工
显式报文走 TCP 44818，封装命令是 SendRRData（0x006F），里面套一层 Common Packet Format：Item Count、Null Address Item（0x0000）、Unconnected Data Item（0x00B2）或者 Connected Data Item（0x00B1）。它是请求—应答模型，用来读 Identity、读 TCP/IP Interface、下发配置。优点是可靠、可带长数据；缺点是慢、有 TCP 握手和重传，绝不能拿它跑周期 I/O。
隐式报文走 UDP 2222，报文结构更简单：Interface Handle（4 字节）、Timeout（2 字节）、Item Count（2 字节），然后是两个 Item——0x00A1 Connected Address Item（里面就是 4 字节连接 ID）和 0x00B1 Connected Data Item（里面是 2 字节序列号 + 实际 I/O 数据）。没有校验、没有重传，丢了就丢了，靠的是周期性刷新。这条通道上还有两个血泪点：连接 ID 必须和 Forward Open 协商的值一致；序列号必须把你收到的那个值原样回填，而不是自己自增。
线程模型上，常见做法是 TCP 一个 Accept 循环加每会话一个读任务，UDP 2222 一个独立接收线程配一个发送定时器，UDP 44818 只在收到广播时回一帧。别把 I/O 收发塞进 TCP 的会话任务里——一旦某个显式请求卡住，隐式通道跟着停摆，PLC 那边立刻报连接超时。
3. 核心链路：一次 RegisterSession 到周期 I/O 的完整代码
链路是从上电广播开始的：扫描器先发 ListIdentity 找设备，再建 TCP 会话、RegisterSession，然后 Forward Open 谈好连接参数，最后切到 UDP 2222 开始周期性交换。下面按这个顺序拆四段关键代码，每一段都是必须自己写对的地方。
3.1 封装头与 RegisterSession：24 字节里的小端陷阱
// 24 字节封装头。注意：封装头所有多字节字段都是小端，跟 CIP 报文相反 public readonly record struct EncapsulationHeader( ushort Command, ushort Length, uint SessionHandle, uint Status, ulong SenderContext, uint Options) { public const int Size = 24; public static EncapsulationHeader Parse(ReadOnlySpan<byte> buf) { if (buf.Length < Size) throw new ArgumentException("报文不足 24 字节"); return new EncapsulationHeader( BinaryPrimitives.ReadUInt16LittleEndian(buf[..2]), // Command BinaryPrimitives.ReadUInt16LittleEndian(buf[2..4]), // Length，后面负载的长度 BinaryPrimitives.ReadUInt32LittleEndian(buf[4..8]), // Session Handle BinaryPrimitives.ReadUInt32LittleEndian(buf[8..12]), // Status，0 表示成功 BinaryPrimitives.ReadUInt64LittleEndian(buf[12..20]), // Sender Context，原样回填 BinaryPrimitives.ReadUInt32LittleEndian(buf[20..24]));// Options，固定 0 } public byte[] ToBytes() { /* 按上面的偏移量逆序写回，同样用小端 */ } }Sender Context 这 8 个字节没有任何语义，唯一要求是应答里原样带回去，扫描器靠它把请求和应答配对。Options 填 0。Status 在请求里是 0，应答里非 0 就代表出错，比如 0x00000001 表示"命令不支持"、0x00000064 表示"会话句柄无效"。
RegisterSession 的负载只有 4 个字节：协议版本（2 字节，填 1）和选项标志（2 字节，填 0）。应答的做法是把请求负载原样抄回去，同时在头里塞一个你自己生成的、非 0 的会话句柄，之后所有 SendRRData 都必须带着这个句柄，否则返回 0x64。会话要有空闲回收，我一般设 120 秒没动静就清掉，防止 PLC 侧异常掉线后句柄泄漏。
// RegisterSession 处理：负载 4 字节原样回显，头里换上新会话句柄 private byte[] OnRegisterSession(EncapsulationHeader req, ReadOnlySpan<byte> payload) { if (payload.Length < 4) return Error(req, 0x00000003); // 负载长度不对 var sessionId = _sessions.Create(); // 分配非 0 句柄 var body = payload[..4].ToArray(); // 版本 + 选项，原样回 return BuildResponse(0x0066, sessionId, body, req.SenderContext); }3.2 Forward Open：把 RPI、连接 ID、装配路径一次性谈好
Forward Open（服务码 0x54）发给 Connection Manager（类 0x06、实例 0x01），走 SendRRData。请求体里有几个字段是新手最容易写错的：两个方向的 Network Connection ID 在请求里由发起方给出，O→T 那个通常是扫描器分配的、你原样存下来即可；RPI 单位是微秒，1ms 要写 1000；Connection Size 是字节数，必须和 EDS 里声明的一致；Timeout Multiplier 决定超时时间 = RPI × multiplier。
// 构造 Forward Open 请求。CIP 部分全部大端，别用 BitConverter 直接怼 public static byte[] BuildForwardOpen(ForwardOpenArgs a) { var w = new CipWriter(); // 内部统一按大端写 w.U8(0x54); // 服务码 Forward Open w.U8(0x02); // 路径长度，2 个字 w.Path(0x20, 0x06, 0x24, 0x01); // 类 0x06 实例 0x01 = 连接管理器 w.U8(0x0A); // 优先级 + 时间刻度 w.U8(a.TimeoutTicks); // 超时 tick w.U32(a.OtoTConnectionId); // O→T 连接 ID w.U32(a.TtoOConnectionId); // T→O 连接 ID，首次填 0 w.U16(a.ConnectionSerial); // 连接序列号 w.U16(a.VendorId); // 你的厂商号，必须与 EDS 一致 w.U32(a.OriginatorSerial); w.U8(a.TimeoutMultiplier); // 超时倍率，一般 3 w.U32(a.OtoTRpi); // 微秒 w.U16(a.OtoTSize); // O→T 连接尺寸，字节 w.U32(a.TtoORpi); w.U16(a.TtoOSize); w.U8(0x01); // 传输类型：Class 1 w.U8(0x02); // 连接路径字数 w.Path(0x20, 0x04, 0x24, a.InputAssembly); // 类 0x04 + 输入实例号 return w.ToArray(); }应答里最需要盯的是 general status：0x00 成功；0x01 表示连接参数不匹配（尺寸或 RPI 对不上）；0x08 一般是路径解析失败，说明装配实例号写错或该实例不存在；0x1F 是资源不够，连接数打满了。协商成功后，把两个方向的连接 ID、RPI、尺寸全部落到连接表里，用连接 ID 做字典键——UDP 2222 上收到一帧时，你只能靠这 4 个字节判断它是哪条连接。
3.3 UDP 2222 上的隐式数据：序列号、心跳与超时
隐式通道的收帧逻辑短，但每个字节都有用。收到 0x00A1 拿到连接 ID，收到 0x00B1 拿到序列号和 I/O 数据。当 O→T 方向没有实际输出数据时，也要按 RPI 发空帧当心跳，否则扫描器那边计数不涨、判定连接超时，这是最常被忽略的一条。
// 隐式报文收发：收一帧业务数据，回一帧输入数据 private void OnImplicitFrame(ReadOnlySpan<byte> frame, IPEndPoint from) { var itemCount = BinaryPrimitives.ReadUInt16LittleEndian(frame[6..8]); uint connId = 0; ushort seq = 0; ReadOnlySpan<byte> data = default; var p = 8; for (var i = 0; i < itemCount; i++) { var type = BinaryPrimitives.ReadUInt16LittleEndian(frame[p..(p + 2)]); var len = BinaryPrimitives.ReadUInt16LittleEndian(frame[(p + 2)..(p + 4)]); var body = frame[(p + 4)..(p + 4 + len)]; if (type == 0x00A1) connId = BinaryPrimitives.ReadUInt32LittleEndian(body); // 连接 ID else if (type == 0x00B1) { seq = BinaryPrimitives.ReadUInt16LittleEndian(body); data = body[2..]; } p += 4 + len; } if (!_connections.TryGet(connId, out var conn)) return; // 未知连接直接丢 conn.LastSeen = Stopwatch.GetTimestamp(); // 喂狗 if (!data.IsEmpty) _map.WriteOutputs(data); // 业务写输出区 var reply = BuildUnitData(connId, seq, _map.ReadInputs()); // 序列号原样回填 _udpIo.Send(reply, from); // 回给同一来源 }超时判断放在独立的定时器里：每隔一个 RPI 检查Now - LastSeen，超过RPI × multiplier就把连接置为超时态，清掉输出区（很多设备要求超时后输出归零），并允许扫描器重新发起 Forward Open。连接 ID 用递增分配，但不要复用得太快，我一般要求至少间隔 0x1000，避免扫描器把新连接误认成老连接。
3.4 装配对象映射：把字节数组接到你的业务变量上
装配实例不要写成硬编码的 switch，用一个映射层，输入输出各注册一组"偏移 + 长度 + 读写委托"。这样换设备时只改配置，协议栈一行不动。
// 把 assembly 的字节区映射到业务量，偏移和长度来自 EDS 定义 public sealed class IoDataMap { private readonly byte[] _inputs = new byte[32]; // PLC 读到的 private readonly byte[] _outputs = new byte[16]; // PLC 写过来的 private readonly List<(int Offset, Func<short> Get)> _inputFields = new(); private readonly List<(int Offset, Action<short> Set)> _outputFields = new(); public void RegisterInput(int offset, Func<short> get) => _inputFields.Add((offset, get)); public ReadOnlySpan<byte> ReadInputs() { foreach (var f in _inputFields) BinaryPrimitives.WriteInt16BigEndian(_inputs.AsSpan(f.Offset), f.Get()); // CIP 侧大端 return _inputs; } public void WriteOutputs(ReadOnlySpan<byte> data) { data.CopyTo(_outputs); foreach (var f in _outputFields) f.Set(BinaryPrimitives.ReadInt16BigEndian(_outputs.AsSpan(f.Offset))); } }ReadInputs每次刷新时逐字段回写，成本可控（几十个字段量级）。注意 16 位有符号量在 CIP 侧是大端，如果你的业务变量来自小端设备（比如某类 ADC 直接吐的原始值），转换必须放在这一层，不能指望 PLC 那边帮你换。
3.5 ListIdentity：抓包软件第一眼看到的东西
扫描器上电第一件事是往 UDP 44818 发广播的 ListIdentity，谁答得快、答得对，谁就出现在可选设备列表里。应答是一个 Identity Item（类型 0x000C），里面装着厂商号、设备类型、产品码、版本、序列号和产品名。这些字段必须和 EDS 文件里声明的一模一样，差一个字节，PLC 就会认为"这不是我认识的那台设备"。
// ListIdentity 应答：字段必须与 EDS 完全一致，否则扫描器直接跳过 private byte[] BuildListIdentity() { var item = new List<byte>(); item.AddRange(new byte[] { 0x01, 0x00 }); // 封装协议版本 1，小端 item.AddRange(BuildSockAddr(_localEndPoint)); // 16 字节 sockaddr，网络序 item.AddRange(Le(_id.VendorId)); // 厂商号 item.AddRange(Le(_id.DeviceType)); // 设备类型，通信适配器一般 0x0C item.AddRange(Le(_id.ProductCode)); item.AddRange(Le(_id.MajorRev)); item.AddRange(Le(_id.MinorRev)); item.AddRange(Le(_id.Status)); item.AddRange(Le(_id.SerialNumber)); item.Add((byte)_id.ProductName.Length); // 产品名长度，1 字节 item.AddRange(Encoding.ASCII.GetBytes(_id.ProductName)); item.Add(0x03); // State var body = new List<byte>(); body.AddRange(Le((ushort)1)); // Item Count body.AddRange(Le((ushort)0x000C)); // Identity Item body.AddRange(Le((ushort)item.Count)); body.AddRange(item); return BuildResponse(0x0064, 0, body.ToArray(), 0); // 0x0064 = ListIdentity }这里三种端序同时出现：封装头小端、sockaddr 是网络序（大端）、产品名字符串按 ASCII 原样拼。写错一个，现象就是"抓包能看到有应答，但扫描器列表里空空如也"。
4. 跑起来：从网卡配置到 PLC 扫描列表里出现设备
代码能编译不等于设备能被认出来。这套栈的调试成本大部分花在环境上，而不是逻辑上，所以第一次跑建议按固定顺序来，别跳步。
4.1 环境、网卡与端口占用
运行时选 .NET 6 或 .NET 8 都行，Windows 和 Linux 都能跑，因为用的是原生 Socket，没有平台相关依赖。三个端口必须独占：TCP 44818、UDP 44818、UDP 2222。44818 不是特权端口，普通用户就能绑，不需要提权。
多网卡机器上必须显式绑定 IP，不能绑IPAddress.Any了事——广播的 ListIdentity 从哪块网卡回、源地址是什么，会直接影响扫描器认不认。我一般是在配置文件里写死设备侧网卡的 IP 和子网掩码，启动时校验这块网卡确实存在、且和 PLC 在同一网段。防火墙这一关经常被忽略：Windows 上默认策略会把入站 UDP 2222 直接丢掉，现象就是"能建连接但 I/O 永远不刷新"，排查半天以为是序列号写错。上线前先把三条规则放通，或者干脆在实验机上关掉防火墙。
# 启动前确认三个端口没有被别的进程占用 ss -lntup | grep -E '44818|2222'4.2 启动顺序与自检清单
启动顺序很重要：先起 UDP 44818（能应答 ListIdentity），再起 TCP 44818（能接受会话），最后起 UDP 2222（隐式通道）。反过来的话，扫描器可能在隐式通道就绪前就把连接建完了，然后因为收不到 I/O 帧而超时重连，日志里全是"连接已建立又断开"的噪声。
自检我固定跑四项：ListIdentity 广播能不能在 100ms 内应答；RegisterSession 拿到的句柄是否非 0；用显式报文读 Identity 对象（类 0x01 实例 0x01 属性 0x01~0x07）能不能正常返回；Forward Open 的应答 general status 是不是 0。这四项全绿再接 PLC，能省掉一大半现场沟通。
配置项建议单独抽一个类，别散在代码里：
| 配置项 | 典型值 | 说明 |
|---|---|---|
| VendorId | 自定义 | 必须与 EDS 一致，不能借用别人的 |
| DeviceType | 0x0C | 通信适配器 |
| InputAssembly | 101 | 输入实例号 |
| OutputAssembly | 100 | 输出实例号 |
| InputSize / OutputSize | 32 / 16 | 字节数，与 EDS 严格对应 |
| Rpi | 10000 | 微秒，即 10ms |
| TimeoutMultiplier | 3 | 超时 = RPI × 3 |
| MaxConnections | 8 | 连接表上限 |
4.3 EDS 文件：扫描器认不认你，一半靠它
EDS 是设备的"身份证"，扫描器读它来决定尺寸、连接参数和显示名。手工写容易漏字段，常见做法是用通用的 EDS 编辑器生成一份再改。核心段落无非 Identity、Assembly、Connection Manager 三块：
[Device] VendCode=1; VendName="Your Company"; ProdType=12; ProdTypeStr="Communications Adapter"; ProdCode=1; MajRev=1; MinRev=3; ProdName="Generic IO Adapter"; [Assembly] Assem1=32; ; 输入实例 101，32 字节 Assem2=16; ; 输出实例 100，16 字节 Assem3=0; ; 配置实例 103 [Connection Manager] Connection1=0x04000100, 0x04010064, 0x44010100, 0x012C, 0x1388, 0x0001;Connection1那一行长这样：第一个字段是 O→T 的连接参数（尺寸与类型），第二个是 T→O，第三个是配置连接，后面依次是 RPI、超时和连接数。改尺寸的时候，EDS、代码里的InputSize、装配实例的实际长度必须三处同步改，改一处不改另两处，Forward Open 一定返回 0x01。
4.4 单点验证：先确认对象树，再看 I/O 数据
接 PLC 之前，用一个最小脚本把设备扫出来，能省掉大量"到底是设备问题还是 PLC 组态问题"的争论。下面这段只依赖标准库，跑在任意能访问设备网段的机器上：
import socket, struct # 构造 ListIdentity 请求：24 字节头 + 空负载 req = struct.pack('<HHIIQI', 0x0064, 0, 0, 0, 0, 0) s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.settimeout(2.0) s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) s.sendto(req, ('255.255.255.255', 44818)) while True: data, addr = s.recvfrom(1024) # 谁回就说明谁在监听 44818 print(addr, data[:2].hex(), len(data))返回的 Command 应该是64 00（0x0064 的小端表示），长度一般在 60~120 字节之间。如果这里收不到东西，先别怀疑协议栈逻辑，去看网卡绑定和防火墙；如果收到了但 PLC 列表里没有，去比对 Identity 字段和 EDS。显式报文验证同理：读类 0x01 实例 0x01 属性 0x07（产品名），返回的字符串和 EDS 对不上，扫描器就会把设备标成"未知"。
5. 避坑排查：连接建不起来与 I/O 不刷新的现场记录
这套栈的坑有个特点：错误现象高度相似，原因却分散在端序、EDS、路径、时序四个地方。下面五条是我和同事实际踩过的，按"现象 → 原因 → 解决"记，遇到同类问题直接对照。
5.1 建链阶段：设备不出现、会话被秒关
现象一：抓包能看到设备回复了 ListIdentity，但扫描器设备列表里始终是空的。原因基本是 Identity 字段和 EDS 不一致。最常见的具体差异是 MajRev/MinRev（代码里是 1.3，EDS 里写的 1.1）、ProductCode，或者 ProductName 长度字节算错导致后面整段偏移。解决方法是把 EDS 的 Identity 段和BuildListIdentity的字段逐项对照，尤其是产品名：长度是 1 字节，超过 32 个字符有些扫描器会直接截断或丢弃。改完记得清一次扫描器的设备缓存，很多工具会缓存上次探测结果。
现象二：TCP 能连上，RegisterSession 一发就断，或者后续请求全部返回状态 0x64。原因只有两个：封装头的端序写反了，或者会话句柄没带对。前者表现为 Length 字段解析成天文数字，服务端读负载时直接越界；后者是自己生成的句柄和应答里返回的不一致。解决办法是把封装头的所有多字节字段统一改成小端读写，并且会话句柄用单调递增的正整数，请求进来先校验句柄是否存在、是否过期。这一条我吃过亏：调试时用BitConverter图省事，在小端机器上跑得好好的，换台大端环境（或者用了大端序列化的库）全线崩。
现象三：Forward Open 返回 general status 0x01 或 0x08。0x01 是连接参数不匹配，九成是 Connection Size 和 EDS 声明的不一致，或者 RPI 小于设备支持的下限（有些实现硬性要求 ≥ 5ms）。0x08 是路径解析失败，去检查连接路径里的装配实例号——20 04 24 65是输入实例 101，如果你的代码里写的是十进制 101 但序列化成了 0x65 以外的值，或者实例根本没注册到对象表里，都会报这个。解决办法是把连接路径打印成十六进制，和 EDS 里的 Assem 编号对齐，并在对象表里对所有声明的实例做启动自检。
5.2 运行阶段：连接建好了但数据不对
现象四：连接状态正常，PLC 侧却周期性报"连接超时"，I/O 数据一直是初始值。原因是 O→T 方向没有按 RPI 发心跳。很多实现只在有输出数据变化时才发包，而扫描器的看门狗是按固定周期计数的，几个 RPI 收不到帧就判超时。解决办法是起一个周期定时器，无条件下发，没有业务数据就发纯序列号的空帧。顺带检查超时倍率：默认 3 意味着 3 个 RPI 没收到就断，10ms 的 RPI 只有 30ms 窗口，调度抖动大一点就够呛，实验阶段可以临时调到 8 观察。
现象五：数据能刷，但数值明显错位，或者高低字节反了。原因通常不是端序，而是装配定义和业务映射的偏移对不上。比如 EDS 里第一个字段是 4 字节的浮点温度，代码里却按 2 字节整型从偏移 0 开始读，后面所有字段整体错位。另一种情况是业务侧变量本身是 16 位有符号，CIP 侧要求大端，映射层却直接Buffer.BlockCopy拷过去，PLC 读出来就是反的。解决办法是把偏移表单独维护成一份配置（偏移、类型、长度、方向），代码按表生成读写委托，改设备只改表；上线前用一组已知值（比如写 0x0102 读回来验证字节序）做一次对拍。
把这些坑归到一句话：端序、路径、时序，三样只要有一样错，现象都是"连不上"或"数据不对"，而错误码给的信息量极小。所以日志一定要把收发的原始十六进制打出来，别只打"连接失败"。这套代码里我后来加了一个可开关的报文日志，抓一次完整的建链过程存成文件，比现场猜半小时有用得多。
6. 二次开发：把通用协议栈捏成你自己的设备
这套栈的设计意图很明显：协议部分保持通用，设备特性全部外置。真要改成自己的产品，改动集中在四个点。
| 改造点 | 位置 | 注意 |
|---|---|---|
| 身份信息 | DeviceIdentity+ EDS | 厂商号、产品码、版本三处同步，改完清扫描器缓存 |
| 装配尺寸 | IoDataMap+ EDS[Assembly] | 尺寸变了，Forward Open 的 Size 字段跟着变 |
| 连接数上限 | ConnectionTable | 上限受内存和 CPU 影响，超过 16 条要重新压测 |
| 业务映射 | RegisterInput/RegisterOutput | 偏移表外置成配置，别写死在代码里 |
最省事的扩展方式是把 I/O 映射做成接口，让协议栈只认IIoSource：
// 业务侧只需要实现这个接口，协议栈不关心数据从哪来 public interface IIoSource { int InputSize { get; } // 必须等于 EDS 声明的输入尺寸 int OutputSize { get; } void Fill(Span<byte> input); // 每周期调用，写 PLC 要读的数据 void Apply(ReadOnlySpan<byte> output); // PLC 写过来的数据落到业务层 } // 启动时一行接入，换设备只换实现类 var host = new AdapterHost(new DeviceIdentity(vendorId: 1, deviceType: 0x0C, /* ... */)); host.UseIoSource(new MyValveBankIoSource()); await host.RunAsync();验证方法我固定三步：先用显式报文读回装配实例，确认字节数和内容符合预期；再用抓包看 O→T 帧的间隔是不是稳定在 RPI 附近（抖动超过 50% 就要查调度）；最后做一次断线重连压测——把网线拔掉 10 秒再插回，确认连接表能自动清理、扫描器能重新建链，且连接 ID 没有复用。第三步最容易暴露问题，我见过连接表只加不删、跑一天后新连接全部报 0x1F 的实现。
从那以后我每次改装配尺寸或者 EDS，都强制走一遍"改配置 → 清缓存 → 重扫 → 读回比对"这条流程，绝不允许自己"只改代码不改 EDS"直接上现场。协议栈这类东西，错一个字节和错一百个字节的现象是一样的，靠肉眼看不出来，只能靠固定流程卡住。希望帮到你。
本文还有配套的精品资源，点击获取
