简介面向C#开发者的欧姆龙PLC通信资源包演示如何通过FINS协议连接、读取和写入PLC寄存器数据覆盖帧构造、命令代码、响应解析等关键点适合工业自动化上位机开发人员、电气工程师和PLC通信入门者。包内共45个文件大小4.38MB核心是9个源代码文件含示例工程并配有通讯手册、协议截图、网络调试工具和课件文档方便对照报文逐帧学习。目前已有1117人学习说明这类互联需求在设备监控和数据采集中较为常见。下载后可直接用Visual Studio打开工程修改PLC的IP和寄存器地址即可运行通过抓包工具分析FINS请求与响应可快速掌握帧格式与命令码进而完成寄存器批量读写、状态轮询等任务。整套资料将协议规范、可运行示例和调试工具整合在一起能有效缩短从零搭建通信环境的周期适合作入门教程和项目参考。1. 项目定位一条 C# 上位机与 FINS 协议的通信链路车间里有一批设备状态要往 PC 上汇总PLC 用的不是通用的 Modbus TCP而是 FINS 报文协议。第一次接触 FINS 时我踩了不少坑明明 IP 能 ping 通指令发出去了PLC 就是不回包偶尔回了数值还是反的。这套 C# 例子把「通过 FINS 读取 PLC 内存区」这件事做成了最小可跑的工程直接基于 UdpClient 发送 0101 读取命令拿到响应后按字解析温度、压力、运行位等点位数据。它适合两类人一类是刚接手 C# 上位机、第一次碰 FINS 的开发者照着配置改 IP 和节点号就能跑通另一类是已经熟悉 PLC、想绕开厂家封装控件直接用裸协议做轻量采集的熟手。整份代码没有依赖第三方库读起来也不会被业务代码带偏。2. 工程骨架与报文结构拆开 FINS 帧的每个字节FINS 协议的报文并不复杂难点在于很多人把组帧、收发、解析全写在一个按钮事件里出了问题根本不知道是网络层、帧格式还是字节序的锅。这套工程从一开始就把通信和业务分开报文相关代码集中在FinsClient网络参数单独抽成配置类业务侧只负责维护点位列表。后面再改协议版本或者换 TCP 传输需要动的文件很有限。2.1 工程目录通信类、模型与配置分离工程是一个 .NET 6 控制台程序目录结构大致如下FinsDemo/ ├── Program.cs // 控制台入口负责轮询和日志 ├── FinsClient.cs // UDP 收发、组帧、拆帧、超时处理 ├── FinsNetConfig.cs // PLC IP、节点号、端口、超时配置 ├── FinsException.cs // 结束码转业务异常 ├── DataPoint.cs // 点位模型区域、地址、数据类型 ├── BatchReader.cs // 批量读取改造模块 └── appsettings.json // 网络参数与点位配置FinsClient只做一件事把调用方传入的「区域码 地址 读取个数」变成一条 FINS 读取命令发出去再把响应里的结束码和数据区解析出来。它不知道温度和压力是什么也不关心点位名称。BatchReader负责把一组点位合并成尽量少的读取请求降低轮询耗时。Program.cs负责定时循环、异常处理和日志输出这样每一层都能单独验证。这种分层看起来比一个Program.cs写到底笨实际排查问题时收益很大。第一次跑通后把FinsClient单独写单元测试就能确认帧格式没问题点位读不到值问题一定出在配置或 PLC 地址映射上不会互相甩锅。2.2 FINS 帧头ICF、节点号与 SID 怎么填FINS 的报文首部固定 10 个字节后面跟 2 字节命令码和命令参数。读取命令0101的参数是内存区代码 1 字节、起始地址 2 字节、读取字数 2 字节。所以一次 UDP 读取请求共 17 字节响应长度至少 14 字节数据区从第 14 字节开始。首部每个字节的含义和处理规则如下表偏移字段含义本工程取值0ICF信息控制字段0x80表示需要响应1RSV保留0x002GCT网关计数0x023DNA目标网络号0x00本地网络4DA1目标节点号PLC 的 FINS 节点号5DA2目标单元号0x00CPU 单元6SNA源网络号0x007SA1源节点号上位机自身 FINS 节点号8SA2源单元号0x009SID服务标识每次请求自增用于匹配响应DA1和SA1不是随便填的。很多 PLC 的以太网模块会把 FINS 节点号默认设成 IP 最后一段比如192.168.1.10对应节点号 10如果 PLC 被改过这里填错请求发出去没有响应。SID的作用是把当前请求和响应配对轮询频率一高SID 必须用完后自增或者随机变化不能永远填0x00否则调试时根本分不清回包对应哪条命令。2.3 UDP 与 TCP这个例子为什么默认走 UDP 9600FINS 协议在以太网上有两种常见传输FINS/UDP 和 FINS/TCP目标端口都是 9600。这份例子选 UDP不选 TCP原因有两点。第一FINS/UDP 的报文就是裸 FINS 帧抓包和拼帧都直观FINS/TCP 还要在帧前面套一截 8 字节的会话头第一次调试容易多包一层错。第二车间上位机采集场景通常是上位机主动发起请求PLC 被动响应UDP 的状态管理正好满足需求。UDP 的 9600 端口要求 PLC 以太网单元里开放 FINS UDP 服务默认都是开的。UdpClient本机端口不用刻意绑定到 9600只要能收 PLC 回包源端口由系统分配即可。如果现场网络环境差、丢包多再考虑换 FINS/TCP那一层改造在第六章会提到。3. 核心模块拆解一个读取请求从构造到解析的完整链路这一章把源码里的重点代码逐段拎出来讲。顺序按照一次读取请求的完整链路走初始化客户端、构造命令、发送并接收、解析响应字节序。看懂这几段其他区域码、写命令、批量读取都是同一套逻辑换参数而已。3.1 初始化客户端UdpClient 与网络参数的绑定通信类的构造函数接收一个FinsNetConfig配置对象里面包含 PLC IP、PLC 节点号、上位机节点号和超时时间。构造UdpClient后直接把套接字超时时间设好这样后面Receive阻塞时不会无限等下去。public sealed class FinsClient : IDisposable { private readonly UdpClient _udp; private readonly IPEndPoint _plcRemote; private readonly int _plcNode; private readonly int _localNode; private readonly int _timeoutMs; private readonly object _sync new object(); private byte _sid; public FinsClient(FinsNetConfig config) { _plcNode config.PlcNode; _localNode config.LocalNode; _timeoutMs config.TimeoutMs; _plcRemote new IPEndPoint(IPAddress.Parse(config.PlcIp), config.Port); _udp new UdpClient(); _udp.Client.ReceiveTimeout _timeoutMs; } }这里把_sync锁加上是因为后续同步收发方法会共享同一个UdpClient。一个连接内部维护一个自增 SID多线程同时发命令时如果没有这把锁SID 会互相覆盖接收方靠 SID 配对就乱了。锁的粒度是整个收发过程不是只锁 SID 自增保证请求和响应是一对一的关系。ReceiveTimeout的单位是毫秒配置里给 2000 代表 2 秒超时。现场 PLC 在大数据量读取或者总线负载高时响应可能变慢这个值要留足余量。上位机轮询越频繁越不要把超时压到 500 毫秒以内否则偶发的延迟会被误判成通信故障。3.2 构造读取命令内存区代码与 0101 命令的字节布局读取命令的核心是BuildReadCmd方法。0101是 FINS 的读命令码后面跟 5 个参数区域码、起始地址高字节、起始地址低字节、读取个数高字节、读取个数低字节。地址和个数都是二进制数不是 BCD 码拼字节时用移位和与操作。public byte[] Read(byte areaCode, int address, int count) { if (address 0 || address 0xFFFF || count 0 || count 0xFFFF) throw new ArgumentOutOfRangeException(nameof(address)); lock (_sync) { byte sid NewSid(); byte[] cmd BuildReadCmd(areaCode, address, count, sid); _udp.Send(cmd, cmd.Length, _plcRemote); byte[] resp ReadResponse(sid); return resp.AsSpan(14, count * 2).ToArray(); } } private byte[] BuildReadCmd(byte areaCode, int address, int count, byte sid) { byte[] cmd new byte[17]; cmd[0] 0x80; // ICF需要响应 cmd[1] 0x00; // RSV cmd[2] 0x02; // GCT cmd[3] 0x00; // DNA本地网络 cmd[4] (byte)_plcNode; // DA1目标节点号 cmd[5] 0x00; // DA2CPU 单元 cmd[6] 0x00; // SNA cmd[7] (byte)_localNode; // SA1源节点号 cmd[8] 0x00; // SA2 cmd[9] sid; // SID cmd[10] 0x01; // 命令码 0101 cmd[11] 0x01; cmd[12] areaCode; // 内存区代码 cmd[13] (byte)(address 8); // 地址高字节 cmd[14] (byte)(address 0xFF);// 地址低字节 cmd[15] (byte)(count 8); // 读取个数高字节 cmd[16] (byte)(count 0xFF); // 读取个数低字节 return cmd; } private byte NewSid() { _sid (byte)((_sid 1) 0xFF); return _sid; }读字指令常用的区域码是0x82DM 区、0xB0CIO 区、0xB1WR 区。DM区地址 0 对应 PLC 里的 DM0CIO区地址 500 对应 CIO 500不需要再乘 2因为这里按字寻址一个地址代表一个 16 位字。count表示读几个字想读两个连续字拼一个 32 位浮点数count 就填 2。如果把地址当成 BCD 码来拼比如 PLC 里显示D0100你直接填十六进制0x0100读回来的就是完全不对的区域。PLC 参数地址在 FINS 报文里就是二进制数一个int直接拆高低字节别做十进制转 BCD 的中间转换。3.3 解析响应结束码、SID 校验与数据切片ReadResponse负责收 UDP 包并校验。收到包之后先看包头里的 SID 是否等于本次请求的 SID不相等就继续收下一个包直到超时。再取第 12、13 字节作为结束码非 0 时直接抛FinsException。private byte[] ReadResponse(byte expectedSid) { while (true) { IPEndPoint remote new IPEndPoint(IPAddress.Any, 0); byte[] resp; try { resp _udp.Receive(ref remote); } catch (SocketException ex) when (ex.SocketErrorCode SocketError.TimedOut) { throw new TimeoutException($等待 PLC 响应超时SID{expectedSid:X2}); } if (!remote.Equals(_plcRemote) || resp.Length 14 || resp[9] ! expectedSid) continue; ushort endCode ReadUInt16BigEndian(resp, 12); if (endCode ! 0) throw new FinsException(endCode, ResolveMessage(endCode)); return resp; } } private static ushort ReadUInt16BigEndian(byte[] buffer, int offset) { return (ushort)((buffer[offset] 8) | buffer[offset 1]); }这里判断resp.Length 14是防御性校验。正常响应至少 14 字节10 字节帧头、2 字节命令码、2 字节结束码。如果收到的报文长度都不够说明抓到的可能不是 FINS 响应丢弃继续等。结束码的常见值有0x0000正常、0x1101区域或长度设定异常、0x1103地址设定异常、0x1203数据长度异常。真正要细抠时还是以 PLC 手册的结束码表为准不同机型个别码有差异。校验完 SID 和结束码后resp[14..]就是数据区。count个字的响应数据长度是count * 2字节切片后返回给上层做类型转换。这里有个容易忽略的点UDP 是可能收到杂包的调试时不要一收到数据就认定是本次响应SID 校验不能省。3.4 地址换算与数据类型DM 区偏移怎么变成 FINS 地址从上层视角看没人愿意每次调用都传0x82、地址、count 这些原始参数。于是我在FinsClient上加了几种常用类型的方法把 FINS 数据区还原成业务值。public ushort ReadWord(byte areaCode, int address) { byte[] data Read(areaCode, address, 1); return ReadUInt16BigEndian(data, 0); } public float ReadFloat(byte areaCode, int address) { byte[] data Read(areaCode, address, 2); uint raw ((uint)data[0] 24) | ((uint)data[1] 16) | ((uint)data[2] 8) | data[3]; return BitConverter.ToSingle(BitConverter.GetBytes(raw), 0); } public bool ReadBit(byte areaCode, int address, int bitIndex) { ushort word ReadWord(areaCode, address); return (word (1 bitIndex)) ! 0; }FINS 字数据在报文里是高字节在前而 C# 的BitConverter在绝大多数 PC 平台上是小端解析直接BitConverter.ToUInt16会把高低字节读反。上面代码用移位手动拼不依赖运行平台的大小端假设。一个实测场景PLC 里 DM100 存 100十六进制是00 64报文数据区是00 64如果用小端解析得到的是0x6400也就是 25600数值差了 256 倍。整条链路里所有字数据必须统一走一个解析入口不要写一半时手滑用BitConverter。浮点数按 IEEE 754 存储时占两个连续字四个字节网络序拼成uint再通过BitConverter.GetBytes中转成float。位读取先读整个字再按bitIndex位移判断。CIO区相对复杂的地方在于位地址带有小数比如 CIO 1.05 这种地址格式建议先转成「字地址 位索引」再调用ReadBit不要把小数直接乘 16 塞进 address。4. 避坑记录地址换算、字节序与响应码的 5 个翻车现场这一章是血泪经验的浓缩。FINS 协议本身不难难在细节下面五条基本覆盖了大多数人第一次跑通信时会遇到的情况。每条都按「现象 → 原因 → 解决」写方便对照。4.1 现象一网络能 ping 通PLC 就是不回包现象UdpClient.Send正常执行没有抛异常但Receive一直等到超时抓包只看到请求看不到响应。原因请求里的DA1和 PLC 实际配置的 FINS 节点号对不上。PLC 以太网单元里的 FINS 节点号可以手动设置不一定等于 IP 最后一段。还有一种情况是SA1填了 0PLC 侧开启了节点号校验看到源节点无效直接丢弃。解决先去 PLC 系统设定里读出当前 FINS 节点号把配置里的PlcNode改成它。上位机的LocalNode也最好设成和本机 IP 对应的值并且在 PLC 的 FINS 节点表里登记。如果只是做点对点测试至少保证本地节点号不是 0且和 PLC 没有冲突。改完还不行用抓包工具对比请求帧头里的DA1和SA1字节一眼就能看出来。4.2 现象二读回来的数值比触摸屏上大一倍或乱跳现象PLC 里 DM100 的值是 100上位机读出来变成 25600或者读 32 位浮点数时数值完全离谱。原因FINS 数据区按网络字节序传输高字节在前。C# 的BitConverter.ToUInt16默认按小端解析直接把00 64读成0x6400。解决字数据的解析统一用移位方式拼禁止在核心解析路径上直接BitConverter.ToUInt16。浮点数也按四个字节手工拼成uint再转。这个坑最容易排查也最容易犯关键是别只改一处要全类收口。从那以后我每次新增数据类型第一件事就是看它走没走统一的ReadUInt16BigEndian入口。4.3 现象三第一次读写正常之后偶发超时现象程序启动后第一次点动读写是好的轮询跑几圈突然出现一次超时下一次又自己恢复看起来像玄学。原因常见原因是 SID 没有变化每次都发 0x00。PLC 收到重复 SID 的请求时部分固件会当成重试报文处理回来的响应可能对应上一条命令导致上位机按照 SID 匹配失败。另一个隐藏原因是多线程共用一个UdpClientReceive却在另一个线程里处理响应被别的请求消费掉了。解决每条命令使用自增 SID接收侧强制校验 SID不匹配的包丢弃继续收。多线程调用同一FinsClient时必须把「自增 SID 发送 接收」放进同一个锁里。项目里如果并发要求高最简单干脆的办法是每个线程一个FinsClient实例互不干扰。4.4 现象四结束码报 0x1103 或 0x1101地址明明不大现象读取 DM 地址 1000 报地址异常或者读取连续 50 个字报区域超限。原因第一种是把地址当成 BCD 码拼了比如把十进制 1000 转成 0x1000 填入地址字段。第二种是 count 太大跨过了该内存区实际允许的最大地址。DM 区在几款小机型上末尾地址不同CIO 区的范围也受 CPU 型号限制理论值不等于实际值。解决确认地址按二进制拼取消一切 BCD 转换。然后从读 1 个字开始逐步把 count 往上加找到边界。很多 PLC 允许读的范围是连续的比如 DM 0 到 DM 5999但有些区段中间存在空隙一次读太大就会撞到边界。批量读取时先按连续段分组别图省事把跨几百个字的大区间一次读完。4.5 现象五同步收报卡死界面任务里又不敢随便 Sleep现象在 WinForms 的按钮事件里调用ReadWord点一下界面就白屏点几秒后恢复但整个程序像假死。原因UdpClient.Receive是同步阻塞调用界面线程被卡在等 PLC 回包上。超时 2 秒还好如果配置成 10 秒界面就得卡 10 秒。解决UI 线程不要直接调通信方法。把轮询放进Task.Run或者独立的后台采集服务里界面通过事件、INotifyPropertyChanged或消息队列更新。通信类内部用ReceiveTimeout控制阻塞上限不要在超时处理里再写Thread.Sleep(50)之类的重试逻辑超时返回后直接进入下一次轮询即可。5. 改造示例批量轮询、配置化地址表与异常重连跑通单点读取只是第一步。把这份例子接到真实设备上时一般还要做三件事减少请求次数、把点位配置从代码里挪出去、让采集服务断线后自己恢复。这一章的改造代码在原工程里都有可以直接抄。5.1 从单点读取改成批量读取一次请求读多个字单点读取的问题是每个点位一次 UDP 请求100 个点位就是 100 次每次往返哪怕只有 2 毫秒一轮也要 200 毫秒。FINS 读取命令本身支持一次读多个连续字所以按区域分组后把同一区域里离得近的点位合成一段一次读完再按偏移切给各个点位。public Dictionarystring, object ReadBatch(IReadOnlyListDataPoint points) { var result new Dictionarystring, object(); foreach (var group in points.GroupBy(p p.Area)) { byte area group.Key; var ordered group.OrderBy(p p.Address).ToList(); var segments new ListListDataPoint(); foreach (var point in ordered) { if (segments.Count 0 || point.Address - segments.Last().Last().Address 16) { segments.Add(new ListDataPoint()); } segments.Last().Add(point); } foreach (var segment in segments) { int min segment.Min(p p.Address); int max segment.Max(p p.Address p.Count); byte[] block _client.Read(area, min, max - min); foreach (var point in segment) { int offset (point.Address - min) * 2; byte[] slice block .Skip(offset) .Take(point.Count * 2) .ToArray(); result[point.Name] ConvertSlice(slice, point.Type); } } } return result; }分段阈值 16 是经验值。两个点位地址相隔不超过 16 个字时合并一次读超过就断开这样既不会把区间拉得太长也不会频繁触发单点请求。ConvertSlice内部根据DataPoint.Type把切片转成ushort、int、float或bool它和第三章的数据解析方法是一套逻辑。这种批量读法的收益在点位密集时很明显。比如一组模拟量点都放在 DM 区连续地址里原来 20 次 UDP 往返能缩到 1 次轮询周期从秒级降到百毫秒级。代价是每次读取的块变大如果点位分布太散合并的收益反而被超时风险抵消所以分段阈值要按实际点位分布调。5.2 配置化地址表用 JSON 管理点位硬编码点位名称和地址改起来太痛苦而且换一台设备往往只是换几个地址。我把点位配置挪到appsettings.json里程序启动时反序列化成ListDataPoint。{ Plc: { Ip: 192.168.1.10, PlcNode: 10, LocalNode: 100, Port: 9600, TimeoutMs: 2000 }, Points: [ { Name: Pressure, Area: DM, Address: 100, Count: 1, Type: Word }, { Name: SetTemp, Area: DM, Address: 120, Count: 2, Type: Float }, { Name: RunSignal, Area: CIO, Address: 500, Count: 1, Type: Bool } ] }Area字符串到内存区代码做一层映射DM - 0x82CIO - 0xB0WR - 0xB1。DataPoint里同时保存Count和TypeCount决定切多少个字节Type决定用什么解析器。这样新增一个采集点位只改 JSON不动代码。如果点位表格是从 Excel 或数据库里来的也可以直接把这张表换成 SQL 查询结果ReadBatch不变。配置化之后要特别注意一点Address属性不要写成 PLC 上位机里的显示地址统一写成 FINS 原始地址。比如有些触摸屏显示D0100但 FINS 地址就是 100有些软件把 CIO 500 显示成CIO500.00但字地址还是 500。写进 JSON 之前先在 PLC 手册里核对区域和地址范围。5.3 异常重连与日志让采集服务能过夜现场程序没人天天盯着通信模块必须能在超时后自己恢复。常见的做法是循环里捕获超时异常重建UdpClient等待一小段时间再继续。重建连接的成本很低比反复复用同一个半死状态的 socket 更可靠。while (!cts.IsCancellationRequested) { try { var values _batchReader.ReadBatch(_points); _logger.LogValue(values); } catch (TimeoutException) { _logger.Write(PLC 响应超时准备重连); _client.Dispose(); _client new FinsClient(_config); _batchReader.UpdateClient(_client); await Task.Delay(2000, cts.Token); } catch (FinsException ex) { _logger.Write($FINS 异常{ex.Message}); await Task.Delay(1000, cts.Token); } await Task.Delay(_intervalMs, cts.Token); }重连前必须把旧的UdpClient释放掉否则旧 socket 上的缓存响应可能干扰新会话。FinsException里如果结束码表示的是点位地址写错重连没用所以日志里一定要带上原始地址、区域码和 count。日志尽量写成结构化文本至少包括时间、点位名、原始值和结束码。现场排查超时问题时时间戳能帮判断是 PLC 周期性抖动还是数据量大导致的固定延迟。日志里另一个容易被忽略的指标是「每轮实际耗时」。在ReadBatch前后各记一个时间戳跑一段时间就能看出通信链路是否稳定。五十个点位正常 80 毫秒读完突然变成 500 毫秒大概率是网络有重传这时候再优化读取段大小才有方向。6. 二次开发建议从跑通到改造成自己的采集程序拿到这份源码建议先不要急着加业务按下面顺序做三轮改造每一步都能独立验证。先扩展FinsClient把写命令0102加上。写法就是把命令码改成0x01 0x02参数在原来读取命令的基础上追加待写数据区域码、地址和字数的拼法和读取一致。我只建议第一步就加写命令因为这个通信用途不只是单向采集设备启停、设定值下发都需要写。再对照实际 PLC 型号确认内存区代码表。小机型的 CIO、WR、DM 区域范围和大机型不一样尤其是扩展数据区。把配置里不存在的区域提前在启动时做一次字典检查能挡住一半手滑填错地址的现场故障。最后按这个清单做一轮回归验证项预期结果修改 IP、节点号后启动无超时异常控制台正常打印点位值读取 DM 浮点量数值与 PLC 侧编程软件一致人为拔掉网线再插回2 秒超时后进入重连恢复后继续采集连续运行 8 小时日志无 SID 错配无累计卡死修改 JSON 后重启程序新点位立即生效不需要重新编译从那次以后我每次拿到一个没见过的 PLC 型号都会先把内存区地址范围和字节序确认清楚再往工程里填点位。先用最朴素的命令行跑通确认帧格式和结束码没问题才允许它进上位机界面顺序反了往往会把界面调试和协议调试混在一起两头都痛苦。希望这份例子能帮你把 FINS 这条链路一次跑通少走那几趟弯路。本文还有配套的精品资源点击获取
简介面向C#开发者的欧姆龙PLC通信资源包演示如何通过FINS协议连接、读取和写入PLC寄存器数据覆盖帧构造、命令代码、响应解析等关键点适合工业自动化上位机开发人员、电气工程师和PLC通信入门者。包内共45个文件大小4.38MB核心是9个源代码文件含示例工程并配有通讯手册、协议截图、网络调试工具和课件文档方便对照报文逐帧学习。目前已有1117人学习说明这类互联需求在设备监控和数据采集中较为常见。下载后可直接用Visual Studio打开工程修改PLC的IP和寄存器地址即可运行通过抓包工具分析FINS请求与响应可快速掌握帧格式与命令码进而完成寄存器批量读写、状态轮询等任务。整套资料将协议规范、可运行示例和调试工具整合在一起能有效缩短从零搭建通信环境的周期适合作入门教程和项目参考。1. 项目定位一条 C# 上位机与 FINS 协议的通信链路车间里有一批设备状态要往 PC 上汇总PLC 用的不是通用的 Modbus TCP而是 FINS 报文协议。第一次接触 FINS 时我踩了不少坑明明 IP 能 ping 通指令发出去了PLC 就是不回包偶尔回了数值还是反的。这套 C# 例子把「通过 FINS 读取 PLC 内存区」这件事做成了最小可跑的工程直接基于 UdpClient 发送 0101 读取命令拿到响应后按字解析温度、压力、运行位等点位数据。它适合两类人一类是刚接手 C# 上位机、第一次碰 FINS 的开发者照着配置改 IP 和节点号就能跑通另一类是已经熟悉 PLC、想绕开厂家封装控件直接用裸协议做轻量采集的熟手。整份代码没有依赖第三方库读起来也不会被业务代码带偏。2. 工程骨架与报文结构拆开 FINS 帧的每个字节FINS 协议的报文并不复杂难点在于很多人把组帧、收发、解析全写在一个按钮事件里出了问题根本不知道是网络层、帧格式还是字节序的锅。这套工程从一开始就把通信和业务分开报文相关代码集中在FinsClient网络参数单独抽成配置类业务侧只负责维护点位列表。后面再改协议版本或者换 TCP 传输需要动的文件很有限。2.1 工程目录通信类、模型与配置分离工程是一个 .NET 6 控制台程序目录结构大致如下FinsDemo/ ├── Program.cs // 控制台入口负责轮询和日志 ├── FinsClient.cs // UDP 收发、组帧、拆帧、超时处理 ├── FinsNetConfig.cs // PLC IP、节点号、端口、超时配置 ├── FinsException.cs // 结束码转业务异常 ├── DataPoint.cs // 点位模型区域、地址、数据类型 ├── BatchReader.cs // 批量读取改造模块 └── appsettings.json // 网络参数与点位配置FinsClient只做一件事把调用方传入的「区域码 地址 读取个数」变成一条 FINS 读取命令发出去再把响应里的结束码和数据区解析出来。它不知道温度和压力是什么也不关心点位名称。BatchReader负责把一组点位合并成尽量少的读取请求降低轮询耗时。Program.cs负责定时循环、异常处理和日志输出这样每一层都能单独验证。这种分层看起来比一个Program.cs写到底笨实际排查问题时收益很大。第一次跑通后把FinsClient单独写单元测试就能确认帧格式没问题点位读不到值问题一定出在配置或 PLC 地址映射上不会互相甩锅。2.2 FINS 帧头ICF、节点号与 SID 怎么填FINS 的报文首部固定 10 个字节后面跟 2 字节命令码和命令参数。读取命令0101的参数是内存区代码 1 字节、起始地址 2 字节、读取字数 2 字节。所以一次 UDP 读取请求共 17 字节响应长度至少 14 字节数据区从第 14 字节开始。首部每个字节的含义和处理规则如下表偏移字段含义本工程取值0ICF信息控制字段0x80表示需要响应1RSV保留0x002GCT网关计数0x023DNA目标网络号0x00本地网络4DA1目标节点号PLC 的 FINS 节点号5DA2目标单元号0x00CPU 单元6SNA源网络号0x007SA1源节点号上位机自身 FINS 节点号8SA2源单元号0x009SID服务标识每次请求自增用于匹配响应DA1和SA1不是随便填的。很多 PLC 的以太网模块会把 FINS 节点号默认设成 IP 最后一段比如192.168.1.10对应节点号 10如果 PLC 被改过这里填错请求发出去没有响应。SID的作用是把当前请求和响应配对轮询频率一高SID 必须用完后自增或者随机变化不能永远填0x00否则调试时根本分不清回包对应哪条命令。2.3 UDP 与 TCP这个例子为什么默认走 UDP 9600FINS 协议在以太网上有两种常见传输FINS/UDP 和 FINS/TCP目标端口都是 9600。这份例子选 UDP不选 TCP原因有两点。第一FINS/UDP 的报文就是裸 FINS 帧抓包和拼帧都直观FINS/TCP 还要在帧前面套一截 8 字节的会话头第一次调试容易多包一层错。第二车间上位机采集场景通常是上位机主动发起请求PLC 被动响应UDP 的状态管理正好满足需求。UDP 的 9600 端口要求 PLC 以太网单元里开放 FINS UDP 服务默认都是开的。UdpClient本机端口不用刻意绑定到 9600只要能收 PLC 回包源端口由系统分配即可。如果现场网络环境差、丢包多再考虑换 FINS/TCP那一层改造在第六章会提到。3. 核心模块拆解一个读取请求从构造到解析的完整链路这一章把源码里的重点代码逐段拎出来讲。顺序按照一次读取请求的完整链路走初始化客户端、构造命令、发送并接收、解析响应字节序。看懂这几段其他区域码、写命令、批量读取都是同一套逻辑换参数而已。3.1 初始化客户端UdpClient 与网络参数的绑定通信类的构造函数接收一个FinsNetConfig配置对象里面包含 PLC IP、PLC 节点号、上位机节点号和超时时间。构造UdpClient后直接把套接字超时时间设好这样后面Receive阻塞时不会无限等下去。public sealed class FinsClient : IDisposable { private readonly UdpClient _udp; private readonly IPEndPoint _plcRemote; private readonly int _plcNode; private readonly int _localNode; private readonly int _timeoutMs; private readonly object _sync new object(); private byte _sid; public FinsClient(FinsNetConfig config) { _plcNode config.PlcNode; _localNode config.LocalNode; _timeoutMs config.TimeoutMs; _plcRemote new IPEndPoint(IPAddress.Parse(config.PlcIp), config.Port); _udp new UdpClient(); _udp.Client.ReceiveTimeout _timeoutMs; } }这里把_sync锁加上是因为后续同步收发方法会共享同一个UdpClient。一个连接内部维护一个自增 SID多线程同时发命令时如果没有这把锁SID 会互相覆盖接收方靠 SID 配对就乱了。锁的粒度是整个收发过程不是只锁 SID 自增保证请求和响应是一对一的关系。ReceiveTimeout的单位是毫秒配置里给 2000 代表 2 秒超时。现场 PLC 在大数据量读取或者总线负载高时响应可能变慢这个值要留足余量。上位机轮询越频繁越不要把超时压到 500 毫秒以内否则偶发的延迟会被误判成通信故障。3.2 构造读取命令内存区代码与 0101 命令的字节布局读取命令的核心是BuildReadCmd方法。0101是 FINS 的读命令码后面跟 5 个参数区域码、起始地址高字节、起始地址低字节、读取个数高字节、读取个数低字节。地址和个数都是二进制数不是 BCD 码拼字节时用移位和与操作。public byte[] Read(byte areaCode, int address, int count) { if (address 0 || address 0xFFFF || count 0 || count 0xFFFF) throw new ArgumentOutOfRangeException(nameof(address)); lock (_sync) { byte sid NewSid(); byte[] cmd BuildReadCmd(areaCode, address, count, sid); _udp.Send(cmd, cmd.Length, _plcRemote); byte[] resp ReadResponse(sid); return resp.AsSpan(14, count * 2).ToArray(); } } private byte[] BuildReadCmd(byte areaCode, int address, int count, byte sid) { byte[] cmd new byte[17]; cmd[0] 0x80; // ICF需要响应 cmd[1] 0x00; // RSV cmd[2] 0x02; // GCT cmd[3] 0x00; // DNA本地网络 cmd[4] (byte)_plcNode; // DA1目标节点号 cmd[5] 0x00; // DA2CPU 单元 cmd[6] 0x00; // SNA cmd[7] (byte)_localNode; // SA1源节点号 cmd[8] 0x00; // SA2 cmd[9] sid; // SID cmd[10] 0x01; // 命令码 0101 cmd[11] 0x01; cmd[12] areaCode; // 内存区代码 cmd[13] (byte)(address 8); // 地址高字节 cmd[14] (byte)(address 0xFF);// 地址低字节 cmd[15] (byte)(count 8); // 读取个数高字节 cmd[16] (byte)(count 0xFF); // 读取个数低字节 return cmd; } private byte NewSid() { _sid (byte)((_sid 1) 0xFF); return _sid; }读字指令常用的区域码是0x82DM 区、0xB0CIO 区、0xB1WR 区。DM区地址 0 对应 PLC 里的 DM0CIO区地址 500 对应 CIO 500不需要再乘 2因为这里按字寻址一个地址代表一个 16 位字。count表示读几个字想读两个连续字拼一个 32 位浮点数count 就填 2。如果把地址当成 BCD 码来拼比如 PLC 里显示D0100你直接填十六进制0x0100读回来的就是完全不对的区域。PLC 参数地址在 FINS 报文里就是二进制数一个int直接拆高低字节别做十进制转 BCD 的中间转换。3.3 解析响应结束码、SID 校验与数据切片ReadResponse负责收 UDP 包并校验。收到包之后先看包头里的 SID 是否等于本次请求的 SID不相等就继续收下一个包直到超时。再取第 12、13 字节作为结束码非 0 时直接抛FinsException。private byte[] ReadResponse(byte expectedSid) { while (true) { IPEndPoint remote new IPEndPoint(IPAddress.Any, 0); byte[] resp; try { resp _udp.Receive(ref remote); } catch (SocketException ex) when (ex.SocketErrorCode SocketError.TimedOut) { throw new TimeoutException($等待 PLC 响应超时SID{expectedSid:X2}); } if (!remote.Equals(_plcRemote) || resp.Length 14 || resp[9] ! expectedSid) continue; ushort endCode ReadUInt16BigEndian(resp, 12); if (endCode ! 0) throw new FinsException(endCode, ResolveMessage(endCode)); return resp; } } private static ushort ReadUInt16BigEndian(byte[] buffer, int offset) { return (ushort)((buffer[offset] 8) | buffer[offset 1]); }这里判断resp.Length 14是防御性校验。正常响应至少 14 字节10 字节帧头、2 字节命令码、2 字节结束码。如果收到的报文长度都不够说明抓到的可能不是 FINS 响应丢弃继续等。结束码的常见值有0x0000正常、0x1101区域或长度设定异常、0x1103地址设定异常、0x1203数据长度异常。真正要细抠时还是以 PLC 手册的结束码表为准不同机型个别码有差异。校验完 SID 和结束码后resp[14..]就是数据区。count个字的响应数据长度是count * 2字节切片后返回给上层做类型转换。这里有个容易忽略的点UDP 是可能收到杂包的调试时不要一收到数据就认定是本次响应SID 校验不能省。3.4 地址换算与数据类型DM 区偏移怎么变成 FINS 地址从上层视角看没人愿意每次调用都传0x82、地址、count 这些原始参数。于是我在FinsClient上加了几种常用类型的方法把 FINS 数据区还原成业务值。public ushort ReadWord(byte areaCode, int address) { byte[] data Read(areaCode, address, 1); return ReadUInt16BigEndian(data, 0); } public float ReadFloat(byte areaCode, int address) { byte[] data Read(areaCode, address, 2); uint raw ((uint)data[0] 24) | ((uint)data[1] 16) | ((uint)data[2] 8) | data[3]; return BitConverter.ToSingle(BitConverter.GetBytes(raw), 0); } public bool ReadBit(byte areaCode, int address, int bitIndex) { ushort word ReadWord(areaCode, address); return (word (1 bitIndex)) ! 0; }FINS 字数据在报文里是高字节在前而 C# 的BitConverter在绝大多数 PC 平台上是小端解析直接BitConverter.ToUInt16会把高低字节读反。上面代码用移位手动拼不依赖运行平台的大小端假设。一个实测场景PLC 里 DM100 存 100十六进制是00 64报文数据区是00 64如果用小端解析得到的是0x6400也就是 25600数值差了 256 倍。整条链路里所有字数据必须统一走一个解析入口不要写一半时手滑用BitConverter。浮点数按 IEEE 754 存储时占两个连续字四个字节网络序拼成uint再通过BitConverter.GetBytes中转成float。位读取先读整个字再按bitIndex位移判断。CIO区相对复杂的地方在于位地址带有小数比如 CIO 1.05 这种地址格式建议先转成「字地址 位索引」再调用ReadBit不要把小数直接乘 16 塞进 address。4. 避坑记录地址换算、字节序与响应码的 5 个翻车现场这一章是血泪经验的浓缩。FINS 协议本身不难难在细节下面五条基本覆盖了大多数人第一次跑通信时会遇到的情况。每条都按「现象 → 原因 → 解决」写方便对照。4.1 现象一网络能 ping 通PLC 就是不回包现象UdpClient.Send正常执行没有抛异常但Receive一直等到超时抓包只看到请求看不到响应。原因请求里的DA1和 PLC 实际配置的 FINS 节点号对不上。PLC 以太网单元里的 FINS 节点号可以手动设置不一定等于 IP 最后一段。还有一种情况是SA1填了 0PLC 侧开启了节点号校验看到源节点无效直接丢弃。解决先去 PLC 系统设定里读出当前 FINS 节点号把配置里的PlcNode改成它。上位机的LocalNode也最好设成和本机 IP 对应的值并且在 PLC 的 FINS 节点表里登记。如果只是做点对点测试至少保证本地节点号不是 0且和 PLC 没有冲突。改完还不行用抓包工具对比请求帧头里的DA1和SA1字节一眼就能看出来。4.2 现象二读回来的数值比触摸屏上大一倍或乱跳现象PLC 里 DM100 的值是 100上位机读出来变成 25600或者读 32 位浮点数时数值完全离谱。原因FINS 数据区按网络字节序传输高字节在前。C# 的BitConverter.ToUInt16默认按小端解析直接把00 64读成0x6400。解决字数据的解析统一用移位方式拼禁止在核心解析路径上直接BitConverter.ToUInt16。浮点数也按四个字节手工拼成uint再转。这个坑最容易排查也最容易犯关键是别只改一处要全类收口。从那以后我每次新增数据类型第一件事就是看它走没走统一的ReadUInt16BigEndian入口。4.3 现象三第一次读写正常之后偶发超时现象程序启动后第一次点动读写是好的轮询跑几圈突然出现一次超时下一次又自己恢复看起来像玄学。原因常见原因是 SID 没有变化每次都发 0x00。PLC 收到重复 SID 的请求时部分固件会当成重试报文处理回来的响应可能对应上一条命令导致上位机按照 SID 匹配失败。另一个隐藏原因是多线程共用一个UdpClientReceive却在另一个线程里处理响应被别的请求消费掉了。解决每条命令使用自增 SID接收侧强制校验 SID不匹配的包丢弃继续收。多线程调用同一FinsClient时必须把「自增 SID 发送 接收」放进同一个锁里。项目里如果并发要求高最简单干脆的办法是每个线程一个FinsClient实例互不干扰。4.4 现象四结束码报 0x1103 或 0x1101地址明明不大现象读取 DM 地址 1000 报地址异常或者读取连续 50 个字报区域超限。原因第一种是把地址当成 BCD 码拼了比如把十进制 1000 转成 0x1000 填入地址字段。第二种是 count 太大跨过了该内存区实际允许的最大地址。DM 区在几款小机型上末尾地址不同CIO 区的范围也受 CPU 型号限制理论值不等于实际值。解决确认地址按二进制拼取消一切 BCD 转换。然后从读 1 个字开始逐步把 count 往上加找到边界。很多 PLC 允许读的范围是连续的比如 DM 0 到 DM 5999但有些区段中间存在空隙一次读太大就会撞到边界。批量读取时先按连续段分组别图省事把跨几百个字的大区间一次读完。4.5 现象五同步收报卡死界面任务里又不敢随便 Sleep现象在 WinForms 的按钮事件里调用ReadWord点一下界面就白屏点几秒后恢复但整个程序像假死。原因UdpClient.Receive是同步阻塞调用界面线程被卡在等 PLC 回包上。超时 2 秒还好如果配置成 10 秒界面就得卡 10 秒。解决UI 线程不要直接调通信方法。把轮询放进Task.Run或者独立的后台采集服务里界面通过事件、INotifyPropertyChanged或消息队列更新。通信类内部用ReceiveTimeout控制阻塞上限不要在超时处理里再写Thread.Sleep(50)之类的重试逻辑超时返回后直接进入下一次轮询即可。5. 改造示例批量轮询、配置化地址表与异常重连跑通单点读取只是第一步。把这份例子接到真实设备上时一般还要做三件事减少请求次数、把点位配置从代码里挪出去、让采集服务断线后自己恢复。这一章的改造代码在原工程里都有可以直接抄。5.1 从单点读取改成批量读取一次请求读多个字单点读取的问题是每个点位一次 UDP 请求100 个点位就是 100 次每次往返哪怕只有 2 毫秒一轮也要 200 毫秒。FINS 读取命令本身支持一次读多个连续字所以按区域分组后把同一区域里离得近的点位合成一段一次读完再按偏移切给各个点位。public Dictionarystring, object ReadBatch(IReadOnlyListDataPoint points) { var result new Dictionarystring, object(); foreach (var group in points.GroupBy(p p.Area)) { byte area group.Key; var ordered group.OrderBy(p p.Address).ToList(); var segments new ListListDataPoint(); foreach (var point in ordered) { if (segments.Count 0 || point.Address - segments.Last().Last().Address 16) { segments.Add(new ListDataPoint()); } segments.Last().Add(point); } foreach (var segment in segments) { int min segment.Min(p p.Address); int max segment.Max(p p.Address p.Count); byte[] block _client.Read(area, min, max - min); foreach (var point in segment) { int offset (point.Address - min) * 2; byte[] slice block .Skip(offset) .Take(point.Count * 2) .ToArray(); result[point.Name] ConvertSlice(slice, point.Type); } } } return result; }分段阈值 16 是经验值。两个点位地址相隔不超过 16 个字时合并一次读超过就断开这样既不会把区间拉得太长也不会频繁触发单点请求。ConvertSlice内部根据DataPoint.Type把切片转成ushort、int、float或bool它和第三章的数据解析方法是一套逻辑。这种批量读法的收益在点位密集时很明显。比如一组模拟量点都放在 DM 区连续地址里原来 20 次 UDP 往返能缩到 1 次轮询周期从秒级降到百毫秒级。代价是每次读取的块变大如果点位分布太散合并的收益反而被超时风险抵消所以分段阈值要按实际点位分布调。5.2 配置化地址表用 JSON 管理点位硬编码点位名称和地址改起来太痛苦而且换一台设备往往只是换几个地址。我把点位配置挪到appsettings.json里程序启动时反序列化成ListDataPoint。{ Plc: { Ip: 192.168.1.10, PlcNode: 10, LocalNode: 100, Port: 9600, TimeoutMs: 2000 }, Points: [ { Name: Pressure, Area: DM, Address: 100, Count: 1, Type: Word }, { Name: SetTemp, Area: DM, Address: 120, Count: 2, Type: Float }, { Name: RunSignal, Area: CIO, Address: 500, Count: 1, Type: Bool } ] }Area字符串到内存区代码做一层映射DM - 0x82CIO - 0xB0WR - 0xB1。DataPoint里同时保存Count和TypeCount决定切多少个字节Type决定用什么解析器。这样新增一个采集点位只改 JSON不动代码。如果点位表格是从 Excel 或数据库里来的也可以直接把这张表换成 SQL 查询结果ReadBatch不变。配置化之后要特别注意一点Address属性不要写成 PLC 上位机里的显示地址统一写成 FINS 原始地址。比如有些触摸屏显示D0100但 FINS 地址就是 100有些软件把 CIO 500 显示成CIO500.00但字地址还是 500。写进 JSON 之前先在 PLC 手册里核对区域和地址范围。5.3 异常重连与日志让采集服务能过夜现场程序没人天天盯着通信模块必须能在超时后自己恢复。常见的做法是循环里捕获超时异常重建UdpClient等待一小段时间再继续。重建连接的成本很低比反复复用同一个半死状态的 socket 更可靠。while (!cts.IsCancellationRequested) { try { var values _batchReader.ReadBatch(_points); _logger.LogValue(values); } catch (TimeoutException) { _logger.Write(PLC 响应超时准备重连); _client.Dispose(); _client new FinsClient(_config); _batchReader.UpdateClient(_client); await Task.Delay(2000, cts.Token); } catch (FinsException ex) { _logger.Write($FINS 异常{ex.Message}); await Task.Delay(1000, cts.Token); } await Task.Delay(_intervalMs, cts.Token); }重连前必须把旧的UdpClient释放掉否则旧 socket 上的缓存响应可能干扰新会话。FinsException里如果结束码表示的是点位地址写错重连没用所以日志里一定要带上原始地址、区域码和 count。日志尽量写成结构化文本至少包括时间、点位名、原始值和结束码。现场排查超时问题时时间戳能帮判断是 PLC 周期性抖动还是数据量大导致的固定延迟。日志里另一个容易被忽略的指标是「每轮实际耗时」。在ReadBatch前后各记一个时间戳跑一段时间就能看出通信链路是否稳定。五十个点位正常 80 毫秒读完突然变成 500 毫秒大概率是网络有重传这时候再优化读取段大小才有方向。6. 二次开发建议从跑通到改造成自己的采集程序拿到这份源码建议先不要急着加业务按下面顺序做三轮改造每一步都能独立验证。先扩展FinsClient把写命令0102加上。写法就是把命令码改成0x01 0x02参数在原来读取命令的基础上追加待写数据区域码、地址和字数的拼法和读取一致。我只建议第一步就加写命令因为这个通信用途不只是单向采集设备启停、设定值下发都需要写。再对照实际 PLC 型号确认内存区代码表。小机型的 CIO、WR、DM 区域范围和大机型不一样尤其是扩展数据区。把配置里不存在的区域提前在启动时做一次字典检查能挡住一半手滑填错地址的现场故障。最后按这个清单做一轮回归验证项预期结果修改 IP、节点号后启动无超时异常控制台正常打印点位值读取 DM 浮点量数值与 PLC 侧编程软件一致人为拔掉网线再插回2 秒超时后进入重连恢复后继续采集连续运行 8 小时日志无 SID 错配无累计卡死修改 JSON 后重启程序新点位立即生效不需要重新编译从那次以后我每次拿到一个没见过的 PLC 型号都会先把内存区地址范围和字节序确认清楚再往工程里填点位。先用最朴素的命令行跑通确认帧格式和结束码没问题才允许它进上位机界面顺序反了往往会把界面调试和协议调试混在一起两头都痛苦。希望这份例子能帮你把 FINS 这条链路一次跑通少走那几趟弯路。本文还有配套的精品资源点击获取
