C#/.NET EtherNet/IP 从站协议栈实战：IO 适配器开发与避坑指南

简介：面向工业自动化开发者的 EtherNet/IP 协议栈实现资料，基于 C#.NET 编写，专为 IO 适配器设备设计，可用于构建与罗克韦尔（Rockwell）自动化产品兼容的通信方案。内容围绕连接管理器、数据链路层、网络层、应用层及 C#.NET API 展开，覆盖连接建立与维护、数据收发、设备状态管理等核心环节，并涉及 CIP 规范理解、设备发现、错误处理与性能优化等实践要点。压缩包共 230 个文件，以 html 文档、C 源码与头文件为主，辅以 png 图示、css/js 静态资源及 eds 设备描述、pdf 说明、makefile 构建脚本等，整体约 830KB，便于查阅实现细节与接口说明。已有 625 人学习关注，适合需要将 EtherNet/IP 功能集成进自有应用、提升设备互操作性的中高级开发者参考。

1. 从一台 IO 从站设备说起：这套 EtherNet/IP 协议栈到底解决什么问题

产线上有一台分布式 IO 从站，上面挂着十几个数字量输入输出点，上位是一台罗克韦尔的 PLC。设备硬件已经调通，指示灯能亮，串口能通，唯独 PLC 那边扫不到节点——问题往往不在硬件，而在协议栈。工业现场里，IO 从站设备要接入 EtherNet/IP 网络，必须实现一套完整的 CIP 对象模型、显式报文与隐式报文（I/O 连接）处理逻辑，还要能通过 EDS 文件被组态工具识别。这套基于 C#/.NET 的 EtherNet/IP 协议栈，瞄准的就是这个场景：让做 IO 适配器（Adapter，也就是从站）的开发者不用从字节序开始啃规范，直接在一个可运行的协议栈骨架上做设备适配。

它适合两类人：一类是做嵌入式网关、远程 IO 模块、协议转换器的固件/上位机开发者，需要在 .NET 环境里快速把从站侧协议跑通；另一类是已经有一台设备、想让它被主流 PLC 组态软件识别并交换周期性 I/O 数据的工程师。下面按「能干什么 → 怎么跑 → 怎么改」的顺序拆开讲。

2. 协议栈架构拆解：从 TCP 显式报文到 UDP 隐式 I/O 的两条链路

EtherNet/IP 的本质是 CIP 协议跑在 TCP 和 UDP 之上，分成两条完全不同的链路。显式报文走 TCP 44818 端口，用来做对象读写、设备发现、连接建立；隐式报文走 UDP 2222 端口，用来做周期性 I/O 数据交换。这套 C# 协议栈的架构就是围绕这两条链路组织的，理解了这个分层，后面看代码才不会迷路。

2.1 分层结构与目录组织

一个典型的 .NET 版 EtherNet/IP 从站协议栈，目录大致会分成这么几层：

EtherNetIP.Stack/ ├── Transport/ # 传输层：TCP/UDP 监听与收发 │ ├── TcpListenerService.cs │ └── UdpIoService.cs ├── Encapsulation/ # 封装层：命令字、会话、报文头 │ ├── EncapsulationHeader.cs │ └── CommandHandlers/ ├── Cip/ # CIP 层：路径解析、服务分发 │ ├── CipPath.cs │ ├── CipService.cs │ └── MessageRouter.cs ├── Objects/ # 对象模型：标识、消息路由、汇编、连接管理 │ ├── IdentityObject.cs │ ├── MessageRouterObject.cs │ ├── AssemblyObject.cs │ ├── ConnectionManagerObject.cs │ └── TcpIpInterfaceObject.cs ├── Io/ # I/O 连接：生产/消费、RPI 定时 │ ├── IoConnection.cs │ └── IoProducer.cs └── Device/ # 设备适配层：用户真正要改的地方 ├── DeviceProfile.cs └── EdsGenerator.cs

