简介面向工业自动化现场开发者的C#欧姆龙PLC通信学习示例以FINS over TCP/IP协议为基础完整覆盖从建立网络连接、构造请求帧、发送指令到解析响应数据的流程。资源内包含可直接运行的Windows窗体工程以及9个C Sharp源文件分别演示连接建立、数据读取、写入操作、响应解析等典型场景另有通讯手册、协议格式图、网络调试助手和教学课件适合初中级工程师快速掌握欧姆龙PLC以太网通信方法。压缩包共四十五个文件整体仅四兆多除源代码外还提供了应用截图、配置资源、说明文档、可执行调试工具等目录结构明确便于按模块查阅。目前已有1117人学习下载配合直播素材与代码讲解可辅助理解FINS帧头、命令代码、地址分配、数据区读写、异常处理及网络排错思路。该示例既可作为入门参考也能在此基础上扩展为实际的PLC监控或数据采集程序对于FINS帧结构中的命令码、节点地址、数据长度等关键字段以及读取时的字节序和地址映射问题均可在配套代码与文档中找到对应说明减少自行摸索成本适合需要快速落地的工控开发者。1. 一个让 C# 直接读取欧姆龙 PLC 的 FINS UDP 最小示例如果你第一次接触欧姆龙 PLC 和 C# 上位机的组合看到 FINS 协议脑袋里冒出来的第一件事肯定是去搜 DLL、搜 NuGet 包。但这个例子可以让你不依赖厂商库用十几行 C# 代码就把 PLC 里 D 区的字变量读出来。原因很反直觉FINS UDP 报文本身只有 18 字节结构固定手动拼帧比想象中简单得多。这份资源做的事很简单通过 UDP 9600 端口向 PLC 发送一条 0101 读命令帧再解析返回的字变量。它适合需要快速验证通讯、搭建产线数据采集或者手头没有现成通信库的开发者。看完这份例子你能把帧格式、地址换算、响应解析以及常见的 FINS 翻车点一次摸透。2. FINS 协议要先弄清楚的 3 件事帧格式、内存区编码、UDP 端口2.1 FINS UDP 帧结构10 字节头 命令 参数FINS 不是 Modbus 那种寄存器读写协议它有自己的寻址体系。一条读命令帧由三部分组成FINS 固定头、命令码、命令参数。UDP 模式下总长度通常 18 字节其中前 10 字节是固定的帧头后面 2 字节是命令码再后面 6 字节是具体读参数。帧头各字段含义可以用下面这张表看字段值看起来死板但容易出错的恰恰是其中两处DA1 和 SA1。DA1 必须和 PLC 上配置的 FINS 节点号一致SA1 是上位机给自己编的节点号不能和 PLC 节点号冲突。更隐蔽的是部分 CPU 单元在上位机连接设置里限制了允许访问的 FINS 节点或 IP就算网络能 ping 通FINS 层也会不响应。偏移字段值/含义0ICF0x80 表示命令帧0xC0 表示响应帧1RSV保留固定 0x002GCT网关数一般用 0x023DNA目标网络号0x00 表示本地网络4DA1目标节点号也就是 PLC 的 FINS 节点号5DA2目标单元号CPU 单元用 0x006SNA源网络号0x007SA1源节点号上位机自己的节点号8SA2源单元号0x009SID服务标识用于匹配请求和响应10-11命令码0x0101 读0x0102 写12命令参数由具体命令决定命令码 0x0101 后面跟的 6 字节参数是内存区代码 1 字节、起始地址 2 字节、位号 1 字节、读取个数 2 字节。地址和个数都是高位在前也就是大端序。举个例子读 PLC 节点号 10 的 D100 起始 4 个字完整帧是这样80 00 02 00 0A 00 00 64 00 00 01 01 82 00 64 00 00 04逐个字段拆开看0x80 是命令帧0x0A 是目标节点号0x64 是上位机节点号0x0101 是读命令0x82 是 DM 区代码0x0064 是起始地址 1000x00 是位号0x0004 是读 4 个字。响应帧的头部照样是 10 字节结束码固定在偏移 12-13数据从偏移 14 开始。别去看响应里的 IC 字段正常返回是 0x00 0x00否则就要对着错误码表查原因。FINS 协议本身没有 CRC报文的完整性由 UDP/IP 层保证所以错误检查主要靠结束码和长度。2.2 内存区代码和地址换算D100、CIO200 怎么变成帧里的数字在 CX-Programmer 里写的地址是 D100、CIO200、W50FINS 帧里不直接认识字母要把地址区翻译成内存区代码把地址翻译成 2 字节数字。字访问时起始地址两个字节按大端填充位号固定填 0x00位访问时前两个字节仍然放字地址位号填 0x00 到 0x0F。地址区字访问代码位访问代码示例CIO0xB00x30CIO200W 内部继电器0xB10x31W100H 保持继电器0xB20x32H50A 辅助继电器0xB30x33A10D 数据寄存器0x820x02D100比如读 D100 起始 4 个字内存区代码填 0x82起始地址填 0x00 0x64位号填 0x00个数填 0x00 0x04。想读 CIO100.05 这个位内存区代码填 0x30起始地址仍填 0x00 0x64位号填 0x05个数按位来算。要注意的是D 区的位访问在不同 CPU 型号上支持程度不一样有的小型机只支持字访问对 D 区发位读会返回错误码这种情况我一般直接按 16 位整个读回来再到上位机做位运算。地址范围也不能凭感觉。CP 系列的 D 区大约到 D32767CJ 系列更大帧里写 0xFFFF 也只是个数字PLC 执行时会自己判断范围越界返回 0x1103。这跟 Modbus 里地址长度固定、范围靠协议文档约束是两回事最好在每个地址区封一层范围校验而不是靠 PLC 报错才发现问题。2.3 UDP 还是 TCP实际项目里为什么默认走 UDP 9600欧姆龙 PLC 同时支持 FINS/UDP 和 FINS/TCP两种方式默认端口都是 9600。UDP 方式发送简单没有连接管理适合周期轮询TCP 方式虽然不丢包但要额外处理 FINS/TCP 的帧头第一次建立连接还涉及双方端口协商复杂度上了一个台阶。我实际做产线项目时绝大多数场景用的都是 UDP 加超时重试。工业现场 PLC 和上位机在同一网段交换机可控偶尔丢包重发一帧成本很低要是跨三层路由、跨公网传输才会考虑 FINS/TCP 或者加专用网关。还有个常见误区你以为 FINS UDP 就是往 9600 端口扔 18 字节就能通其实 PLC 侧同样要做设置。生产环境里我见过好几台 PLCFINS 服务端口被改过或者节点号配置和图纸对不上。连接不上时不要只盯上位机代码先拿网络工具确认 9600 端口是否在监听再检查 PLC 设置里的 FINS 节点号。TCP/UDP 工具能扫出来端口开着说明大概率是帧里的节点号问题端口都扫不到就要先解决 PLC 侧通讯服务开关。3. C# 工程骨架一个能跑通 FINS 读取的控制台例子3.1 类职责划分Builder、Client、Parser 各管一段工程代码不长但职责划分得很清楚不然二次开发时会把 UDP 收发、帧拼接、数据解析全塞进一个类后面越改越乱。结构是这样的FinsDemo/ ├─ Program.cs // 调用入口演示读取 D100 前 4 个字 ├─ FinsFrameBuilder.cs // 拼帧工具只负责把参数变成 byte[] ├─ FinsUdpClient.cs // UDP 通道、超时、SID 管理 ├─ FinsResponseParser.cs // 解析响应结束码和字数据 └─ FinsDemo.csprojFinsFrameBuilder 只做一件事接收节点号、内存区代码、地址、个数这些参数输出一个 18 字节的数组。FinsUdpClient 负责 UDP 收发和超时控制内部会调用 Builder 和 Parser。Program 层不关心帧长什么样只关心读哪个地址、拿到什么值。后面如果要接入界面或服务替换的只有 Program 层协议层基本不动。工程文件用 .NET 6 控制台项目写起来干净也能跑在大多数工控机上。如果你现场还是老旧的 .NET Framework 4.8核心代码同样能用只有少数语法要调整。Project SdkMicrosoft.NET.Sdk PropertyGroup OutputTypeExe/OutputType TargetFrameworknet6.0/TargetFramework Nullabledisable/Nullable /PropertyGroup /Project3.2 UDP 通道初始化Connect、ReceiveTimeout 和节点号FinsUdpClient 构造函数里做三件事创建 UdpClient、设置同步 Receive 的超时时间、用 Connect 固定对端地址。Connect 之后Send 和 Receive 都不用再传 IPEndPoint 参数收到的数据只会来自这个 PLC 地址避免网络里乱入的广播包干扰。using System.Net; using System.Net.Sockets; public sealed class FinsUdpClient : IDisposable { private readonly UdpClient _udp; private readonly byte _localNode; private byte _sid; public FinsUdpClient(string plcIp, int port, byte localNode) { _udp new UdpClient(); _udp.Client.ReceiveTimeout 2000; _udp.Connect(new IPEndPoint(IPAddress.Parse(plcIp), port)); _localNode localNode; } public void Dispose() _udp.Dispose(); }ReceiveTimeout 的单位是毫秒这里设了 2000 毫秒。现场如果 PLC 扫描周期很长或网络存在拥塞可以调到 3000 到 5000但别太长否则轮询线程会卡死在 Receive 上整个采集链路跟着停。localNode 是上位机自己的 FINS 节点号1 到 127 之间取一个不冲突的值很多项目习惯直接用 100 也就是 0x64但这不是标准要求只是约定俗成。3.3 读请求帧组装FinsFrameBuilder 的 18 字节FinsFrameBuilder 是整个例子的核心。参数里 sid 由客户端传入每次请求递增dstNode 是 PLC 节点号srcNode 是上位机节点号memArea 是内存区代码startAddr 是字地址count 是读取字数。internal static class FinsFrameBuilder { public static byte[] BuildReadFrame( byte sid, byte dstNode, byte srcNode, byte memArea, ushort startAddr, ushort count) { var frame new byte[18]; frame[0] 0x80; // ICF: 命令帧 frame[1] 0x00; // RSV frame[2] 0x02; // GCT frame[3] 0x00; // 目标网络号本地网络 frame[4] dstNode; // PLC 节点号 frame[5] 0x00; // CPU 单元号 frame[6] 0x00; // 源网络号 frame[7] srcNode; // 上位机节点号 frame[8] 0x00; // 源单元号 frame[9] sid; // 服务 ID frame[10] 0x01; // 命令码 0x0101 frame[11] 0x01; // 读命令 frame[12] memArea; // 内存区代码如 0x82 是 DM 区 frame[13] (byte)(startAddr 8); // 起始地址高字节 frame[14] (byte)(startAddr 0xFF); // 起始地址低字节 frame[15] 0x00; // 位号0 表示按字读 frame[16] (byte)(count 8); // 读取个数高字节 frame[17] (byte)(count 0xFF); // 读取个数低字节 return frame; } }这里的字节操作全部是大端序startAddr 右移 8 位取高字节count 也是同样的处理。如果你之前写惯了 Modbus 的小端仓库这里特别容易顺手把低字节放前面结果 PLC 返回的地址完全不对。sid 参数在响应里会原样返回多线程场景下靠它匹配请求后面避坑章节会详细说。3.4 响应解析结束码优先数据从第 14 字节开始响应帧的头部和请求帧结构一样前 10 字节是帧头11-12 是命令码13-14 才是结束码。正常结束码是 0x0000错误码会在 0x1101、0x1103 这些区间。解析时必须先判断结束码再去取数据。internal static class FinsResponseParser { public static byte[] ParseRead(byte[] resp, ushort count) { if (resp.Length 14 count * 2) throw new InvalidDataException($响应长度不足: {resp.Length}); ushort endCode (ushort)((resp[12] 8) | resp[13]); if (endCode ! 0x0000) throw new InvalidOperationException($FINS 结束码错误: 0x{endCode:X4}); var data new byte[count * 2]; Array.Copy(resp, 14, data, 0, data.Length); return data; } }注意结束码的位置在偏移 12 和 13不在 14。因为在 10 字节帧头之后还有 2 字节命令码命令码后面才是结束码。很多第一次写 FINS 解析的人会把结束码的偏移算错一位导致明明读到的是正常数据却报了 0x1002 之类的长度错误。返回的数据区每字两字节都是大端序后续解析时要用(data[i] 8) | data[i 1]重新组合不能直接扔给 BitConverter。3.5 完整调用序列Main 方法从建连到输出FinsUdpClient 还需要补一个 ReadWords 方法把 Builder、Send、Receive、Parser 串起来。这里的同步 Receive 会阻塞到超时虽然不如异步优雅但胜在逻辑直观适合理解整个请求响应链路。public byte[] ReadWords(byte dstNode, byte memArea, ushort startAddr, ushort count) { byte[] frame FinsFrameBuilder.BuildReadFrame( _sid, dstNode, _localNode, memArea, startAddr, count); try { _udp.Send(frame, frame.Length); byte[] resp _udp.Receive(); return FinsResponseParser.ParseRead(resp, count); } catch (SocketException ex) when (ex.SocketErrorCode SocketError.TimedOut) { throw new TimeoutException($读取 D{startAddr} 超时); } }Program 里的调用非常简单构造客户端设置 PLC 节点号、内存区代码、起始地址和个数然后循环解析每个字。using System; class Program { static void Main() { using var client new FinsUdpClient(192.168.250.10, 9600, localNode: 0x64); byte[] data client.ReadWords( dstNode: 0x0A, // PLC 节点号 10 memArea: 0x82, // DM 区 startAddr: 100, // D100 count: 4); // 读 4 个字 for (int i 0; i data.Length; i 2) { ushort word (ushort)((data[i] 8) | data[i 1]); Console.WriteLine($D{100 i / 2} {word}); } } }这里的 count 是 4响应数据长度就是 8 字节循环按 2 字节一跨。如果只想读一个保持继电器 W50 的值把 memArea 改成 0xB1、startAddr 改成 50 就行。读到的高位在前已经在循环里转换成了 ushort直接显示就是 PLC 监控里看到的十进制值。4. FINS 通信必踩的 5 个坑从连不上到数据错乱4.1 链路层IP、端口、节点号为啥总对不上现象Send 方法没报错UDP 报文也确实发出去了但 Receive 一直等到超时整个上位机卡在读取状态。抓包看 PLC 有回包但程序收不到或者 PLC 根本没回。原因这一层八成不是代码问题而是 DA1 目标节点号和 PLC 实际配置不一致。FINS 节点号和 IP 地址没有必然映射关系它是在 PLC 设置里单独配的在 CX-Programmer 的 PLC 设置菜单里能看到。另一个常见原因是 SA1 源节点号没有按 PLC 的允许列表设置帧到了 FINS 层直接被丢掉了。解决第一步先把 IP 和端口排除掉ping 一下 PLC 地址再用 TCP/UDP 工具确认 9600 端口开着。第二步查 PLC 设置里的 FINS 节点号把 ReadWords 的 dstNode 参数改成这个值。第三步检查 PLC 的上位机连接允许列表把上位机的节点号或 IP 加进去。我第一次调 FINS 就栽在这上面代码改了三轮最后发现 PLC 侧工程没下载到 CPU 单元。4.2 报文层结束码 0x1101 和 0x1103 是什么意思现象响应帧完整收回来了但 ParseRead 抛异常结束码不是 0x0000最常见的是 0x1101 或 0x1103。原因0x1101 是内存区代码错误比如把 DM 区的 0x82 写成了 0xB0或者高位字节拼错0x1103 是地址越界起始地址超过了该 CPU 型号的内存范围也可能是一次读取的字数太多把命令长度撑爆了。解决对照第 2 章的内存区代码表逐字节检查帧内容。地址越界时先确认 CPU 型号对应的 D 区上限再看 count 是否超过单帧限制。还有一个隐蔽点字访问和位访问的代码表完全不同想读 CIO100 位却用了字访问代码 0xB0地址和位号对不上PLC 也会返回 0x1103。把 Builder 收到的参数打一行 hex 日志基本一眼就能定位。4.3 数据层读回 100 变成了 25600 是大端序翻车现象PLC 监控程序里 D100 显示 100上位机里读出来是 25600或者像 0、负数的乱值。原因FINS 协议在数据区使用大端字节序高字节存在前一个字节低字节在后。C# 的 BitConverter.ToUInt16 在 Windows 小巧端平台上按小端解析直接把两个字节反了100 就变成了 25600。这个坑几乎每个人都会踩一次和协议本身无关纯粹是主机字节序和网络字节序的差异。解决不要用 BitConverter改成(data[i] 8) | data[i 1]手工组合。32 位数值也要同样处理4 个字节依次左移 24、16、8、0。批量读取时每个字都按这个规则解析而不是先整体拷贝再用 BitConverter。4.4 批量读上限单帧能装多少数据要心里有数现象一次读 600 个字程序偶发返回 0x1103但把个数改成 400 就正常。有的 PLC 型号甚至直接无响应。原因FINS 单条读命令能返回的数据量是有限制的以字为单位读取时常见上限是 480 个字以位为单位读取时常见上限是 960 个位。超过这个数PLC 不会自动拆分而是返回错误或者丢掉帧。解决把 count 控制在 480 以内超过就分片读。比如想读 D100 到 D1000按 400 字一片循环递增起始地址。这个限制在不同 CPU 单元上可能有差异我在代码里写了一个常量 MaxReadWords 480换型号时只改这一处不用满世界找魔法数字。4.5 轮询一快就出乱数SID 和重发策略必须统一现象程序跑了几小时之后开始偶发超时或者读 A 地址的请求返回的却是 B 地址的数据重启上位机又正常。原因UDP 没有连接状态一个 UdpClient 如果被多线程同时调用两个请求都用同一个 SID 发出响应回来就没法区分谁是谁。另一个场景是超时重发之后旧响应后到被下一次 Receive 收走数据就错乱了。解决通信层必须保证两点一是每个请求的 SID 唯一递增响应里的 SID 要和请求里的 SID 对上二是同一时间只允许一个未完成的请求最简单的办法是在 ReadWords 和 WriteWords 外面加信号量或者直接用同一个轮询线程串行调用。写操作重发更要谨慎第一次超时不代表没写成功盲目重发会把同一个值写两次生产上我一般把写操作重试次数设成 0靠读回校验判断成功。5. 从读扩展到写和轮询一个能上产线的 FINS 通信层5.1 写命令帧BuildWriteFrame 和单字写入读命令是 0x0101写命令就是 0x0102。命令帧的前 10 字节头完全一致区别只在命令码和后面多出一段要写入的数据。写入的数据也是大端序一个 ushort 需要拆成高字节和低字节放进 data 数组。public static byte[] BuildWriteFrame( byte sid, byte dstNode, byte srcNode, byte memArea, ushort startAddr, byte bit, ushort count, byte[] data) { var frame new byte[18 data.Length]; frame[0] 0x80; frame[1] 0x00; frame[2] 0x02; frame[3] 0x00; frame[4] dstNode; frame[5] 0x00; frame[6] 0x00; frame[7] srcNode; frame[8] 0x00; frame[9] sid; frame[10] 0x01; frame[11] 0x02; // 写命令 frame[12] memArea; frame[13] (byte)(startAddr 8); frame[14] (byte)(startAddr 0xFF); frame[15] bit; // 字写填 0x00 frame[16] (byte)(count 8); frame[17] (byte)(count 0xFF); Array.Copy(data, 0, frame, 18, data.Length); return frame; }参数里 bit 字段对字写入填 0x00对位写入才填真正的位号。data 是已经按大端拆好的字节数组长度必须等于 count 乘以字节数。写命令的响应帧没有数据区只有结束码所以解析方法可以复用 ParseRead 的头部检查只判断 endCode。FinsUdpClient 里增加 WriteWords 方法入参直接设计成 ushort 数组内部负责大小端转换调用方不用关心协议细节public void WriteWords(byte dstNode, byte memArea, ushort startAddr, ushort[] words) { var bytes new byte[words.Length * 2]; for (int i 0; i words.Length; i) { bytes[i * 2] (byte)(words[i] 8); bytes[i * 2 1] (byte)(words[i] 0xFF); } byte[] frame FinsFrameBuilder.BuildWriteFrame( (byte)(_sid 0xFF), dstNode, _localNode, memArea, startAddr, 0x00, (ushort)words.Length, bytes); _udp.Send(frame, frame.Length); byte[] resp _udp.Receive(); FinsResponseParser.CheckEndCode(resp); }写操作不能无脑重试。如果第一次写入超时PLC 可能已经写成功也可能没写这时重发一次就有概率把同一个值覆盖写两遍。对设备控制类地址我一般会先 ReadWords 读回当前值确认值已经变化才认为写入成功没变才考虑重发。5.2 数据解码字、双字、浮点的通用拆法从 FINS 读回来的字节数组是原始数据必须按 PLC 里的变量类型解码。最常用的是 16 位无符号整型已已经讲过用位移组合。32 位整型和 IEEE 754 浮点也经常出现在温度、流量、压力等模拟量采集里FINS 在这类数据上同样是大端序。public static int ToInt32(byte[] data, int offset) { return (data[offset] 24) | (data[offset 1] 16) | (data[offset 2] 8) | data[offset 3]; } public static float ToFloat32(byte[] data, int offset) { uint raw (uint)ToInt32(data, offset); return BitConverter.ToSingle(BitConverter.GetBytes(raw), 0); }这里 offset 是相对于数据区起始位置的偏移而不是整个响应帧的偏移。读响应时数据区从第 14 字节开始所以想读第二个字offset 就是 2。ToFloat32 的思路是先把 4 个大端字节还原成一个 uint再借助 BitConverter 把 uint 的位模式解释成 float。这个方法在 Windows 这类小端平台上是对的因为 BitConverter.GetBytes(uint) 返回小端字节BitConverter.ToSingle 又按小端读回去正好还原了原始大端数据代表的浮点值。字符串类型也常见比如从 PLC 读设备型号、产品条码。欧姆龙 PLC 里的字符串在不少型号里按 ASCII 编码每个字符占一个字节。读回来之后直接 Encoding.ASCII.GetString但要先根据 PLC 程序里定义的长度截取避免把后面的脏数据带出来。5.3 封装轮询Timer 加忙标志防重入生产环境很少读一次就完事更多是定时采集。最简单的轮询封装是一个 Timer 定时触发 ReadWords同时用一个 _busy 标志防止上一次请求还没完成时下一次又进来public sealed class PlcPoller : IDisposable { private readonly FinsUdpClient _client; private readonly Timer _timer; private bool _busy; public PlcPoller(FinsUdpClient client, TimeSpan interval) { _client client; _timer new Timer(OnTick, null, interval, interval); } private void OnTick(object state) { if (_busy) return; _busy true; try { byte[] data _client.ReadWords(0x0A, 0x82, 100, 8); // 在这里把 data 解码后写入共享字段或触发事件 } catch (Exception ex) { // 记录日志不要吞掉超时异常 } finally { _busy false; } } public void Dispose() _timer.Dispose(); }轮询间隔不要设得太激进。PLC 扫描周期通常是几十毫秒到几百毫秒上位机每 10 毫秒请求一次FINS 层不会崩但 CPU 单元会因为频繁处理通信任务而拉长扫描周期影响本身控制逻辑。一般我先看 PLC 程序的扫描时间轮询间隔取扫描周期的 3 到 5 倍工业现场常见的 200 毫秒到 1 秒都算合理。捕获异常时至少要打一条日志包含请求地址、耗时和结束码。不要只在控制台输出正式项目把日志写到文件或消息队列里产线停线排查时这些日志比在线调试好用得多。5.4 并发控制同一个 FINS 连接必须串行一个 FinsUdpClient 实例对应一个 UDP 套接字和一条 SID 序列。多线程同时调 ReadWords会出现两个请求几乎同时发出、SID 交错、响应无法匹配的情况。之前避坑章节说的响应错乱根源就在这里。解决手法按项目复杂度分三档最简单的所有 PLC 请求都丢进同一个后台线程串行执行轮询器本身就是单线程天然安全中等复杂度给 ReadWords 和 WriteWords 内部加 SemaphoreSlim(1, 1)让方法级别串行再复杂一点可以按优先级拆成两个 UdpClient一个读慢速参数一个读快速报警但 PLC 侧通信负载也会翻倍不推荐轻易这么做。我现在的默认做法是单连接串行宁可读频率保守一点也不能让数据错乱成为产线的黑匣子。6. 二次开发实战把这套 FINS 例子改造成自己的库6.1 没有 PLC 时先用模拟器验证链路别直接拿产线 PLC 当调试对象。手头没有实物时先用支持 FINS 的模拟器架一个虚拟 PLC把抓包工具打开对照第 2 章的帧表确认 Builder 输出的 hex。我第一次调试时跳过模拟器结果连不上绕了半天最后发现是 PLC 节点号配置问题和代码无关。从那以后我强制自己先打印请求帧再进行任何优化。6.2 把地址解析做成独立方法协议层现在只接受内存区代码和数字地址界面配置时最好直接用 D100 这种字符串。加一层 PlcAddress 解析器把地址翻译成 memArea 和 startAddr界面写什么解析层就转什么后续扩展 CIO、W、H 区也方便public static byte[] ReadByAddress(string address, ushort count) { var (memArea, startAddr) PlcAddress.Parse(address); return _client.ReadWords(0x0A, memArea, startAddr, count); }6.3 从控制台到界面或服务把 FinsUdpClient 改成单例界面层通过事件接收解析后的变量如果转 Windows 服务就把 PlcPoller 放进后台托管服务。日志至少要记录 SID、耗时、结束码写命令必须等读回校验成功再继续。我以前的教训是图快没有对地址范围做启动校验结果 D2000 超出型号范围程序运行半小时才报 0x1103整条采集线程挂掉。现在每套上位机都强制走一遍「模拟器跑通、地址解析日志、单帧超时验证」再上产线。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/21 22:00:54 · 阅读 1.2k C#读取欧姆龙PLC：FINS UDP协议实现与实战示例
简介面向工业自动化现场开发者的C#欧姆龙PLC通信学习示例以FINS over TCP/IP协议为基础完整覆盖从建立网络连接、构造请求帧、发送指令到解析响应数据的流程。资源内包含可直接运行的Windows窗体工程以及9个C Sharp源文件分别演示连接建立、数据读取、写入操作、响应解析等典型场景另有通讯手册、协议格式图、网络调试助手和教学课件适合初中级工程师快速掌握欧姆龙PLC以太网通信方法。压缩包共四十五个文件整体仅四兆多除源代码外还提供了应用截图、配置资源、说明文档、可执行调试工具等目录结构明确便于按模块查阅。目前已有1117人学习下载配合直播素材与代码讲解可辅助理解FINS帧头、命令代码、地址分配、数据区读写、异常处理及网络排错思路。该示例既可作为入门参考也能在此基础上扩展为实际的PLC监控或数据采集程序对于FINS帧结构中的命令码、节点地址、数据长度等关键字段以及读取时的字节序和地址映射问题均可在配套代码与文档中找到对应说明减少自行摸索成本适合需要快速落地的工控开发者。1. 一个让 C# 直接读取欧姆龙 PLC 的 FINS UDP 最小示例如果你第一次接触欧姆龙 PLC 和 C# 上位机的组合看到 FINS 协议脑袋里冒出来的第一件事肯定是去搜 DLL、搜 NuGet 包。但这个例子可以让你不依赖厂商库用十几行 C# 代码就把 PLC 里 D 区的字变量读出来。原因很反直觉FINS UDP 报文本身只有 18 字节结构固定手动拼帧比想象中简单得多。这份资源做的事很简单通过 UDP 9600 端口向 PLC 发送一条 0101 读命令帧再解析返回的字变量。它适合需要快速验证通讯、搭建产线数据采集或者手头没有现成通信库的开发者。看完这份例子你能把帧格式、地址换算、响应解析以及常见的 FINS 翻车点一次摸透。2. FINS 协议要先弄清楚的 3 件事帧格式、内存区编码、UDP 端口2.1 FINS UDP 帧结构10 字节头 命令 参数FINS 不是 Modbus 那种寄存器读写协议它有自己的寻址体系。一条读命令帧由三部分组成FINS 固定头、命令码、命令参数。UDP 模式下总长度通常 18 字节其中前 10 字节是固定的帧头后面 2 字节是命令码再后面 6 字节是具体读参数。帧头各字段含义可以用下面这张表看字段值看起来死板但容易出错的恰恰是其中两处DA1 和 SA1。DA1 必须和 PLC 上配置的 FINS 节点号一致SA1 是上位机给自己编的节点号不能和 PLC 节点号冲突。更隐蔽的是部分 CPU 单元在上位机连接设置里限制了允许访问的 FINS 节点或 IP就算网络能 ping 通FINS 层也会不响应。偏移字段值/含义0ICF0x80 表示命令帧0xC0 表示响应帧1RSV保留固定 0x002GCT网关数一般用 0x023DNA目标网络号0x00 表示本地网络4DA1目标节点号也就是 PLC 的 FINS 节点号5DA2目标单元号CPU 单元用 0x006SNA源网络号0x007SA1源节点号上位机自己的节点号8SA2源单元号0x009SID服务标识用于匹配请求和响应10-11命令码0x0101 读0x0102 写12命令参数由具体命令决定命令码 0x0101 后面跟的 6 字节参数是内存区代码 1 字节、起始地址 2 字节、位号 1 字节、读取个数 2 字节。地址和个数都是高位在前也就是大端序。举个例子读 PLC 节点号 10 的 D100 起始 4 个字完整帧是这样80 00 02 00 0A 00 00 64 00 00 01 01 82 00 64 00 00 04逐个字段拆开看0x80 是命令帧0x0A 是目标节点号0x64 是上位机节点号0x0101 是读命令0x82 是 DM 区代码0x0064 是起始地址 1000x00 是位号0x0004 是读 4 个字。响应帧的头部照样是 10 字节结束码固定在偏移 12-13数据从偏移 14 开始。别去看响应里的 IC 字段正常返回是 0x00 0x00否则就要对着错误码表查原因。FINS 协议本身没有 CRC报文的完整性由 UDP/IP 层保证所以错误检查主要靠结束码和长度。2.2 内存区代码和地址换算D100、CIO200 怎么变成帧里的数字在 CX-Programmer 里写的地址是 D100、CIO200、W50FINS 帧里不直接认识字母要把地址区翻译成内存区代码把地址翻译成 2 字节数字。字访问时起始地址两个字节按大端填充位号固定填 0x00位访问时前两个字节仍然放字地址位号填 0x00 到 0x0F。地址区字访问代码位访问代码示例CIO0xB00x30CIO200W 内部继电器0xB10x31W100H 保持继电器0xB20x32H50A 辅助继电器0xB30x33A10D 数据寄存器0x820x02D100比如读 D100 起始 4 个字内存区代码填 0x82起始地址填 0x00 0x64位号填 0x00个数填 0x00 0x04。想读 CIO100.05 这个位内存区代码填 0x30起始地址仍填 0x00 0x64位号填 0x05个数按位来算。要注意的是D 区的位访问在不同 CPU 型号上支持程度不一样有的小型机只支持字访问对 D 区发位读会返回错误码这种情况我一般直接按 16 位整个读回来再到上位机做位运算。地址范围也不能凭感觉。CP 系列的 D 区大约到 D32767CJ 系列更大帧里写 0xFFFF 也只是个数字PLC 执行时会自己判断范围越界返回 0x1103。这跟 Modbus 里地址长度固定、范围靠协议文档约束是两回事最好在每个地址区封一层范围校验而不是靠 PLC 报错才发现问题。2.3 UDP 还是 TCP实际项目里为什么默认走 UDP 9600欧姆龙 PLC 同时支持 FINS/UDP 和 FINS/TCP两种方式默认端口都是 9600。UDP 方式发送简单没有连接管理适合周期轮询TCP 方式虽然不丢包但要额外处理 FINS/TCP 的帧头第一次建立连接还涉及双方端口协商复杂度上了一个台阶。我实际做产线项目时绝大多数场景用的都是 UDP 加超时重试。工业现场 PLC 和上位机在同一网段交换机可控偶尔丢包重发一帧成本很低要是跨三层路由、跨公网传输才会考虑 FINS/TCP 或者加专用网关。还有个常见误区你以为 FINS UDP 就是往 9600 端口扔 18 字节就能通其实 PLC 侧同样要做设置。生产环境里我见过好几台 PLCFINS 服务端口被改过或者节点号配置和图纸对不上。连接不上时不要只盯上位机代码先拿网络工具确认 9600 端口是否在监听再检查 PLC 设置里的 FINS 节点号。TCP/UDP 工具能扫出来端口开着说明大概率是帧里的节点号问题端口都扫不到就要先解决 PLC 侧通讯服务开关。3. C# 工程骨架一个能跑通 FINS 读取的控制台例子3.1 类职责划分Builder、Client、Parser 各管一段工程代码不长但职责划分得很清楚不然二次开发时会把 UDP 收发、帧拼接、数据解析全塞进一个类后面越改越乱。结构是这样的FinsDemo/ ├─ Program.cs // 调用入口演示读取 D100 前 4 个字 ├─ FinsFrameBuilder.cs // 拼帧工具只负责把参数变成 byte[] ├─ FinsUdpClient.cs // UDP 通道、超时、SID 管理 ├─ FinsResponseParser.cs // 解析响应结束码和字数据 └─ FinsDemo.csprojFinsFrameBuilder 只做一件事接收节点号、内存区代码、地址、个数这些参数输出一个 18 字节的数组。FinsUdpClient 负责 UDP 收发和超时控制内部会调用 Builder 和 Parser。Program 层不关心帧长什么样只关心读哪个地址、拿到什么值。后面如果要接入界面或服务替换的只有 Program 层协议层基本不动。工程文件用 .NET 6 控制台项目写起来干净也能跑在大多数工控机上。如果你现场还是老旧的 .NET Framework 4.8核心代码同样能用只有少数语法要调整。Project SdkMicrosoft.NET.Sdk PropertyGroup OutputTypeExe/OutputType TargetFrameworknet6.0/TargetFramework Nullabledisable/Nullable /PropertyGroup /Project3.2 UDP 通道初始化Connect、ReceiveTimeout 和节点号FinsUdpClient 构造函数里做三件事创建 UdpClient、设置同步 Receive 的超时时间、用 Connect 固定对端地址。Connect 之后Send 和 Receive 都不用再传 IPEndPoint 参数收到的数据只会来自这个 PLC 地址避免网络里乱入的广播包干扰。using System.Net; using System.Net.Sockets; public sealed class FinsUdpClient : IDisposable { private readonly UdpClient _udp; private readonly byte _localNode; private byte _sid; public FinsUdpClient(string plcIp, int port, byte localNode) { _udp new UdpClient(); _udp.Client.ReceiveTimeout 2000; _udp.Connect(new IPEndPoint(IPAddress.Parse(plcIp), port)); _localNode localNode; } public void Dispose() _udp.Dispose(); }ReceiveTimeout 的单位是毫秒这里设了 2000 毫秒。现场如果 PLC 扫描周期很长或网络存在拥塞可以调到 3000 到 5000但别太长否则轮询线程会卡死在 Receive 上整个采集链路跟着停。localNode 是上位机自己的 FINS 节点号1 到 127 之间取一个不冲突的值很多项目习惯直接用 100 也就是 0x64但这不是标准要求只是约定俗成。3.3 读请求帧组装FinsFrameBuilder 的 18 字节FinsFrameBuilder 是整个例子的核心。参数里 sid 由客户端传入每次请求递增dstNode 是 PLC 节点号srcNode 是上位机节点号memArea 是内存区代码startAddr 是字地址count 是读取字数。internal static class FinsFrameBuilder { public static byte[] BuildReadFrame( byte sid, byte dstNode, byte srcNode, byte memArea, ushort startAddr, ushort count) { var frame new byte[18]; frame[0] 0x80; // ICF: 命令帧 frame[1] 0x00; // RSV frame[2] 0x02; // GCT frame[3] 0x00; // 目标网络号本地网络 frame[4] dstNode; // PLC 节点号 frame[5] 0x00; // CPU 单元号 frame[6] 0x00; // 源网络号 frame[7] srcNode; // 上位机节点号 frame[8] 0x00; // 源单元号 frame[9] sid; // 服务 ID frame[10] 0x01; // 命令码 0x0101 frame[11] 0x01; // 读命令 frame[12] memArea; // 内存区代码如 0x82 是 DM 区 frame[13] (byte)(startAddr 8); // 起始地址高字节 frame[14] (byte)(startAddr 0xFF); // 起始地址低字节 frame[15] 0x00; // 位号0 表示按字读 frame[16] (byte)(count 8); // 读取个数高字节 frame[17] (byte)(count 0xFF); // 读取个数低字节 return frame; } }这里的字节操作全部是大端序startAddr 右移 8 位取高字节count 也是同样的处理。如果你之前写惯了 Modbus 的小端仓库这里特别容易顺手把低字节放前面结果 PLC 返回的地址完全不对。sid 参数在响应里会原样返回多线程场景下靠它匹配请求后面避坑章节会详细说。3.4 响应解析结束码优先数据从第 14 字节开始响应帧的头部和请求帧结构一样前 10 字节是帧头11-12 是命令码13-14 才是结束码。正常结束码是 0x0000错误码会在 0x1101、0x1103 这些区间。解析时必须先判断结束码再去取数据。internal static class FinsResponseParser { public static byte[] ParseRead(byte[] resp, ushort count) { if (resp.Length 14 count * 2) throw new InvalidDataException($响应长度不足: {resp.Length}); ushort endCode (ushort)((resp[12] 8) | resp[13]); if (endCode ! 0x0000) throw new InvalidOperationException($FINS 结束码错误: 0x{endCode:X4}); var data new byte[count * 2]; Array.Copy(resp, 14, data, 0, data.Length); return data; } }注意结束码的位置在偏移 12 和 13不在 14。因为在 10 字节帧头之后还有 2 字节命令码命令码后面才是结束码。很多第一次写 FINS 解析的人会把结束码的偏移算错一位导致明明读到的是正常数据却报了 0x1002 之类的长度错误。返回的数据区每字两字节都是大端序后续解析时要用(data[i] 8) | data[i 1]重新组合不能直接扔给 BitConverter。3.5 完整调用序列Main 方法从建连到输出FinsUdpClient 还需要补一个 ReadWords 方法把 Builder、Send、Receive、Parser 串起来。这里的同步 Receive 会阻塞到超时虽然不如异步优雅但胜在逻辑直观适合理解整个请求响应链路。public byte[] ReadWords(byte dstNode, byte memArea, ushort startAddr, ushort count) { byte[] frame FinsFrameBuilder.BuildReadFrame( _sid, dstNode, _localNode, memArea, startAddr, count); try { _udp.Send(frame, frame.Length); byte[] resp _udp.Receive(); return FinsResponseParser.ParseRead(resp, count); } catch (SocketException ex) when (ex.SocketErrorCode SocketError.TimedOut) { throw new TimeoutException($读取 D{startAddr} 超时); } }Program 里的调用非常简单构造客户端设置 PLC 节点号、内存区代码、起始地址和个数然后循环解析每个字。using System; class Program { static void Main() { using var client new FinsUdpClient(192.168.250.10, 9600, localNode: 0x64); byte[] data client.ReadWords( dstNode: 0x0A, // PLC 节点号 10 memArea: 0x82, // DM 区 startAddr: 100, // D100 count: 4); // 读 4 个字 for (int i 0; i data.Length; i 2) { ushort word (ushort)((data[i] 8) | data[i 1]); Console.WriteLine($D{100 i / 2} {word}); } } }这里的 count 是 4响应数据长度就是 8 字节循环按 2 字节一跨。如果只想读一个保持继电器 W50 的值把 memArea 改成 0xB1、startAddr 改成 50 就行。读到的高位在前已经在循环里转换成了 ushort直接显示就是 PLC 监控里看到的十进制值。4. FINS 通信必踩的 5 个坑从连不上到数据错乱4.1 链路层IP、端口、节点号为啥总对不上现象Send 方法没报错UDP 报文也确实发出去了但 Receive 一直等到超时整个上位机卡在读取状态。抓包看 PLC 有回包但程序收不到或者 PLC 根本没回。原因这一层八成不是代码问题而是 DA1 目标节点号和 PLC 实际配置不一致。FINS 节点号和 IP 地址没有必然映射关系它是在 PLC 设置里单独配的在 CX-Programmer 的 PLC 设置菜单里能看到。另一个常见原因是 SA1 源节点号没有按 PLC 的允许列表设置帧到了 FINS 层直接被丢掉了。解决第一步先把 IP 和端口排除掉ping 一下 PLC 地址再用 TCP/UDP 工具确认 9600 端口开着。第二步查 PLC 设置里的 FINS 节点号把 ReadWords 的 dstNode 参数改成这个值。第三步检查 PLC 的上位机连接允许列表把上位机的节点号或 IP 加进去。我第一次调 FINS 就栽在这上面代码改了三轮最后发现 PLC 侧工程没下载到 CPU 单元。4.2 报文层结束码 0x1101 和 0x1103 是什么意思现象响应帧完整收回来了但 ParseRead 抛异常结束码不是 0x0000最常见的是 0x1101 或 0x1103。原因0x1101 是内存区代码错误比如把 DM 区的 0x82 写成了 0xB0或者高位字节拼错0x1103 是地址越界起始地址超过了该 CPU 型号的内存范围也可能是一次读取的字数太多把命令长度撑爆了。解决对照第 2 章的内存区代码表逐字节检查帧内容。地址越界时先确认 CPU 型号对应的 D 区上限再看 count 是否超过单帧限制。还有一个隐蔽点字访问和位访问的代码表完全不同想读 CIO100 位却用了字访问代码 0xB0地址和位号对不上PLC 也会返回 0x1103。把 Builder 收到的参数打一行 hex 日志基本一眼就能定位。4.3 数据层读回 100 变成了 25600 是大端序翻车现象PLC 监控程序里 D100 显示 100上位机里读出来是 25600或者像 0、负数的乱值。原因FINS 协议在数据区使用大端字节序高字节存在前一个字节低字节在后。C# 的 BitConverter.ToUInt16 在 Windows 小巧端平台上按小端解析直接把两个字节反了100 就变成了 25600。这个坑几乎每个人都会踩一次和协议本身无关纯粹是主机字节序和网络字节序的差异。解决不要用 BitConverter改成(data[i] 8) | data[i 1]手工组合。32 位数值也要同样处理4 个字节依次左移 24、16、8、0。批量读取时每个字都按这个规则解析而不是先整体拷贝再用 BitConverter。4.4 批量读上限单帧能装多少数据要心里有数现象一次读 600 个字程序偶发返回 0x1103但把个数改成 400 就正常。有的 PLC 型号甚至直接无响应。原因FINS 单条读命令能返回的数据量是有限制的以字为单位读取时常见上限是 480 个字以位为单位读取时常见上限是 960 个位。超过这个数PLC 不会自动拆分而是返回错误或者丢掉帧。解决把 count 控制在 480 以内超过就分片读。比如想读 D100 到 D1000按 400 字一片循环递增起始地址。这个限制在不同 CPU 单元上可能有差异我在代码里写了一个常量 MaxReadWords 480换型号时只改这一处不用满世界找魔法数字。4.5 轮询一快就出乱数SID 和重发策略必须统一现象程序跑了几小时之后开始偶发超时或者读 A 地址的请求返回的却是 B 地址的数据重启上位机又正常。原因UDP 没有连接状态一个 UdpClient 如果被多线程同时调用两个请求都用同一个 SID 发出响应回来就没法区分谁是谁。另一个场景是超时重发之后旧响应后到被下一次 Receive 收走数据就错乱了。解决通信层必须保证两点一是每个请求的 SID 唯一递增响应里的 SID 要和请求里的 SID 对上二是同一时间只允许一个未完成的请求最简单的办法是在 ReadWords 和 WriteWords 外面加信号量或者直接用同一个轮询线程串行调用。写操作重发更要谨慎第一次超时不代表没写成功盲目重发会把同一个值写两次生产上我一般把写操作重试次数设成 0靠读回校验判断成功。5. 从读扩展到写和轮询一个能上产线的 FINS 通信层5.1 写命令帧BuildWriteFrame 和单字写入读命令是 0x0101写命令就是 0x0102。命令帧的前 10 字节头完全一致区别只在命令码和后面多出一段要写入的数据。写入的数据也是大端序一个 ushort 需要拆成高字节和低字节放进 data 数组。public static byte[] BuildWriteFrame( byte sid, byte dstNode, byte srcNode, byte memArea, ushort startAddr, byte bit, ushort count, byte[] data) { var frame new byte[18 data.Length]; frame[0] 0x80; frame[1] 0x00; frame[2] 0x02; frame[3] 0x00; frame[4] dstNode; frame[5] 0x00; frame[6] 0x00; frame[7] srcNode; frame[8] 0x00; frame[9] sid; frame[10] 0x01; frame[11] 0x02; // 写命令 frame[12] memArea; frame[13] (byte)(startAddr 8); frame[14] (byte)(startAddr 0xFF); frame[15] bit; // 字写填 0x00 frame[16] (byte)(count 8); frame[17] (byte)(count 0xFF); Array.Copy(data, 0, frame, 18, data.Length); return frame; }参数里 bit 字段对字写入填 0x00对位写入才填真正的位号。data 是已经按大端拆好的字节数组长度必须等于 count 乘以字节数。写命令的响应帧没有数据区只有结束码所以解析方法可以复用 ParseRead 的头部检查只判断 endCode。FinsUdpClient 里增加 WriteWords 方法入参直接设计成 ushort 数组内部负责大小端转换调用方不用关心协议细节public void WriteWords(byte dstNode, byte memArea, ushort startAddr, ushort[] words) { var bytes new byte[words.Length * 2]; for (int i 0; i words.Length; i) { bytes[i * 2] (byte)(words[i] 8); bytes[i * 2 1] (byte)(words[i] 0xFF); } byte[] frame FinsFrameBuilder.BuildWriteFrame( (byte)(_sid 0xFF), dstNode, _localNode, memArea, startAddr, 0x00, (ushort)words.Length, bytes); _udp.Send(frame, frame.Length); byte[] resp _udp.Receive(); FinsResponseParser.CheckEndCode(resp); }写操作不能无脑重试。如果第一次写入超时PLC 可能已经写成功也可能没写这时重发一次就有概率把同一个值覆盖写两遍。对设备控制类地址我一般会先 ReadWords 读回当前值确认值已经变化才认为写入成功没变才考虑重发。5.2 数据解码字、双字、浮点的通用拆法从 FINS 读回来的字节数组是原始数据必须按 PLC 里的变量类型解码。最常用的是 16 位无符号整型已已经讲过用位移组合。32 位整型和 IEEE 754 浮点也经常出现在温度、流量、压力等模拟量采集里FINS 在这类数据上同样是大端序。public static int ToInt32(byte[] data, int offset) { return (data[offset] 24) | (data[offset 1] 16) | (data[offset 2] 8) | data[offset 3]; } public static float ToFloat32(byte[] data, int offset) { uint raw (uint)ToInt32(data, offset); return BitConverter.ToSingle(BitConverter.GetBytes(raw), 0); }这里 offset 是相对于数据区起始位置的偏移而不是整个响应帧的偏移。读响应时数据区从第 14 字节开始所以想读第二个字offset 就是 2。ToFloat32 的思路是先把 4 个大端字节还原成一个 uint再借助 BitConverter 把 uint 的位模式解释成 float。这个方法在 Windows 这类小端平台上是对的因为 BitConverter.GetBytes(uint) 返回小端字节BitConverter.ToSingle 又按小端读回去正好还原了原始大端数据代表的浮点值。字符串类型也常见比如从 PLC 读设备型号、产品条码。欧姆龙 PLC 里的字符串在不少型号里按 ASCII 编码每个字符占一个字节。读回来之后直接 Encoding.ASCII.GetString但要先根据 PLC 程序里定义的长度截取避免把后面的脏数据带出来。5.3 封装轮询Timer 加忙标志防重入生产环境很少读一次就完事更多是定时采集。最简单的轮询封装是一个 Timer 定时触发 ReadWords同时用一个 _busy 标志防止上一次请求还没完成时下一次又进来public sealed class PlcPoller : IDisposable { private readonly FinsUdpClient _client; private readonly Timer _timer; private bool _busy; public PlcPoller(FinsUdpClient client, TimeSpan interval) { _client client; _timer new Timer(OnTick, null, interval, interval); } private void OnTick(object state) { if (_busy) return; _busy true; try { byte[] data _client.ReadWords(0x0A, 0x82, 100, 8); // 在这里把 data 解码后写入共享字段或触发事件 } catch (Exception ex) { // 记录日志不要吞掉超时异常 } finally { _busy false; } } public void Dispose() _timer.Dispose(); }轮询间隔不要设得太激进。PLC 扫描周期通常是几十毫秒到几百毫秒上位机每 10 毫秒请求一次FINS 层不会崩但 CPU 单元会因为频繁处理通信任务而拉长扫描周期影响本身控制逻辑。一般我先看 PLC 程序的扫描时间轮询间隔取扫描周期的 3 到 5 倍工业现场常见的 200 毫秒到 1 秒都算合理。捕获异常时至少要打一条日志包含请求地址、耗时和结束码。不要只在控制台输出正式项目把日志写到文件或消息队列里产线停线排查时这些日志比在线调试好用得多。5.4 并发控制同一个 FINS 连接必须串行一个 FinsUdpClient 实例对应一个 UDP 套接字和一条 SID 序列。多线程同时调 ReadWords会出现两个请求几乎同时发出、SID 交错、响应无法匹配的情况。之前避坑章节说的响应错乱根源就在这里。解决手法按项目复杂度分三档最简单的所有 PLC 请求都丢进同一个后台线程串行执行轮询器本身就是单线程天然安全中等复杂度给 ReadWords 和 WriteWords 内部加 SemaphoreSlim(1, 1)让方法级别串行再复杂一点可以按优先级拆成两个 UdpClient一个读慢速参数一个读快速报警但 PLC 侧通信负载也会翻倍不推荐轻易这么做。我现在的默认做法是单连接串行宁可读频率保守一点也不能让数据错乱成为产线的黑匣子。6. 二次开发实战把这套 FINS 例子改造成自己的库6.1 没有 PLC 时先用模拟器验证链路别直接拿产线 PLC 当调试对象。手头没有实物时先用支持 FINS 的模拟器架一个虚拟 PLC把抓包工具打开对照第 2 章的帧表确认 Builder 输出的 hex。我第一次调试时跳过模拟器结果连不上绕了半天最后发现是 PLC 节点号配置问题和代码无关。从那以后我强制自己先打印请求帧再进行任何优化。6.2 把地址解析做成独立方法协议层现在只接受内存区代码和数字地址界面配置时最好直接用 D100 这种字符串。加一层 PlcAddress 解析器把地址翻译成 memArea 和 startAddr界面写什么解析层就转什么后续扩展 CIO、W、H 区也方便public static byte[] ReadByAddress(string address, ushort count) { var (memArea, startAddr) PlcAddress.Parse(address); return _client.ReadWords(0x0A, memArea, startAddr, count); }6.3 从控制台到界面或服务把 FinsUdpClient 改成单例界面层通过事件接收解析后的变量如果转 Windows 服务就把 PlcPoller 放进后台托管服务。日志至少要记录 SID、耗时、结束码写命令必须等读回校验成功再继续。我以前的教训是图快没有对地址范围做启动校验结果 D2000 超出型号范围程序运行半小时才报 0x1103整条采集线程挂掉。现在每套上位机都强制走一遍「模拟器跑通、地址解析日志、单帧超时验证」再上产线。希望帮到你。本文还有配套的精品资源点击获取