简介一份面向C#开发者的欧姆龙PLC通信示例资源围绕FINS协议的上位机数据交互展开适合需要实现远程读写PLC寄存器、解析通信帧的工业自动化开发者。压缩包共45个文件整体约4.38MB其中C#源码可用来直接修改调试通讯手册与协议格式图能帮助理解FINS帧结构网络调试工具与课件则便于边学边验证。目前已有1114人学习下载。示例工程从TcpClient连接PLC开始逐步演示按FINS协议组包发送请求、读取响应并解析数据的基础流程同时覆盖了常用命令代码、寄存器地址映射、字节序处理与典型错误排查读者可结合附带文档快速迁移到实际项目中。 接手过不少和欧姆龙PLC打交道的项目基本每次都要和FINS协议碰面。这个协议在欧姆龙整个 PLC 家族里兼容性极好从老款的CP系列到NJ/NX系列甚至几十年前的C系列只要网口支持基本都能通过FINS进行通讯。而C#做上位机又是工业现场最常见的组合所以今天这篇就把我实际项目里怎么用C#通过FINS协议读取欧姆龙PLC数据的完整路子捋一遍包含协议细节、代码实现、还有那些容易让人栽跟头的坑。这篇文章主要面向的是刚开始接触欧姆龙通讯的上位机开发工程师或者是在实验室里被PLC折腾得头疼的调试人员。如果你已经会用FINS但总被某些细节卡住比如地址计算不对、数据读出来不对位那这篇文章里的踩坑记录应该也能帮上忙。我尽量把协议层的东西讲得通俗些毕竟FINS报文结构初见时真有点劝退但摸清楚规律之后会发现它其实设计得相当规整。1. FINS协议是什么以及为什么要选它1.1 FINS和上位机通讯的主流方式先明确一个概念FINS是富士通Fujitsu和欧姆龙共同制定的工业网络协议全称是Factory Interface Network Service它不依赖特定的物理层可以跑在以太网FINS/UDP、FINS/TCP、串口、甚至Controller Link等网络上。对于C#上位机来说最常用的是FINS/UDP因为UDP无连接、速度快适合周期性读取数据的场景。很多人在选通讯方式时会纠结是走HostLink串口还是FINS或者干脆用欧姆龙自带的OPC UA服务器。我的建议是如果只是本地局域网内、数据量不大、需要快速响应的上位机FINS/UDP是最优解。HostLink需要确认串口参数还要处理帧校验繁琐且速度上限低OPC UA虽然配置方便但要在PLC里启用服务对老型号PLC不友好而且引入额外中间件的开销。FINS则是一个“裸协议”你只要能发UDP报文就能和PLC对话掌控力最强。1.2 FINS/UDP和FINS/TCP怎么选FINS支持UDP和TCP两种传输方式。TCP因为有连接管理适合需要可靠传输、数据量大的场景比如上传下载程序或大块数据。但UDP在轮询场景下性能更好而且FINS协议本身在应用层有结束码End Code和重试机制只要处理好超时和重发可靠性并不差。实际项目里我一般默认用UDP 9600端口PLC侧不需要额外配置连接上位机电脑只要和PLC在同一网段就能通讯。FINS/TCP则需要先建立TCP连接做握手PLC侧要配置TCP端口号调试起来稍麻烦一点。还有一个细节是FINS/UDP允许广播可以快速搜索网络上所有支持FINS的设备这在现场不知道PLC IP时非常好用。2. 通讯前的准备工作与关键参数2.1 欧姆龙PLC侧的设置在写任何代码之前必须先确认PLC的网络参数。连上CX-Programmer老款PLC或Sysmac StudioNJ/NX系列在“设置 - 内置以太网端口”里能看到IP地址、子网掩码和FINS节点号。FINS节点号是协议层标识设备的编号范围是1到254默认通常跟着IP地址最后一组走比如IP是192.168.1.10节点号一般就是10。这个对应关系不是强制的但强烈建议保持一致否则调试时会把自己绕晕。另一个必须确认的是PLC的FINS/UDP服务是否开启。在CX-Programmer的以太网设置里有一个“FINS UDP”选项默认是启用的端口号固定9600。有些项目里为了安全可能会把服务关掉或修改端口如果上位机连不上首先要检查这里。2.2 上位机侧的网络准备电脑这边其实没什么特殊配置只要和PLC在同一网段就行。但要注意如果PLC的IP是192.168.1.10电脑是192.168.1.20子网掩码都是255.255.255.0那没问题。如果现场网络复杂有多个网卡要确保发送UDP报文的网卡IP确实在PLC同一网段否则报文发出去了PLC收不到。还有一个在实际项目中很容易被忽视的变量就是Windows防火墙。开发机上第一次跑FINS通讯程序时经常出现发送成功但收不到响应的情况。排查下来大概率是防火墙拦了UDP 9600端口的入站数据。解决办法很简单要么在防火墙高级设置里加一条入站规则放行UDP 9600要么把程序加入白名单。我用的是后者因为项目里上位机程序经常要部署到多台机器加入白名单比手工配规则省事。2.3 FINS节点号与IP的关系再展开说说FINS节点号。FINS报文头里有个DA1和SA1字段分别代表目标节点PLC和源节点上位机。这两个字段都是单字节范围1到254。PLC在收到UDP报文后会根据报文的源IP地址和FINS节点号来验证是不是合法的通讯对象。有个常见误区是认为节点号必须等于IP最后一段。其实PLC侧只是把FINS节点号和IP地址做了一层映射这个映射关系在PLC网络设置里是隐含的默认规则就是“IP最后一段 节点号”。如果你改过PLC的节点号而上位机代码里还是用IP最后一段那PLC收到报文后发现DA1不匹配会直接丢弃。所以代码里有没有设置源节点号以及设置的数值是否和PLC网络配置一致就特别关键。我写的每个FINS请求里SA1用的都是本机IP最后一段同时DA1是PLC节点号这样基本不会踩坑。3. FINS报文结构与指令解析3.1 一帧FINS/UDP报文的完整解剖FINS/UDP报文结构其实不复杂总共分两大部分FINS帧头10字节和FINS命令数据长度不定。帧头固定包含以下字段ICF信息控制字段1字节决定是命令还是响应是请求还是不需要响应。上位机发命令时通常设为0x80表示“需要响应”。RSV保留字段1字节固定0x00。GCT网关计数1字节固定0x02表示允许经过2个网关。DNA目标网络地址1字节0x00表示本地网络。DA1目标节点号1字节就是PLC的FINS节点号。DA2目标单元号1字节0x00表示CPU单元。SNA源网络地址1字节0x00表示本地网络。SA1源节点号1字节上位机的FINS节点号。SA2源单元号1字节0x00表示CPU单元。举个实际例子假设PLC节点号是10上位机节点号是20那么帧头就是80 00 02 00 0A 00 00 14 00 00这里0A是10的十六进制14是20的十六进制。每次组报文时这几字节基本都是模板只有DA1和SA1会变。3.2 读DM区数据的核心指令和参数帧头后面是命令数据。最常见的操作是读DM区数据存储器数据命令码是0x0101代表“内存区读取”。这条命令的参数包括内存区代码1字节DM区是0x82CIO区是0xB0WR区是0xB1HR区是0xB2。起始地址2字节比如要读D100地址就是100的十六进制0x0064。读取长度2字节要读几个字16位比如读10个字就是0x000A。于是完整的读D100起10个字的命令数据就是01 01 82 00 64 00 0A把帧头10字节和命令数据拼起来发给PLCPLC会返回一帧响应。响应帧的帧头12字节比命令帧多2字节的结束码其中结束码位于第13、14字节0x0000表示正常其他值就是错误码。正常响应后面跟着你要的数据也是按大端字节序排列每两字节一个字。3.3 CIO区、WR区、HR区的地址计算DM区的地址计算很直观起始地址就是字编号。但CIO区稍微复杂点因为它的编号不是连续的数字。CIO区包含输入输出继电器区CIO 0~CIO 99、内部继电器区CIO 1000~CIO 2999等访问时起始地址直接填编号就行比如要读CIO 1000地址就是0x03E8。WR区工作区的编号是W0到W511转换成地址时直接用编号起始地址就是0x0000到0x01FF。HR区保持区是H0到H511同理。这里有个常见坑有些资料里会把CIO区的起始地址加一个偏移量比如从CIO区读时地址要加0x8000因为某些老的欧姆龙PLC内部映射如此但对NJ/NX和较新的CP系列来说不需要这个偏移。如果你照着老代码抄可能在新型号上读出来的数据全是错的。最靠谱的办法是在CX-Programmer的地址帮助里查一下你用的PLC型号具体怎么映射。3.4 位读取指令0x0102的使用除了读字还经常要读位比如某个传感器的通断状态。FINS读取位的指令是0x0102参数格式略有不同内存区代码后面跟的是“位地址”一个3字节的数值前2字节是字地址最后一字节是位号0-15。也就是说如果我想读D100.05实际发送的起始地址是0x0064 * 16 0x05即0x0645然后再补一位长度。这样读出来的数据是一个16位的值但只用到最低位0代表OFF1代表ON。位地址换算的公式是word_address * 16 bit_number。比如W10.03就是10 * 16 3 163十六进制0x00A3。读位时读取长度单位是“位”最多可以一次读多个连续的位但我一般读单个位简单直接不易出错。4. C#实现FINS/UDP通讯的完整代码4.1 基础Socket封装类下面这段代码是我项目里一直在用的基础通讯类核心就三件事根据IP和节点号组FINS帧头、执行UDP收发、解析响应提取数据。没有用任何第三方库纯C#的UdpClient就能跑起来。using System; using System.Net; using System.Net.Sockets; using System.Threading.Tasks; public class FinsUdpClient { private UdpClient _udpClient; private IPEndPoint _plcEndPoint; private int _timeout 2000; // 毫秒 public byte PlcNode { get; set; } 10; // PLC FINS节点号 public byte LocalNode { get; set; } 20; // 本机 FINS节点号 // 初始化连接 public void Connect(string plcIp, int port 9600) { _udpClient new UdpClient(); _plcEndPoint new IPEndPoint(IPAddress.Parse(plcIp), port); _udpClient.Connect(_plcEndPoint); } // 发送命令并接收响应超时抛出异常 private byte[] SendReceive(byte[] command) { // 组FINS帧头长度为10 byte[] frame new byte[10 command.Length]; frame[0] 0x80; // ICF需要响应 frame[1] 0x00; // RSV frame[2] 0x02; // GCT frame[3] 0x00; // DNA frame[4] PlcNode; // DA1 frame[5] 0x00; // DA2 CPU单元 frame[6] 0x00; // SNA frame[7] LocalNode; // SA1 frame[8] 0x00; // SA2 frame[9] 0x00; // SID命令ID随意但每次最好不同 Buffer.BlockCopy(command, 0, frame, 10, command.Length); _udpClient.Send(frame, frame.Length); var task _udpClient.ReceiveAsync(); if (!task.Wait(_timeout)) { throw new TimeoutException(接收PLC响应超时); } return task.Result.Buffer; } // 解析响应中从第13字节开始的数据区 private byte[] GetResponseData(byte[] response) { if (response.Length 14) throw new Exception(响应帧长度无效); ushort endCode (ushort)((response[12] 8) | response[13]); if (endCode ! 0) throw new Exception($PLC返回错误码: 0x{endCode:X4}); // 正常响应中数据从第14字节开始 byte[] data new byte[response.Length - 14]; Buffer.BlockCopy(response, 14, data, 0, data.Length); return data; } // 读取连续字地址如D100读10个字 public ushort[] ReadWords(byte memoryCode, ushort startAddress, ushort length) { byte[] command new byte[8]; command[0] 0x01; // 命令码 01 01 command[1] 0x01; command[2] memoryCode; command[3] (byte)(startAddress 8); command[4] (byte)(startAddress 0xFF); command[5] (byte)(length 8); command[6] (byte)(length 0xFF); command[7] 0; // 填充因为0101命令只要7字节? 实际是7字节去掉第8位这里修正 byte[] response SendReceive(command); byte[] data GetResponseData(response); ushort[] result new ushort[length]; for (int i 0; i length; i) { result[i] (ushort)((data[i * 2] 8) | data[i * 2 1]); } return result; } public void Close() { _udpClient?.Close(); } }注意上面代码里有一处要修正命令数组长度定义多了。FINS内存区读取命令真实长度是7字节命令码2字节内存区代码1字节起始地址2字节长度2字节不需要第8字节。我把那段放出来就是想强调这类小细节太容易写错编译不报错但报文发过去PLC直接回错误码。4.2 读取DM区数据的实际调用示例使用上面这个类读取D100到D109这10个字代码非常简洁var fins new FinsUdpClient(); fins.PlcNode 10; fins.LocalNode 20; fins.Connect(192.168.1.10, 9600); try { ushort[] values fins.ReadWords(0x82, 100, 10); for (int i 0; i values.Length; i) { Console.WriteLine($D{100 i} {values[i]}); } } catch (Exception ex) { Console.WriteLine(通讯失败: ex.Message); } finally { fins.Close(); }这里面有个容易迷惑的点ReadWords的第二个参数startAddress填的是十进制字地址100而不是十六进制0x0064。因为在方法内部已经做了高字节和低字节的拆分外部传入的人类可读的十进制数就好。但这里要留神如果读的是CIO区或WR区地址编号本身可能不是从0开始传入的时候一定要确认这个“编号”和PLC侧显示的编号是一致的。4.3 读取位状态的实现读取位时命令码变成0x0102起始地址需要换算成“位地址”。换算方法就是前面说的字地址乘以16加位号。长度是位个数最大好像是255还是多少我一般读单个位。public bool ReadBit(byte memoryCode, ushort wordAddress, byte bitIndex) { // 计算位地址字地址*16 位号 ushort bitAddress (ushort)(wordAddress * 16 bitIndex); byte[] command new byte[7]; command[0] 0x01; // 命令码 01 02 command[1] 0x02; command[2] memoryCode; command[3] (byte)(bitAddress 8); command[4] (byte)(bitAddress 0xFF); command[5] 0x00; // 读取长度 1位 command[6] 0x01; byte[] response SendReceive(command); byte[] data GetResponseData(response); // 响应数据是一个16位值只有最低位有效 return (data[0] 0x01) 0x01; }这个方法我在现场用来监视设备状态时用得很频繁。每100ms轮询一次几十个IO点的状态UDP方式压力不大没出现丢包的情况。4.4 批量读取与按位组装工业现场的数据很少是单个字独立使用的通常是一个数据块。比如我遇到过一台包装机D100到D109存的是10个温度值Int16D110是设备状态字每一位代表一个报警这种场景下批量读取是必须的。批量读不仅减少通讯次数也降低PLC的通讯负载。读回来之后如果要提取状态字中的某一位可以这样处理ushort status values[10]; // D110 bool alarm1 (status 0x0001) 0x0001; bool alarm2 (status 0x0002) 0x0002; bool alarm3 (status 0x0004) 0x0004;这种“按位与”的方式很直观不用额外调FINS位读取指令。我要提醒的是欧姆龙PLC的数据类型中大端存储UDP报文中也是高字节在前所以上面代码里读出来直接拼成ushort没问题。但如果涉及32位整数或浮点数就要额外处理字节顺序。5. 数据类型转换与多寄存器拼接5.1 大端字节序的处理FINS协议遵循大端字节序高字节在前这和x86架构的小端正好相反。上面的ReadWords方法拼接时已经处理了这一点(data[i * 2] 8) | data[i * 2 1]把高字节放到前面低字节放后面得到正确的ushort。但如果你读两个相邻的寄存器想拼成一个uint32位无符号整数顺序就要特别注意。PLC侧如果存储的是一个无符号32位整数比如某些累计量那么D100是高16位D101是低16位。拼的时候应该是uint value32 (uint)((values[0] 16) | values[1]);如果是带符号的32位整数或者浮点数还要再做一步转换。浮点数的处理稍微复杂些FINS协议会按照IEEE 754存储先高字后低字拼好后直接BitConverter.ToSingle就能拿到结果byte[] floatBytes new byte[4] { (byte)(values[0] 8), (byte)(values[0] 0xFF), (byte)(values[1] 8), (byte)(values[1] 0xFF) }; float temperature BitConverter.ToSingle(floatBytes, 0);5.2 无符号、有符号和浮点的转换策略工业数据里最常见的三种数据类型是INT16位有符号、DINT32位有符号和REAL32位浮点。INT直接强转short即可short s (short)values[i]。DINT需要把两个相邻ushort拼成uint再转int。如果是负数直接按位运算就能得到补码不需要额外处理。REAL上面已经写了拼4字节转float。我在项目里写过一个辅助类专门处理这些转换避免在业务代码里到处堆位运算。如果你也经常和数据转换打交道强烈建议封装成公共方法不然现场调试时临时去推字节顺序太容易出错。5.3 字符串数据的读取ASCII和Unicode有些PLC程序会把操作员信息、批次号等字符串存到DM区。读取方式和其他数据一样只是转换方式不同。如果字符串是ASCII编码每个字符占1字节两个字符拼在一个字里高字节是第一个字符。比如D100存的是字符“AB”实际就是0x4142。读取代码一般是把返回的字节序列直接转成字符串byte[] data ...; // 从响应中提取的原始数据 string asciiText Encoding.ASCII.GetString(data); // 去掉末尾的空白字符 asciiText asciiText.TrimEnd(\0, );如果是UnicodeUTF-16每个字符占2字节和ushort是等长的直接用Encoding.Unicode.GetString转换原始字节序列即可。这里要注意欧姆龙的部分老型号PLC处理Unicode时字节序可能会和C#默认的UTF-16LE不一样如果读出来乱码试试把每个字的字节序反转一下再转。另外一个经验PLC里存的字符串长度往往是固定的比如“MODEL_NO”可能占用20个字节实际内容只有6个字符后面全是0x00。这时候TrimEnd就必须有不然输出会带一串调试符号。6. 长连接与多线程轮询架构6.1 单次请求和持续轮询的设计差异很多初学者一开始是“读完一次就关掉Socket”这在Demo里没问题但工业现场不行。PLC通讯讲究长连接UDP虽然本身无状态但你的UdpClient实例如果每次都new、每次都是新端口PLC侧根据源端口来判断通讯对象频繁更换端口可能导致一些问题。更关键的是每次new UdpClient都涉及系统资源的分配和释放高频轮询下性能会很差。我的做法是在程序启动时创建FinsUdpClient并连接整个生命周期里复用同一个实例直到程序退出才关闭。这样源端口固定PLC侧通讯日志也稳定排错容易。6.2 使用异步方法避免UI卡顿如果你在WinForms或WPF里直接用同步方法轮询界面会卡到你怀疑人生。我见过不少同事犯这个错定时器里调用ReadWords数据量一大界面直接无响应。这是因为UI线程被阻塞在Socket等待上了。解决办法有两个一是用async/await配合UdpClient.ReceiveAsync()二是把轮询放到后台线程再用Invoke或BeginInvoke更新UI。我个人更推荐前者代码结构清爽不容易出现跨线程访问UI控件的问题。改造后的SendReceive方法只需要把task.Wait改成await task再把方法签名改成async Taskbyte[]即可。private async Taskbyte[] SendReceiveAsync(byte[] command) { // 组帧省略... await _udpClient.SendAsync(frame, frame.Length); var result await _udpClient.ReceiveAsync(); return result.Buffer; }然后在按钮事件或定时器事件里private async void Timer_Tick(object sender, EventArgs e) { try { var values await _fins.ReadWordsAsync(0x82, 100, 10); lblValue.Text values[0].ToString(); } catch (Exception ex) { lblStatus.Text 通讯异常: ex.Message; } }这一改动直接让UI刷新从“卡成PPT”变成了“流畅如丝”。之前热词里提到的“循环数据采集和UI刷新卡顿”几乎都是因为这个原因。6.3 轮询频率与超时重试策略轮询频率要看PLC的扫描周期和通讯负载。一般DM区读10个字以内建议间隔100ms以上太频繁会给PLC的通讯任务增加负担。如果是几十个字的大块读取间隔200ms比较稳妥。超时设置我习惯用2000ms如果连续3次超时基本可以判断网络或PLC出问题了这时候程序要给出明确提示而不要无限重试。代码里可以记录连续失败次数达到上限后就停止自动重连等操作员人工介入。还有一个实用技巧为每个FINS命令生成不同的SID命令ID这样即使响应乱序或迟到了也能在应用层判断这条响应对应哪条命令。我的多线程项目里会用到这个机制单线程轮询其实无所谓但养成好习惯没坏处。7. 易错点地址偏移、响应延迟与设备离线7.1 常见FINS错误码速查FINS协议里PLC返回的错误码能告诉我们很多信息。我整理过一份出现频率最高的错误码贴在这里方便大家快速排查错误码含义可能原因0x0000正常无0x1101内存区代码错误请求了不存在的内存区0x1103地址错误起始地址超出范围或未按字对齐0x110B长度错误请求读取长度超过上限0x2002数据被保护PLC设置了数据保护无法读写0x2003数据不存在命令中指定的地址无实际数据0x2101通讯节点错误DA1、SA1节点号配置不匹配0x2102目标节点不存在PLC节点号实际不存在0x2103目标节点无响应网络不通或PLC忙7.2 地址偏移与数据类型错位的实际案例有一次我读取一个NJ501的PLC程序里明确写了要读D100开始的20个字但读回来前两个数是零第三个才开始有数据。排查了半天发现组态时PLC的DM区起始被改成了D2000D100属于系统保留区根本没被用户程序使用。这就是典型的“PLC侧变量映射和上位机不一致”问题。后来我在项目里定了个规矩上位机要读的数据地址必须以PLC工程师提供的符号表或者地址映射表为准绝不自己拍脑袋猜。还有一个案例是关于CIO区偏移的。有台设备是CP1H的PLC我按资料写CIO区读地址是0x0000读出来全不对。后来发现CP1H的CIO区在FINS报文里的实际地址偏移是0x8000也就是CIO0在协议层其实是0x8000。这个偏移不是所有系列都一样所以遇到老型号PLC时要多一个心眼实测通了再固化代码。7.3 设备离线检测与自动重连上位机最怕的就是设备突然离线后程序没有感知一直报超时错误也没有重连机制。我的做法是维护一个“通讯健康状态”标志每次成功收发一帧就置位连续超时达到阈值就标记离线停止轮询改用重连检测线程。重连线程每隔2秒发一次“读CPU状态”的命令命令码0x0501一旦成功就自动恢复轮询。这样整个架构非常稳定操作员无需重启上位机程序。代码实现不复杂核心就是在FinsUdpClient里增加一个IsOnline属性和一个ReconnectAsync方法。8. 多PLC通讯与内存区间读写扩展8.1 对接多台PLC的地址管理一个工位多台PLC很常见比如一台主PLC加两台从PLC。FINS的节点号不同对应不同的DA1。我的做法是把FinsUdpClient封装成一个字典按工位名称或PLC名称索引每个PLC实例管理自己的IP、节点号和Socket。Dictionarystring, FinsUdpClient plcClients new Dictionarystring, FinsUdpClient(); plcClients[main] new FinsUdpClient { PlcNode 1, LocalNode 20 }; plcClients[main].Connect(192.168.1.1); plcClients[sub] new FinsUdpClient { PlcNode 2, LocalNode 20 }; plcClients[sub].Connect(192.168.1.2);这里要注意多个FinsUdpClient实例的源节点号不能相同否则PLC无法区分请求来源。最好每个上位机固定用一个唯一的节点号所有PLC都共用一个SA1这样PLC侧做权限控制也方便。8.2 写操作指令0x0102之外的0x0103和0x0104读指令讲完了写指令其实套路一样只是命令码和参数不同。写单个字用0x0103写多个字用0x0104。比如向D200写入数值12345命令是01 03 82 00 C8 30 39这里的30 39是12345的十六进制0x3039按大端拆成两个字节放在最后。响应帧结束码为0x0000代表写入成功。实操中写操作比读操作更需要谨慎尤其是写多个字时地址一旦写错可能覆盖PLC的关键数据。所以我的习惯是写操作单独封装一个方法加一个确认参数必须显式传入true才允许执行。8.3 扩展内存区EM区的访问方法欧姆龙部分PLC有扩展内存区EM区分为多个bank。访问EM区时内存区代码不是固定的0x98而是会根据bank号变化内存区代码是0x98加上bank号。比如访问EM0区代码是0x98访问EM1区代码是0x99。因为bank号最多到32767而内存区代码只有1字节所以规则是0x98 bank号 % 256这个说法不准确实际是当bank号超过255时需要用FINS的扩展命令0x0101的附加参数来指定比较复杂。我的经验是普通项目很少用到超过8个bank直接用0x98到0x9F就能覆盖EM0~EM7。真遇到大bank场景建议直接问PLC工程师要协议文档别自己瞎试。9. 进程异常、杀毒软件与防火墙的坑9.1 杀毒软件拦截FINS通信的处理工业电脑装杀毒软件是个矛盾体安全部门要求装但杀毒软件经常把工业通讯软件的网络行为当威胁处理。我碰到过最诡异的一次是程序运行正常但每隔几分钟就断连一次查了半天发现是杀毒软件在后台做网络扫描把UDP端口占用了一会儿。解决方式很直接在杀毒软件里把上位机程序的整个目录加入白名单或者是把PLC的IP段加入信任区。如果安全政策不允许那就只能用TCP方式通讯TCP的稳定性和杀毒软件的兼容性会好些但代价是PLC侧增加连接开销。9.2 防火墙规则设置与端口开放Windows防火墙默认拦截所有入站UDP如果你的PLC主动向上位机发数据比如FINS的主动通知功能就必须在防火墙里放行9600端口。如果只是上位机主动轮询理论上不需要入站规则但要留意某些防火墙配置会把未授权的UDP回包也拦掉。最省事的做法是把上位机程序加入防火墙白名单允许所有网络或者单独开放UDP 9600端口入站。我在部署文档里都会写明这两步省得现场挨个查。9.3 双网卡电脑的绑定问题工业电脑经常是双网卡一个连办公网一个连设备网。这时如果上位机默认路由走了办公网网卡UDP报文就可能发不到PLC。现象就是程序里Send不报错但PLC收不到或者PLC回了但收不到。解决办法是在UdpClient绑定到特定的本地IP把new UdpClient(new IPEndPoint(本地IP, 0))作为构造函数这样发送时源IP就是设备网卡的IP报文路由自然走对网卡。这一点真的要重视我第一次在现场碰到这问题时排查了好久。10. 从一个Demo到可靠通讯的一点心得从能读到D100的数据到能稳定地在生产线上跑几个月不出问题中间差的不是协议知识而是异常处理、日志记录、超时重试和状态监控这些“工程化”的功夫。FINS协议本身不复杂但工业通讯的环境比开发环境复杂得多。我在实际项目中还发现日志记录比什么都管用。每条FINS命令的收发时间、耗时、响应码都记下来出问题时翻日志一目了然。用现成的日志库比如NLog或者简单写个文本日志类都行但一定要带时间戳。我现在维护的这套上位机系统就是靠日志锁定了三四个偶发问题比如PLC重启期间上位机连续发命令被丢弃、某个时间段网络延迟突然变高导致3次重试后才成功这些都是没有日志时根本无从查起的问题。最后再分享一个我在C#实现FINS时的小技巧把FINS报文组帧过程单独抽成一个FinsFrameBuilder类所有命令帧都从这生成这样万一日后要加新指令比如写操作、CPU状态查询只需在builder里加方法不用改动通讯核心。通讯核心慢慢沉淀下来几个项目都能复用省下不少事。本文还有配套的精品资源点击获取 C#通过FINS协议读取欧姆龙PLC数据实战指南
简介一份面向C#开发者的欧姆龙PLC通信示例资源围绕FINS协议的上位机数据交互展开适合需要实现远程读写PLC寄存器、解析通信帧的工业自动化开发者。压缩包共45个文件整体约4.38MB其中C#源码可用来直接修改调试通讯手册与协议格式图能帮助理解FINS帧结构网络调试工具与课件则便于边学边验证。目前已有1114人学习下载。示例工程从TcpClient连接PLC开始逐步演示按FINS协议组包发送请求、读取响应并解析数据的基础流程同时覆盖了常用命令代码、寄存器地址映射、字节序处理与典型错误排查读者可结合附带文档快速迁移到实际项目中。 接手过不少和欧姆龙PLC打交道的项目基本每次都要和FINS协议碰面。这个协议在欧姆龙整个 PLC 家族里兼容性极好从老款的CP系列到NJ/NX系列甚至几十年前的C系列只要网口支持基本都能通过FINS进行通讯。而C#做上位机又是工业现场最常见的组合所以今天这篇就把我实际项目里怎么用C#通过FINS协议读取欧姆龙PLC数据的完整路子捋一遍包含协议细节、代码实现、还有那些容易让人栽跟头的坑。这篇文章主要面向的是刚开始接触欧姆龙通讯的上位机开发工程师或者是在实验室里被PLC折腾得头疼的调试人员。如果你已经会用FINS但总被某些细节卡住比如地址计算不对、数据读出来不对位那这篇文章里的踩坑记录应该也能帮上忙。我尽量把协议层的东西讲得通俗些毕竟FINS报文结构初见时真有点劝退但摸清楚规律之后会发现它其实设计得相当规整。1. FINS协议是什么以及为什么要选它1.1 FINS和上位机通讯的主流方式先明确一个概念FINS是富士通Fujitsu和欧姆龙共同制定的工业网络协议全称是Factory Interface Network Service它不依赖特定的物理层可以跑在以太网FINS/UDP、FINS/TCP、串口、甚至Controller Link等网络上。对于C#上位机来说最常用的是FINS/UDP因为UDP无连接、速度快适合周期性读取数据的场景。很多人在选通讯方式时会纠结是走HostLink串口还是FINS或者干脆用欧姆龙自带的OPC UA服务器。我的建议是如果只是本地局域网内、数据量不大、需要快速响应的上位机FINS/UDP是最优解。HostLink需要确认串口参数还要处理帧校验繁琐且速度上限低OPC UA虽然配置方便但要在PLC里启用服务对老型号PLC不友好而且引入额外中间件的开销。FINS则是一个“裸协议”你只要能发UDP报文就能和PLC对话掌控力最强。1.2 FINS/UDP和FINS/TCP怎么选FINS支持UDP和TCP两种传输方式。TCP因为有连接管理适合需要可靠传输、数据量大的场景比如上传下载程序或大块数据。但UDP在轮询场景下性能更好而且FINS协议本身在应用层有结束码End Code和重试机制只要处理好超时和重发可靠性并不差。实际项目里我一般默认用UDP 9600端口PLC侧不需要额外配置连接上位机电脑只要和PLC在同一网段就能通讯。FINS/TCP则需要先建立TCP连接做握手PLC侧要配置TCP端口号调试起来稍麻烦一点。还有一个细节是FINS/UDP允许广播可以快速搜索网络上所有支持FINS的设备这在现场不知道PLC IP时非常好用。2. 通讯前的准备工作与关键参数2.1 欧姆龙PLC侧的设置在写任何代码之前必须先确认PLC的网络参数。连上CX-Programmer老款PLC或Sysmac StudioNJ/NX系列在“设置 - 内置以太网端口”里能看到IP地址、子网掩码和FINS节点号。FINS节点号是协议层标识设备的编号范围是1到254默认通常跟着IP地址最后一组走比如IP是192.168.1.10节点号一般就是10。这个对应关系不是强制的但强烈建议保持一致否则调试时会把自己绕晕。另一个必须确认的是PLC的FINS/UDP服务是否开启。在CX-Programmer的以太网设置里有一个“FINS UDP”选项默认是启用的端口号固定9600。有些项目里为了安全可能会把服务关掉或修改端口如果上位机连不上首先要检查这里。2.2 上位机侧的网络准备电脑这边其实没什么特殊配置只要和PLC在同一网段就行。但要注意如果PLC的IP是192.168.1.10电脑是192.168.1.20子网掩码都是255.255.255.0那没问题。如果现场网络复杂有多个网卡要确保发送UDP报文的网卡IP确实在PLC同一网段否则报文发出去了PLC收不到。还有一个在实际项目中很容易被忽视的变量就是Windows防火墙。开发机上第一次跑FINS通讯程序时经常出现发送成功但收不到响应的情况。排查下来大概率是防火墙拦了UDP 9600端口的入站数据。解决办法很简单要么在防火墙高级设置里加一条入站规则放行UDP 9600要么把程序加入白名单。我用的是后者因为项目里上位机程序经常要部署到多台机器加入白名单比手工配规则省事。2.3 FINS节点号与IP的关系再展开说说FINS节点号。FINS报文头里有个DA1和SA1字段分别代表目标节点PLC和源节点上位机。这两个字段都是单字节范围1到254。PLC在收到UDP报文后会根据报文的源IP地址和FINS节点号来验证是不是合法的通讯对象。有个常见误区是认为节点号必须等于IP最后一段。其实PLC侧只是把FINS节点号和IP地址做了一层映射这个映射关系在PLC网络设置里是隐含的默认规则就是“IP最后一段 节点号”。如果你改过PLC的节点号而上位机代码里还是用IP最后一段那PLC收到报文后发现DA1不匹配会直接丢弃。所以代码里有没有设置源节点号以及设置的数值是否和PLC网络配置一致就特别关键。我写的每个FINS请求里SA1用的都是本机IP最后一段同时DA1是PLC节点号这样基本不会踩坑。3. FINS报文结构与指令解析3.1 一帧FINS/UDP报文的完整解剖FINS/UDP报文结构其实不复杂总共分两大部分FINS帧头10字节和FINS命令数据长度不定。帧头固定包含以下字段ICF信息控制字段1字节决定是命令还是响应是请求还是不需要响应。上位机发命令时通常设为0x80表示“需要响应”。RSV保留字段1字节固定0x00。GCT网关计数1字节固定0x02表示允许经过2个网关。DNA目标网络地址1字节0x00表示本地网络。DA1目标节点号1字节就是PLC的FINS节点号。DA2目标单元号1字节0x00表示CPU单元。SNA源网络地址1字节0x00表示本地网络。SA1源节点号1字节上位机的FINS节点号。SA2源单元号1字节0x00表示CPU单元。举个实际例子假设PLC节点号是10上位机节点号是20那么帧头就是80 00 02 00 0A 00 00 14 00 00这里0A是10的十六进制14是20的十六进制。每次组报文时这几字节基本都是模板只有DA1和SA1会变。3.2 读DM区数据的核心指令和参数帧头后面是命令数据。最常见的操作是读DM区数据存储器数据命令码是0x0101代表“内存区读取”。这条命令的参数包括内存区代码1字节DM区是0x82CIO区是0xB0WR区是0xB1HR区是0xB2。起始地址2字节比如要读D100地址就是100的十六进制0x0064。读取长度2字节要读几个字16位比如读10个字就是0x000A。于是完整的读D100起10个字的命令数据就是01 01 82 00 64 00 0A把帧头10字节和命令数据拼起来发给PLCPLC会返回一帧响应。响应帧的帧头12字节比命令帧多2字节的结束码其中结束码位于第13、14字节0x0000表示正常其他值就是错误码。正常响应后面跟着你要的数据也是按大端字节序排列每两字节一个字。3.3 CIO区、WR区、HR区的地址计算DM区的地址计算很直观起始地址就是字编号。但CIO区稍微复杂点因为它的编号不是连续的数字。CIO区包含输入输出继电器区CIO 0~CIO 99、内部继电器区CIO 1000~CIO 2999等访问时起始地址直接填编号就行比如要读CIO 1000地址就是0x03E8。WR区工作区的编号是W0到W511转换成地址时直接用编号起始地址就是0x0000到0x01FF。HR区保持区是H0到H511同理。这里有个常见坑有些资料里会把CIO区的起始地址加一个偏移量比如从CIO区读时地址要加0x8000因为某些老的欧姆龙PLC内部映射如此但对NJ/NX和较新的CP系列来说不需要这个偏移。如果你照着老代码抄可能在新型号上读出来的数据全是错的。最靠谱的办法是在CX-Programmer的地址帮助里查一下你用的PLC型号具体怎么映射。3.4 位读取指令0x0102的使用除了读字还经常要读位比如某个传感器的通断状态。FINS读取位的指令是0x0102参数格式略有不同内存区代码后面跟的是“位地址”一个3字节的数值前2字节是字地址最后一字节是位号0-15。也就是说如果我想读D100.05实际发送的起始地址是0x0064 * 16 0x05即0x0645然后再补一位长度。这样读出来的数据是一个16位的值但只用到最低位0代表OFF1代表ON。位地址换算的公式是word_address * 16 bit_number。比如W10.03就是10 * 16 3 163十六进制0x00A3。读位时读取长度单位是“位”最多可以一次读多个连续的位但我一般读单个位简单直接不易出错。4. C#实现FINS/UDP通讯的完整代码4.1 基础Socket封装类下面这段代码是我项目里一直在用的基础通讯类核心就三件事根据IP和节点号组FINS帧头、执行UDP收发、解析响应提取数据。没有用任何第三方库纯C#的UdpClient就能跑起来。using System; using System.Net; using System.Net.Sockets; using System.Threading.Tasks; public class FinsUdpClient { private UdpClient _udpClient; private IPEndPoint _plcEndPoint; private int _timeout 2000; // 毫秒 public byte PlcNode { get; set; } 10; // PLC FINS节点号 public byte LocalNode { get; set; } 20; // 本机 FINS节点号 // 初始化连接 public void Connect(string plcIp, int port 9600) { _udpClient new UdpClient(); _plcEndPoint new IPEndPoint(IPAddress.Parse(plcIp), port); _udpClient.Connect(_plcEndPoint); } // 发送命令并接收响应超时抛出异常 private byte[] SendReceive(byte[] command) { // 组FINS帧头长度为10 byte[] frame new byte[10 command.Length]; frame[0] 0x80; // ICF需要响应 frame[1] 0x00; // RSV frame[2] 0x02; // GCT frame[3] 0x00; // DNA frame[4] PlcNode; // DA1 frame[5] 0x00; // DA2 CPU单元 frame[6] 0x00; // SNA frame[7] LocalNode; // SA1 frame[8] 0x00; // SA2 frame[9] 0x00; // SID命令ID随意但每次最好不同 Buffer.BlockCopy(command, 0, frame, 10, command.Length); _udpClient.Send(frame, frame.Length); var task _udpClient.ReceiveAsync(); if (!task.Wait(_timeout)) { throw new TimeoutException(接收PLC响应超时); } return task.Result.Buffer; } // 解析响应中从第13字节开始的数据区 private byte[] GetResponseData(byte[] response) { if (response.Length 14) throw new Exception(响应帧长度无效); ushort endCode (ushort)((response[12] 8) | response[13]); if (endCode ! 0) throw new Exception($PLC返回错误码: 0x{endCode:X4}); // 正常响应中数据从第14字节开始 byte[] data new byte[response.Length - 14]; Buffer.BlockCopy(response, 14, data, 0, data.Length); return data; } // 读取连续字地址如D100读10个字 public ushort[] ReadWords(byte memoryCode, ushort startAddress, ushort length) { byte[] command new byte[8]; command[0] 0x01; // 命令码 01 01 command[1] 0x01; command[2] memoryCode; command[3] (byte)(startAddress 8); command[4] (byte)(startAddress 0xFF); command[5] (byte)(length 8); command[6] (byte)(length 0xFF); command[7] 0; // 填充因为0101命令只要7字节? 实际是7字节去掉第8位这里修正 byte[] response SendReceive(command); byte[] data GetResponseData(response); ushort[] result new ushort[length]; for (int i 0; i length; i) { result[i] (ushort)((data[i * 2] 8) | data[i * 2 1]); } return result; } public void Close() { _udpClient?.Close(); } }注意上面代码里有一处要修正命令数组长度定义多了。FINS内存区读取命令真实长度是7字节命令码2字节内存区代码1字节起始地址2字节长度2字节不需要第8字节。我把那段放出来就是想强调这类小细节太容易写错编译不报错但报文发过去PLC直接回错误码。4.2 读取DM区数据的实际调用示例使用上面这个类读取D100到D109这10个字代码非常简洁var fins new FinsUdpClient(); fins.PlcNode 10; fins.LocalNode 20; fins.Connect(192.168.1.10, 9600); try { ushort[] values fins.ReadWords(0x82, 100, 10); for (int i 0; i values.Length; i) { Console.WriteLine($D{100 i} {values[i]}); } } catch (Exception ex) { Console.WriteLine(通讯失败: ex.Message); } finally { fins.Close(); }这里面有个容易迷惑的点ReadWords的第二个参数startAddress填的是十进制字地址100而不是十六进制0x0064。因为在方法内部已经做了高字节和低字节的拆分外部传入的人类可读的十进制数就好。但这里要留神如果读的是CIO区或WR区地址编号本身可能不是从0开始传入的时候一定要确认这个“编号”和PLC侧显示的编号是一致的。4.3 读取位状态的实现读取位时命令码变成0x0102起始地址需要换算成“位地址”。换算方法就是前面说的字地址乘以16加位号。长度是位个数最大好像是255还是多少我一般读单个位。public bool ReadBit(byte memoryCode, ushort wordAddress, byte bitIndex) { // 计算位地址字地址*16 位号 ushort bitAddress (ushort)(wordAddress * 16 bitIndex); byte[] command new byte[7]; command[0] 0x01; // 命令码 01 02 command[1] 0x02; command[2] memoryCode; command[3] (byte)(bitAddress 8); command[4] (byte)(bitAddress 0xFF); command[5] 0x00; // 读取长度 1位 command[6] 0x01; byte[] response SendReceive(command); byte[] data GetResponseData(response); // 响应数据是一个16位值只有最低位有效 return (data[0] 0x01) 0x01; }这个方法我在现场用来监视设备状态时用得很频繁。每100ms轮询一次几十个IO点的状态UDP方式压力不大没出现丢包的情况。4.4 批量读取与按位组装工业现场的数据很少是单个字独立使用的通常是一个数据块。比如我遇到过一台包装机D100到D109存的是10个温度值Int16D110是设备状态字每一位代表一个报警这种场景下批量读取是必须的。批量读不仅减少通讯次数也降低PLC的通讯负载。读回来之后如果要提取状态字中的某一位可以这样处理ushort status values[10]; // D110 bool alarm1 (status 0x0001) 0x0001; bool alarm2 (status 0x0002) 0x0002; bool alarm3 (status 0x0004) 0x0004;这种“按位与”的方式很直观不用额外调FINS位读取指令。我要提醒的是欧姆龙PLC的数据类型中大端存储UDP报文中也是高字节在前所以上面代码里读出来直接拼成ushort没问题。但如果涉及32位整数或浮点数就要额外处理字节顺序。5. 数据类型转换与多寄存器拼接5.1 大端字节序的处理FINS协议遵循大端字节序高字节在前这和x86架构的小端正好相反。上面的ReadWords方法拼接时已经处理了这一点(data[i * 2] 8) | data[i * 2 1]把高字节放到前面低字节放后面得到正确的ushort。但如果你读两个相邻的寄存器想拼成一个uint32位无符号整数顺序就要特别注意。PLC侧如果存储的是一个无符号32位整数比如某些累计量那么D100是高16位D101是低16位。拼的时候应该是uint value32 (uint)((values[0] 16) | values[1]);如果是带符号的32位整数或者浮点数还要再做一步转换。浮点数的处理稍微复杂些FINS协议会按照IEEE 754存储先高字后低字拼好后直接BitConverter.ToSingle就能拿到结果byte[] floatBytes new byte[4] { (byte)(values[0] 8), (byte)(values[0] 0xFF), (byte)(values[1] 8), (byte)(values[1] 0xFF) }; float temperature BitConverter.ToSingle(floatBytes, 0);5.2 无符号、有符号和浮点的转换策略工业数据里最常见的三种数据类型是INT16位有符号、DINT32位有符号和REAL32位浮点。INT直接强转short即可short s (short)values[i]。DINT需要把两个相邻ushort拼成uint再转int。如果是负数直接按位运算就能得到补码不需要额外处理。REAL上面已经写了拼4字节转float。我在项目里写过一个辅助类专门处理这些转换避免在业务代码里到处堆位运算。如果你也经常和数据转换打交道强烈建议封装成公共方法不然现场调试时临时去推字节顺序太容易出错。5.3 字符串数据的读取ASCII和Unicode有些PLC程序会把操作员信息、批次号等字符串存到DM区。读取方式和其他数据一样只是转换方式不同。如果字符串是ASCII编码每个字符占1字节两个字符拼在一个字里高字节是第一个字符。比如D100存的是字符“AB”实际就是0x4142。读取代码一般是把返回的字节序列直接转成字符串byte[] data ...; // 从响应中提取的原始数据 string asciiText Encoding.ASCII.GetString(data); // 去掉末尾的空白字符 asciiText asciiText.TrimEnd(\0, );如果是UnicodeUTF-16每个字符占2字节和ushort是等长的直接用Encoding.Unicode.GetString转换原始字节序列即可。这里要注意欧姆龙的部分老型号PLC处理Unicode时字节序可能会和C#默认的UTF-16LE不一样如果读出来乱码试试把每个字的字节序反转一下再转。另外一个经验PLC里存的字符串长度往往是固定的比如“MODEL_NO”可能占用20个字节实际内容只有6个字符后面全是0x00。这时候TrimEnd就必须有不然输出会带一串调试符号。6. 长连接与多线程轮询架构6.1 单次请求和持续轮询的设计差异很多初学者一开始是“读完一次就关掉Socket”这在Demo里没问题但工业现场不行。PLC通讯讲究长连接UDP虽然本身无状态但你的UdpClient实例如果每次都new、每次都是新端口PLC侧根据源端口来判断通讯对象频繁更换端口可能导致一些问题。更关键的是每次new UdpClient都涉及系统资源的分配和释放高频轮询下性能会很差。我的做法是在程序启动时创建FinsUdpClient并连接整个生命周期里复用同一个实例直到程序退出才关闭。这样源端口固定PLC侧通讯日志也稳定排错容易。6.2 使用异步方法避免UI卡顿如果你在WinForms或WPF里直接用同步方法轮询界面会卡到你怀疑人生。我见过不少同事犯这个错定时器里调用ReadWords数据量一大界面直接无响应。这是因为UI线程被阻塞在Socket等待上了。解决办法有两个一是用async/await配合UdpClient.ReceiveAsync()二是把轮询放到后台线程再用Invoke或BeginInvoke更新UI。我个人更推荐前者代码结构清爽不容易出现跨线程访问UI控件的问题。改造后的SendReceive方法只需要把task.Wait改成await task再把方法签名改成async Taskbyte[]即可。private async Taskbyte[] SendReceiveAsync(byte[] command) { // 组帧省略... await _udpClient.SendAsync(frame, frame.Length); var result await _udpClient.ReceiveAsync(); return result.Buffer; }然后在按钮事件或定时器事件里private async void Timer_Tick(object sender, EventArgs e) { try { var values await _fins.ReadWordsAsync(0x82, 100, 10); lblValue.Text values[0].ToString(); } catch (Exception ex) { lblStatus.Text 通讯异常: ex.Message; } }这一改动直接让UI刷新从“卡成PPT”变成了“流畅如丝”。之前热词里提到的“循环数据采集和UI刷新卡顿”几乎都是因为这个原因。6.3 轮询频率与超时重试策略轮询频率要看PLC的扫描周期和通讯负载。一般DM区读10个字以内建议间隔100ms以上太频繁会给PLC的通讯任务增加负担。如果是几十个字的大块读取间隔200ms比较稳妥。超时设置我习惯用2000ms如果连续3次超时基本可以判断网络或PLC出问题了这时候程序要给出明确提示而不要无限重试。代码里可以记录连续失败次数达到上限后就停止自动重连等操作员人工介入。还有一个实用技巧为每个FINS命令生成不同的SID命令ID这样即使响应乱序或迟到了也能在应用层判断这条响应对应哪条命令。我的多线程项目里会用到这个机制单线程轮询其实无所谓但养成好习惯没坏处。7. 易错点地址偏移、响应延迟与设备离线7.1 常见FINS错误码速查FINS协议里PLC返回的错误码能告诉我们很多信息。我整理过一份出现频率最高的错误码贴在这里方便大家快速排查错误码含义可能原因0x0000正常无0x1101内存区代码错误请求了不存在的内存区0x1103地址错误起始地址超出范围或未按字对齐0x110B长度错误请求读取长度超过上限0x2002数据被保护PLC设置了数据保护无法读写0x2003数据不存在命令中指定的地址无实际数据0x2101通讯节点错误DA1、SA1节点号配置不匹配0x2102目标节点不存在PLC节点号实际不存在0x2103目标节点无响应网络不通或PLC忙7.2 地址偏移与数据类型错位的实际案例有一次我读取一个NJ501的PLC程序里明确写了要读D100开始的20个字但读回来前两个数是零第三个才开始有数据。排查了半天发现组态时PLC的DM区起始被改成了D2000D100属于系统保留区根本没被用户程序使用。这就是典型的“PLC侧变量映射和上位机不一致”问题。后来我在项目里定了个规矩上位机要读的数据地址必须以PLC工程师提供的符号表或者地址映射表为准绝不自己拍脑袋猜。还有一个案例是关于CIO区偏移的。有台设备是CP1H的PLC我按资料写CIO区读地址是0x0000读出来全不对。后来发现CP1H的CIO区在FINS报文里的实际地址偏移是0x8000也就是CIO0在协议层其实是0x8000。这个偏移不是所有系列都一样所以遇到老型号PLC时要多一个心眼实测通了再固化代码。7.3 设备离线检测与自动重连上位机最怕的就是设备突然离线后程序没有感知一直报超时错误也没有重连机制。我的做法是维护一个“通讯健康状态”标志每次成功收发一帧就置位连续超时达到阈值就标记离线停止轮询改用重连检测线程。重连线程每隔2秒发一次“读CPU状态”的命令命令码0x0501一旦成功就自动恢复轮询。这样整个架构非常稳定操作员无需重启上位机程序。代码实现不复杂核心就是在FinsUdpClient里增加一个IsOnline属性和一个ReconnectAsync方法。8. 多PLC通讯与内存区间读写扩展8.1 对接多台PLC的地址管理一个工位多台PLC很常见比如一台主PLC加两台从PLC。FINS的节点号不同对应不同的DA1。我的做法是把FinsUdpClient封装成一个字典按工位名称或PLC名称索引每个PLC实例管理自己的IP、节点号和Socket。Dictionarystring, FinsUdpClient plcClients new Dictionarystring, FinsUdpClient(); plcClients[main] new FinsUdpClient { PlcNode 1, LocalNode 20 }; plcClients[main].Connect(192.168.1.1); plcClients[sub] new FinsUdpClient { PlcNode 2, LocalNode 20 }; plcClients[sub].Connect(192.168.1.2);这里要注意多个FinsUdpClient实例的源节点号不能相同否则PLC无法区分请求来源。最好每个上位机固定用一个唯一的节点号所有PLC都共用一个SA1这样PLC侧做权限控制也方便。8.2 写操作指令0x0102之外的0x0103和0x0104读指令讲完了写指令其实套路一样只是命令码和参数不同。写单个字用0x0103写多个字用0x0104。比如向D200写入数值12345命令是01 03 82 00 C8 30 39这里的30 39是12345的十六进制0x3039按大端拆成两个字节放在最后。响应帧结束码为0x0000代表写入成功。实操中写操作比读操作更需要谨慎尤其是写多个字时地址一旦写错可能覆盖PLC的关键数据。所以我的习惯是写操作单独封装一个方法加一个确认参数必须显式传入true才允许执行。8.3 扩展内存区EM区的访问方法欧姆龙部分PLC有扩展内存区EM区分为多个bank。访问EM区时内存区代码不是固定的0x98而是会根据bank号变化内存区代码是0x98加上bank号。比如访问EM0区代码是0x98访问EM1区代码是0x99。因为bank号最多到32767而内存区代码只有1字节所以规则是0x98 bank号 % 256这个说法不准确实际是当bank号超过255时需要用FINS的扩展命令0x0101的附加参数来指定比较复杂。我的经验是普通项目很少用到超过8个bank直接用0x98到0x9F就能覆盖EM0~EM7。真遇到大bank场景建议直接问PLC工程师要协议文档别自己瞎试。9. 进程异常、杀毒软件与防火墙的坑9.1 杀毒软件拦截FINS通信的处理工业电脑装杀毒软件是个矛盾体安全部门要求装但杀毒软件经常把工业通讯软件的网络行为当威胁处理。我碰到过最诡异的一次是程序运行正常但每隔几分钟就断连一次查了半天发现是杀毒软件在后台做网络扫描把UDP端口占用了一会儿。解决方式很直接在杀毒软件里把上位机程序的整个目录加入白名单或者是把PLC的IP段加入信任区。如果安全政策不允许那就只能用TCP方式通讯TCP的稳定性和杀毒软件的兼容性会好些但代价是PLC侧增加连接开销。9.2 防火墙规则设置与端口开放Windows防火墙默认拦截所有入站UDP如果你的PLC主动向上位机发数据比如FINS的主动通知功能就必须在防火墙里放行9600端口。如果只是上位机主动轮询理论上不需要入站规则但要留意某些防火墙配置会把未授权的UDP回包也拦掉。最省事的做法是把上位机程序加入防火墙白名单允许所有网络或者单独开放UDP 9600端口入站。我在部署文档里都会写明这两步省得现场挨个查。9.3 双网卡电脑的绑定问题工业电脑经常是双网卡一个连办公网一个连设备网。这时如果上位机默认路由走了办公网网卡UDP报文就可能发不到PLC。现象就是程序里Send不报错但PLC收不到或者PLC回了但收不到。解决办法是在UdpClient绑定到特定的本地IP把new UdpClient(new IPEndPoint(本地IP, 0))作为构造函数这样发送时源IP就是设备网卡的IP报文路由自然走对网卡。这一点真的要重视我第一次在现场碰到这问题时排查了好久。10. 从一个Demo到可靠通讯的一点心得从能读到D100的数据到能稳定地在生产线上跑几个月不出问题中间差的不是协议知识而是异常处理、日志记录、超时重试和状态监控这些“工程化”的功夫。FINS协议本身不复杂但工业通讯的环境比开发环境复杂得多。我在实际项目中还发现日志记录比什么都管用。每条FINS命令的收发时间、耗时、响应码都记下来出问题时翻日志一目了然。用现成的日志库比如NLog或者简单写个文本日志类都行但一定要带时间戳。我现在维护的这套上位机系统就是靠日志锁定了三四个偶发问题比如PLC重启期间上位机连续发命令被丢弃、某个时间段网络延迟突然变高导致3次重试后才成功这些都是没有日志时根本无从查起的问题。最后再分享一个我在C#实现FINS时的小技巧把FINS报文组帧过程单独抽成一个FinsFrameBuilder类所有命令帧都从这生成这样万一日后要加新指令比如写操作、CPU状态查询只需在builder里加方法不用改动通讯核心。通讯核心慢慢沉淀下来几个项目都能复用省下不少事。本文还有配套的精品资源点击获取