这个划分不是随便摆的。Transport 层只关心字节进出，Encapsulation 层负责解析 24 字节封装头（命令、长度、会话句柄、状态码），Cip 层处理路径段和服务码，Objects 层是 CIP 对象模型的落地，Io 层管周期性数据，Device 层是留给设备厂商填自己 IO 点表的地方。分层的好处是：改设备只需要动 Device 和 AssemblyObject，协议细节不用碰。

提示：不同实现里目录名会有出入，但「传输 / 封装 / CIP / 对象 / IO / 设备」这六层职责基本是固定的，看任何一份 EtherNet/IP 从站代码都可以按这个骨架去对号入座。

2.2 封装层：24 字节报文头是所有交互的入口

所有 EtherNet/IP 报文，不管是 TCP 还是 UDP，开头都是 24 字节的封装头。协议栈里通常有一个结构体或类专门处理它，字段顺序和字节序必须严格对齐：

// EncapsulationHeader.cs public class EncapsulationHeader { public ushort Command; // 命令字：0x0065 RegisterSession, 0x0066 UnRegister, 0x0070 SendRRData, 0x0072 SendUnitData public ushort Length; // 后续数据长度 public uint SessionHandle; // 会话句柄，RegisterSession 后由从站分配 public uint Status; // 状态码，0 表示成功 public ulong SenderContext; // 发送方上下文，原样回传 public uint Options; // 选项，通常为 0 public const int Size = 24; public static EncapsulationHeader Parse(byte[] buffer, int offset) { // EtherNet/IP 全部使用小端序，BitConverter 在 x86/x64 上默认即小端 return new EncapsulationHeader { Command = BitConverter.ToUInt16(buffer, offset), Length = BitConverter.ToUInt16(buffer, offset + 2), SessionHandle = BitConverter.ToUInt32(buffer, offset + 4), Status = BitConverter.ToUInt32(buffer, offset + 8), SenderContext = BitConverter.ToUInt64(buffer, offset + 12), Options = BitConverter.ToUInt32(buffer, offset + 20) }; } public byte[] ToBytes() { var buf = new byte[Size]; BitConverter.GetBytes(Command).CopyTo(buf, 0); BitConverter.GetBytes(Length).CopyTo(buf, 2); BitConverter.GetBytes(SessionHandle).CopyTo(buf, 4); BitConverter.GetBytes(Status).CopyTo(buf, 8); BitConverter.GetBytes(SenderContext).CopyTo(buf, 12); BitConverter.GetBytes(Options).CopyTo(buf, 20); return buf; } }

这里有几个参数值得说清楚。Command决定这条报文要干什么，从站最常处理的是0x0065（RegisterSession，PLC 建会话）、0x0070（SendRRData，显式报文）、0x0072（SendUnitData，隐式连接数据）。SessionHandle在 RegisterSession 之前是 0，从站回复时分配一个非零值，之后 PLC 每条报文都带着它，从站要校验，不匹配就返回 0x64 错误。SenderContext是 8 字节，从站不需要理解内容，原样回填即可，很多实现翻车就翻在忘了回填这 8 个字节，导致组态工具认为响应非法。

Length字段只算封装头之后的数据长度，不含这 24 字节本身。解析时如果按「总长 = Length + 24」去读 socket，遇到粘包要自己维护缓冲区，这一点在 2.3 节会展开。

2.3 显式报文链路：RegisterSession 到 SendRRData 的完整处理

PLC 连上来的第一步永远是 RegisterSession。从站收到0x0065后，分配会话句柄，回一个 Status=0 的响应。之后 PLC 用0x0070SendRRData 发 CIP 请求，里面包着 CPF（Common Packet Format）数据项，再里面才是 CIP 服务码和路径。

// CommandHandlers/RegisterSessionHandler.cs public byte[] Handle(EncapsulationHeader header, byte[] payload) { // payload 前 4 字节是协议版本，后 2 字节是选项标志，一般忽略 uint sessionId = _sessionManager.CreateSession(); var resp = new EncapsulationHeader { Command = 0x0065, Length = 4, // 回 4 字节：协议版本 + 选项 SessionHandle = sessionId, Status = 0, SenderContext = header.SenderContext, // 必须原样回填 Options = 0 }; var body = new byte[4]; BitConverter.GetBytes((ushort)1).CopyTo(body, 0); // 协议版本 1 BitConverter.GetBytes((ushort)0).CopyTo(body, 2); // 选项 0 return resp.ToBytes().Concat(body).ToArray(); }

SendRRData 的处理要复杂一层，因为它带 CPF 结构。CPF 里通常有两个数据项：一个是 Null Address Item（0x0000），一个是 Unconnected Data Item（0x00B2）或 Connected Data Item（0x00B1）。真正的 CIP 报文在第二个数据项里。解析顺序是：封装头 → 接口句柄（4 字节）→ 超时（2 字节）→ 数据项数量（2 字节）→ 逐项解析（类型 2 字节 + 长度 2 字节 + 数据）。

// Cip/MessageRouter.cs public byte[] RouteCipRequest(byte[] cipData) { // cipData[0] 是服务码，cipData[1] 是路径长度（字数） byte service = cipData[0]; int pathWords = cipData[1]; int pathOffset = 2; int pathBytes = pathWords * 2; var path = CipPath.Parse(cipData, pathOffset, pathBytes); // path 形如 [0x20,0x01,0x24,0x01]：类 0x01、实例 0x01 var target = _objectRegistry.Resolve(path.ClassId, path.InstanceId); if (target == null) return BuildError(service, 0x05); // 0x05 = 路径目标不存在 return target.HandleService(service, cipData, pathOffset + pathBytes); }

CipPath.Parse要处理逻辑段（0x20 类、0x24 实例、0x25 属性、0x28 成员）和端口段，还要处理 8 位/16 位/32 位不同长度的段。这里最容易出错的是路径长度的单位——规范里路径长度字段的单位是「字」（2 字节），不是字节，少乘 2 就会把路径截断，表现为 PLC 报「对象不存在」，但对象明明注册了。

2.4 隐式 I/O 链路：RPI 定时与生产消费模型

显式报文跑通只说明设备能被识别，真正干活的隐式 I/O 连接是另一套逻辑。PLC 通过 ForwardOpen（服务码 0x54）建立连接，协商 RPI（Requested Packet Interval，请求包间隔）、连接尺寸、生产/消费方向。从站要按 RPI 周期性地把输入数据通过 UDP 2222 发出去，同时接收 PLC 发来的输出数据。

// Io/IoProducer.cs public class IoProducer { private readonly UdpClient _udp; private readonly IoConnection _conn; private Timer _timer; public void Start() { // RPI 单位是微秒，这里换算成毫秒；实际发送周期一般取 RPI 的 1/2 到 1 倍 int periodMs = Math.Max(1, (int)(_conn.RpiMicroseconds / 1000)); _timer = new Timer(_ => Produce(), null, 0, periodMs); } private void Produce() { // 从 Assembly 对象取输入数据，组装成 CPF + 序列号 + 数据 byte[] inputData = _conn.InputAssembly.GetData(); byte[] packet = BuildConnectedDataPacket(_conn.OtoTConnectionId, inputData); _udp.Send(packet, packet.Length, _conn.RemoteEndPoint); } }

RpiMicroseconds是 ForwardOpen 里协商出来的值，常见 5ms 到 20ms。发送周期如果严格等于 RPI，网络抖动时容易丢包；我一般会取 RPI 的一半作为定时器周期，让数据稍微「提前」一点，PLC 侧的超时判定更宽松。OtoTConnectionId是 Originator to Target 的连接 ID，由从站在 ForwardOpen 响应里分配，PLC 发来的数据带着 TtoO 连接 ID，从站要校验，不匹配直接丢弃。

Assembly 对象是 I/O 数据的容器，输入汇编（通常是实例 0x64）和输出汇编（实例 0x65）的字节布局必须和 EDS 文件里声明的一致，否则 PLC 组态时尺寸对不上，连接建立会失败。这块在 3.2 节讲 EDS 时会再提。

3. 把协议栈跑起来：环境、配置与第一个会话

协议栈能不能跑，关键不在代码多复杂，而在几个硬性条件是否满足：端口有没有被占、网卡选对没有、EDS 文件格式对不对。这一章按实际启动顺序走一遍。

3.1 运行环境与依赖准备

这套栈是纯 .NET 实现，没有原生依赖，理论上 .NET 6/7/8 都能跑。实际项目里我倾向用 .NET 8 的 LTS，长期维护省心。需要确认的几件事：

启动前先确认端口没被别的进程占用。Windows 上用netstat -ano | findstr 44818，Linux 上用ss -lntup | grep 44818。如果之前跑过别的 EtherNet/IP 工具没退干净，44818 会被占着，新进程绑定直接抛异常，现象是「程序启动即退出」，日志里只有一行 SocketException，很容易误判成代码问题。

# 克隆后还原依赖并编译 dotnet restore dotnet build -c Release # 运行（示例入口，实际以项目 csproj 为准） dotnet run --project src/EtherNetIP.Adapter.Host

配置文件里通常要指定绑定网卡、设备身份信息（厂商 ID、设备类型、产品代码、版本号）。这些值不是随便填的，它们会出现在 Identity 对象里，PLC 组态时读的就是这些字段，填错会导致设备能连上但被识别成未知设备。

{ "Network": { "BindAddress": "192.168.1.10", "TcpPort": 44818, "UdpPort": 2222 }, "Identity": { "VendorId": 1, "DeviceType": 12, "ProductCode": 100, "Revision": "1.001", "ProductName": "Generic IO Adapter" } }

DeviceType为 12 表示通信适配器，做 IO 从站一般用这个值；VendorId在正式产品里要向标准组织申请，做实验可以先用 1。Revision是主次版本拼接，格式要和 EDS 文件里的MajRev/MinRev对应。

3.2 EDS 文件：设备被组态工具识别的通行证

PLC 组态软件不认识你的代码，它只认 EDS 文件。EDS 是一个 INI 格式的文本文件，描述设备的身份、连接参数、I/O 数据尺寸。协议栈里一般带一个生成器，根据 DeviceProfile 自动产出。

[Device] VendCode = 1; VendName = "Generic Vendor"; ProdType = 12; ProdTypeStr = "Communications Adapter"; ProdCode = 100; MajRev = 1; MinRev = 1; ProdName = "Generic IO Adapter"; [Assembly] Assem100 = 0x04, 16, 0x0000; # 输入汇编，16 字节 Assem101 = 0x04, 8, 0x0000; # 输出汇编，8 字节 [Connection Manager] Connection1 = 0x04010000, 0x01000000, 16, 8, 500, 1, 0x4400, 0x4400;

Assem100那行里，0x04表示输入方向，16是字节数，必须和 AssemblyObject 里实例 0x64 的实际长度一致。Connection1里的500是 RPI 默认值（单位 ms 的十分之一，即 50ms），两个0x4400是连接参数。EDS 里任何一处尺寸和代码里的 Assembly 长度对不上，组态工具要么拒绝导入，要么导入后连接建立失败，报「连接尺寸不匹配」。

注意：EDS 文件编码要用 ANSI 或带 BOM 的 UTF-8，纯 UTF-8 无 BOM 在某些组态工具里会读成乱码，表现为设备名显示为问号。这个坑很隐蔽，因为文件本身用文本编辑器打开完全正常。

3.3 用测试客户端验证第一个会话

设备跑起来后，别急着上 PLC，先用一个简单的 TCP 客户端验证 RegisterSession 和一次显式读。这样能把「协议栈问题」和「PLC 组态问题」分开，省很多时间。

// 最小验证：发 RegisterSession，读回会话句柄 using var client = new TcpClient("192.168.1.10", 44818); using var stream = client.GetStream(); var header = new byte[24]; BitConverter.GetBytes((ushort)0x0065).CopyTo(header, 0); // RegisterSession BitConverter.GetBytes((ushort)4).CopyTo(header, 2); // 后续 4 字节 BitConverter.GetBytes((uint)0).CopyTo(header, 4); // 会话句柄先填 0 BitConverter.GetBytes((ulong)0x1122334455667788).CopyTo(header, 12); // 上下文 var body = new byte[] { 0x01, 0x00, 0x00, 0x00 }; // 版本 1，选项 0 stream.Write(header.Concat(body).ToArray()); var resp = new byte[28]; int read = 0; while (read < 28) read += stream.Read(resp, read, 28 - read); uint session = BitConverter.ToUInt32(resp, 4); Console.WriteLine($"SessionHandle = 0x{session:X8}");

如果这一步能拿到非零会话句柄，说明封装层和 TCP 监听是通的。接下来再发 SendRRData 读 Identity 对象的属性 1（厂商 ID），路径是[0x20,0x01,0x24,0x01,0x30,0x01]，服务码 0x0E（GetAttributeSingle）。能读回配置里的 VendorId，就说明 CIP 路由和对象模型也通了。这两步过了，再上 PLC 组态，问题范围就缩小到 EDS 和连接参数上了。

4. 核心对象与 I/O 数据映射：改设备时到底动哪几个文件

协议栈跑通只是起点，真正的工作量在「把设备的 IO 点映射进 Assembly 对象」。这一章讲清楚对象模型里哪几个是必须实现的、数据怎么映射、以及改设备时的最小改动面。

4.1 必须实现的四个 CIP 对象

CIP 对象模型里有几十个对象，但从站设备必须实现的核心对象其实就四个，缺一个 PLC 就认不全：

另外 TCP/IP Interface（0x05）和 Ethernet Link（0x0F）虽然不是所有场景都强制，但组态工具通常会读，缺了会报「对象不支持」，建议一并实现。Identity 对象的属性 1 到 7 分别是厂商 ID、设备类型、产品代码、版本、状态、序列号、产品名，这些值全部来自配置文件，改设备信息就是改配置，不用动代码。

Message Router 对象本身不存数据，它的作用是接收显式报文并按路径分发，2.3 节的RouteCipRequest就是它的核心逻辑。Connection Manager 负责处理 ForwardOpen/ForwardClose，分配连接 ID，把连接参数（RPI、尺寸、方向）传给 IoConnection。

4.2 Assembly 对象与 IO 点映射

Assembly 对象是设备和 PLC 之间交换数据的实际载体。输入汇编（实例 0x64）放从站采集到的数据，输出汇编（实例 0x65）放 PLC 下发的数据。映射逻辑通常放在 Device 层，把物理 IO 点按位或按字节填进一个 byte 数组。

// Device/DeviceProfile.cs public class DeviceProfile { // 输入：16 字节，前 2 字节是 16 路数字量输入，其余预留 private readonly byte[] _inputAssembly = new byte[16]; // 输出：8 字节，前 2 字节是 16 路数字量输出 private readonly byte[] _outputAssembly = new byte[8]; public void UpdateInputs(bool[] diPoints) { Array.Clear(_inputAssembly, 0, 2); for (int i = 0; i < diPoints.Length && i < 16; i++) { if (diPoints[i]) _inputAssembly[i / 8] |= (byte)(1 << (i % 8)); // 按位打包，低位在前 } } public bool[] GetOutputs() { var result = new bool[16]; for (int i = 0; i < 16; i++) result[i] = (_outputAssembly[i / 8] & (1 << (i % 8))) != 0; return result; } }

位序是这里的关键。CIP 的位打包没有强制规定「低位在前」还是「高位在前」，但主流 PLC 组态默认按低位在前解释，也就是第 0 个点对应字节的 bit0。如果设备侧按高位在前打包，PLC 上看到的点位顺序会整体反过来，现象是「输入 1 触发时 PLC 显示输入 8」，排查时容易怀疑硬件，其实是位序问题。改法就是上面代码里的1 << (i % 8)，如果硬件要求高位在前，改成1 << (7 - i % 8)。

_inputAssembly的长度必须和 EDS 里Assem100声明的字节数一致，_outputAssembly同理对应Assem101。改 IO 点数时，这三个地方（代码数组长度、EDS 声明、Connection1 里的尺寸参数）要同步改，漏一个就连不上。

4.3 ForwardOpen 处理与连接参数协商

ForwardOpen 是隐式连接建立的核心，PLC 发来服务码 0x54，里面带着连接三元组、RPI、连接尺寸、连接 ID。从站要解析这些参数，分配自己的连接 ID，回一个 ForwardOpen 成功响应。

// Objects/ConnectionManagerObject.cs public byte[] HandleForwardOpen(byte[] request) { // 跳过服务码和路径，定位到连接参数区 int offset = 2 + request[1] * 2; uint otoTConnectionId = BitConverter.ToUInt32(request, offset + 8); uint ttoOConnectionId = _connectionIdPool.Allocate(); // 从站分配 ushort rpiTicks = BitConverter.ToUInt16(request, offset + 12); int rpiUs = rpiTicks * 1000; // 单位换算，具体系数依实现 var conn = new IoConnection { OtoTConnectionId = otoTConnectionId, TtoOConnectionId = ttoOConnectionId, RpiMicroseconds = rpiUs, InputAssembly = _assemblyRegistry.Get(0x64), OutputAssembly = _assemblyRegistry.Get(0x65) }; _ioService.Register(conn); return BuildForwardOpenSuccess(ttoOConnectionId, otoTConnectionId); }

otoTConnectionId是 PLC 分配的，从站回显；ttoOConnectionId是从站分配的，PLC 后续发数据时带着它。两个 ID 方向不能搞反，搞反了 PLC 会认为收到未知连接的数据包，直接丢弃，现象是「连接建立了但 I/O 数据不更新」。rpiTicks的单位换算各实现略有差异，有的按 1 tick = 1ms，有的按 1 tick = 1us，要以实际抓包对过为准，这个值错了会导致发送频率差几个数量级。

5. 避坑与排查：现场最容易翻车的五个点

协议栈这东西，代码写对了不代表现场能跑，网络环境、组态工具、时序都会给你上课。下面五条是实际调试里反复出现的，按「现象 → 原因 → 解决」记下来。

5.1 现象：PLC 能 Ping 通但扫不到设备

原因通常是 UDP 2222 没绑定成功，或者绑定在了错误的网卡上。EtherNet/IP 的设备发现（ListIdentity）走的是 UDP 广播，从站要在 2222 端口监听广播包并回复。多网卡机器上如果绑定了0.0.0.0，某些系统会把广播包路由到错误的接口。

解决：显式绑定到与 PLC 同网段的那个 IP，并在 socket 上设置ReuseAddress。Linux 下还要确认防火墙没拦 UDP 2222，iptables -L -n看一眼。

5.2 现象：RegisterSession 成功，但读 Identity 返回 0x05

0x05 是「路径目标不存在」。最常见的原因是路径长度字段按字节算了而不是按字算，导致路径被截断，解析出来的类 ID 是错的。另一个原因是对象注册表里类 ID 用了十进制 1 而不是 0x01，虽然值一样，但如果注册时按字符串匹配就会对不上。

解决：在CipPath.Parse里打日志，把解析出的 ClassId/InstanceId 打出来，和请求里的原始字节对比。路径[0x20,0x01,0x24,0x01]解析出来必须是 Class=1、Instance=1。

5.3 现象：I/O 连接建立后数据不更新

先查连接 ID 方向有没有搞反（见 4.3 节）。如果 ID 没问题，再看 RPI 定时器是不是根本没启动——有些实现在 ForwardOpen 响应发出后才启动定时器，但 PLC 在收到响应前就开始发数据了，这中间有个窗口期，从站如果对未注册连接的数据包直接丢弃，看起来就像「连上了但没数据」。

解决：在 ForwardOpen 处理里先注册连接再回响应，定时器在注册时立即启动一次。另外确认 UDP 接收缓冲区够大，RPI 很小时数据包密集，缓冲区小了会丢包。

5.4 现象：EDS 导入后设备显示为黄色问号

组态工具读 EDS 时校验VendCode、ProdType、ProdCode和 Identity 对象返回的值是否一致。任何一项对不上，设备就显示为未识别。常见的是 EDS 里MajRev/MinRev和 Identity 的 Revision 格式不一致，比如 EDS 写1和1，代码里返回的却是1.001解析出的0x0101。

解决：把 Identity 对象实际返回的四个字段抓包打出来，逐项和 EDS 对照。Revision 在 Identity 里是两个字节，主版本高字节、次版本低字节，EDS 里是分开的两个字段，换算关系要写对。

5.5 现象：跑一段时间后连接断开，重连失败

多半是会话或连接 ID 泄漏。RegisterSession 分配的会话句柄没有超时回收，PLC 异常断开后句柄一直占着，重连时分配新句柄但旧连接还在发数据，资源越积越多。连接 ID 池同理，ForwardClose 没正确处理就回收不了。

解决：给会话加超时清理（比如 60 秒无报文就回收），ForwardClose 里显式释放连接 ID 并停掉对应的定时器。这块建议加个连接数上限和日志，出问题时能看出是哪个环节没释放。

6. 二次开发：把通用栈改成你自己的设备

拿到这套栈之后，绝大多数人的第一件事是「把我的 IO 点表塞进去」。改动面其实很小，集中在 Device 层和三个同步点，但顺序错了会反复返工。我一般按下面的顺序改，改完用一套固定流程验证。

6.1 改造的最小改动面

先定 IO 点表：多少路输入、多少路输出、有没有模拟量。然后同步改三处——DeviceProfile里的数组长度和映射逻辑、EDS 生成器里的Assem100/Assem101尺寸、Connection1里的连接尺寸参数。这三处是强耦合的，建议写个单元测试，断言「数组长度 == EDS 声明长度 == 连接参数长度」，改一处跑一次，比现场调试快得多。

如果设备有模拟量，注意字节序。CIP 里 16 位模拟量一般按小端存放，但有些 PLC 组态按大端解释，需要在映射时做字节交换。这个没有统一答案，以实际 PLC 读到的值为准，抓一次包对比原始字节和 PLC 显示值就能确定。

6.2 验证流程：从单元测试到抓包

我习惯的验证顺序是：先跑单元测试确认路径解析和对象路由，再用 3.3 节的测试客户端验证 RegisterSession 和 Identity 读，然后上组态工具导入 EDS 建连接，最后用抓包工具看 I/O 数据包的周期和内容。抓包这一步别省，很多「PLC 显示数据不对」的问题，抓包一看就是字节序或位序，比在代码里猜快十倍。

// 一个最小的映射测试，改完 IO 点表先跑这个 [Fact] public void InputMapping_BitOrder_MatchesPlcExpectation() { var profile = new DeviceProfile(); var points = new bool[16]; points[0] = true; // 只触发第 0 路 profile.UpdateInputs(points); var assembly = profile.GetInputAssembly(); Assert.Equal(0x01, assembly[0]); // 低位在前：bit0 = 1 Assert.Equal(0x00, assembly[1]); }

这个测试看着简单，但它把「位序」这个最容易翻车的点钉死了。以后任何人改映射逻辑，跑一下就知道有没有破坏约定。

6.3 一个容易忽略的扩展点：ListIdentity 响应

设备发现阶段，组态工具会发 ListIdentity（命令 0x0063）广播，从站要回一个包含 Identity 信息和网络参数的响应。很多实现只处理了单播，广播包没回，导致工具里「扫描网络」扫不到设备，但手动输 IP 能连上。扩展的时候记得在 UDP 服务里判断目标地址是不是广播地址，是的话也走一遍 ListIdentity 处理。

提示：ListIdentity 响应里的 socket 地址字段要填从站自己的 IP 和 44818 端口，填错了工具会去连一个不存在的地址，表现为「扫描到了但连不上」。

从那以后我每次改完 IO 映射，都强制先跑一遍映射单元测试再上设备，抓包确认位序和周期没问题才交给组态。这套流程救过我好几次，尤其是改点数的时候，三处同步漏一处，测试会直接告诉你。希望帮到你。

本文还有配套的精品资源，点击获取