1. 协议概览FINS到底是什么为什么绕不开它搞工控的人迟早都会撞上欧姆龙的PLC。不管是老一点的C系列、CS1还是现在主流的NJ/NX系列只要你想让PLC和上位机触摸屏、工控机、MES系统说上话就绕不开一个叫FINS的协议。FINS全称是Factory Interface Network Service翻译过来就是工厂接口网络服务听起来挺绕口但你完全可以把它理解成欧姆龙设备之间通信的“普通话”。这个协议厉害在哪它不挑网络。不管你是走串口RS-232C、RS-422A/485还是走以太网UDP/TCP甚至是Controller Link、SYSMAC LINK这类工业总线FINS都能跑。也就是说你只要学会了一套报文格式不管物理层用什么介质都能用同一套规则去读写PLC的数据区。这在实际项目中太重要了——今天用串口调试的老设备明天想改造成以太网接入上位机协议层几乎不用动只需要换传输方式就行。很多人一开始接触FINS时觉得难主要难在两点一是它的报文结构是二进制十六进制的看起来全是“F0 01 02 00”这种字节串不像Modbus那样有清晰的功能码和寄存器地址容易让人发懵二是FINS的命令码和地址计算规则有自己的逻辑跟你之前熟悉的Modbus、西门子S7协议完全不是一个路子。但话又说回来正因为它的规则是固定的、帧结构是统一的只要你把它的报文骨架啃透了后面读写数据基本就是套模板的事。这篇文章我就按自己实际调试的经验从帧结构、地址计算、报文示例、常见坑这几个维度把FINS协议从头到尾捋一遍。内容面向那些已经会Basic梯形图编程、但对上位机通信还不太熟的工程师以及刚入门工控通信、想搞懂底层报文交换的同学。2. 帧结构拆解一条FINS报文到底由哪些部分组成2.1 三种帧模式从ASCII码到二进制命令帧FINS协议最劝退新手的就是它有好几种“长相”。同一条指令你从串口发出来是ASCII码字符串从以太网发出来是二进制帧而且在以太网里还要先搞清楚是走UDP还是TCP。我先按从简到繁的顺序把FINS的帧模式讲清楚。第一种是串口场景下的“命令帧”。这种帧以开头后面跟单元号、命令码、文本长度、正文最后是FCS校验码和终止符。整体是ASCII可见字符方便用串口助手直接观察。比如你要读取PLC的DM区数据发出的数据大致是00FA0500FFFF0002000001C0这样的字符串其中每个字符都代表一个十六进制数字。这种方式调试最直观原理也最简单把每条命令的十六进制字节转成对应的ASCII字符发出去。第二种是Host Link协议的“FINS命令”。这个本质上还是串口帧但是报文里多了一个明确的帧格式段。命令最终的格式是单元号 帧格式 FINS命令码 正文 FCS 终止符。这里的帧格式通常填FA表示是FINS命令格式。第三种是以太网场景下的FINS/UDP和FINS/TCP帧。这种就是纯二进制帧了不再用ASCII字符表示十六进制数而是直接把字节发出去。比如读DM区的二进制请求是80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00这样一长串。看起来复杂但拆开来看结构非常清晰。2.2 以太网帧的详细字段解析FINS Header和FINS命令区用最常用的FINS/UDP来说一帧完整的报文分两大块FINS Header报头和FINS命令区。FINS Header共10个字节作用类似于信封上的地址和邮戳。各字段含义如下字段长度说明信息控制ICF1字节0x80表示命令帧0x00表示响应帧应答类型RSV1字节固定填0x00由系统设置网关计数GCT1字节默认0x02表示允许经过2个网关目标网络号DNA1字节0x00表示本地网络目标节点号DA11字节PLC的节点号通常为0x01目标单元号DA21字节0x00表示内置CPU单元源网络号SNA1字节0x00源节点号SA11字节上位机的节点号比如0x11源单元号SA21字节0x00服务IDSID1字节命令帧和响应帧对应相同的SID用于配对确认SID这个字段特别实用。它是你给这条命令起的“编号”PLC返回的响应帧会带上相同的编号。如果上位机同时发了多条命令就靠SID来区分哪条响应对应哪条请求。坑点在于有些调试者忽略了SID收发日志里多条命令的SID全是0x00一旦同时下发好几条命令就分不清响应顺序了。FINS命令区则分成两段前2字节是命令码MRC/SRC后面是命令参数和写入的数据。命令码是整个协议的核心索引。比如01 01是读DM区数据01 02是写DM区数据01 03是读I/O区数据23 01是写时钟数据。不同型号PLC支持的命令有细微微调但读字、写字、读状态这几类最常用。2.3 串口帧与以太网帧的换算关系这里有个很多人绕不明白的点为什么串口帧里的命令码是ASCII形式的以太网帧就是二进制字节其实很简单——串口帧是为了能在老式触摸屏和Host Link协议下用可见字符传输每个字节要拆成两个十六进制字符发送以太网帧则是纯粹的二进制传输效率更高。举个例子读取DM区0000开始的1个字二进制二进制命令区内容是01 01 82 00 00 00 00 01命令码01 01内存类型82表示DM区起始地址0000长度1个字如果走串口ASCII帧那么这段内容要变成30313031 38323030 30303030 30303031这样的ASCII字符序列。如果走以太网直接发送80 00 00 00 00 00 00 00 00 00 00 02 00 01 01 82 00 00 00 00 01。所以调试时不要犯“用串口助手习惯了看ASCII结果用以太网抓包时看不懂二进制报文”这类错误。把这两种形态的对应关系搞明白FINS协议就通了七成。3. 内存区与地址PLC里的地址怎么映射到FINS报文3.1 FINS内存区代码速查表FINS协议里内存区类型是用一个字节代码表示的。这个跟Modbus的寄存器区概念很像但代码完全自定义。最常用的几个区如下内存区代码数据类型说明0x82 / 0x02DM区数据内存按字(16位)寻址0x80 / 0x00CIO区输入输出继电器区0x83 / 0x03WR区内部继电器区0x84 / 0x04HR区保持继电器区0x85 / 0x05AR区辅助继电器区0x88 / 0x08程序区存放用户程序0x89 / 0x09扩展区某些高端型号特有0xB0数据寄存器NJ/NX系列D区看到这里你可能会疑问为什么DM区有0x82和0x02两个代码因为第一个代码是“读”模式下的内存区代码第二个是“写”模式下的代码。FINS规定对某些区域进行写操作时需要使用不同的内存区代码标识目的是在系统层面防止误写。实际调试时读和写别混用代码否则就会返回错误码。3.2 地址计算规则字地址和位地址的换算这是FINS协议真正容易出错的地方。FINS的报文参数里起始地址拆成了两个部分前2字节是“字地址”后2字节是“位地址”。但位地址不是你想的bit偏移量而是一个“编码”。以DM区为例。DM区是一个16位的字区地址从0000到327670x0000到0x7FFF。要读DM0的整个字字地址填0x0000位地址填0x0000。要读DM10的整个字字地址填0x000A位地址填0x0000。这个逻辑很直觉。但对于CIO区就不同了。CIO区的地址范围很大例如一个CJ系列PLC的CIO区按位编址地址可能是0.00到6143.15。在FINS报文里它会把CIO区地址统一换算成一个“绝对位编号”然后拆成字地址和位地址。举个例子你要读CIO 100.05这个位。这个地址对应的总编号是100字乘16位加5位等于1605位。换算成十六进制是0x0645。那么FINS命令里内存区代码填0x30表示CIO区按位访问起始字地址填0x0006位地址填0x0045。命令码如果是位读写那么数据会在01位或者16位的格式下处理。这个计算过程容易乱因为你手上有字地址和位地址两个概念。记住一个核心口诀FINS协议里“字地址 总位编号 // 16”“位地址 总位编号 % 16加上内存区属性决定的高位偏移”。更准确地说位地址字段低4位是位号高12位是字内的偏移信息。实操中建议写一个小工具函数来做转换千万别心算项目规模一大准出错。我常用的转换思路是这样def cio_to_fins(addr_str): # 输入格式如 100.05 word_str, bit_str addr_str.split(.) word int(word_str) bit int(bit_str) total_bit word * 16 bit return total_bit // 16, total_bit % 16这个方法同样适用于DM区分配位访问时的情况。把DM区地址也转成总位数再拆字地址和位地址虽然平时DM区直接按字读更方便但项目里总有读单个开关量的场景。3.3 数据格式与大小端坑点FINS传输数据时多字节数据的字节序跟很多人的直觉不一样。比如你想把一个16位数值0x1234写入DM区FINS报文中该数据的字节顺序是12 34也就是大端模式高字节在前。这在工控协议里很常见Modbus也是大端。但问题出在32位数据上比如双字数据0x12345678FINS会按12 34 56 78的顺序传输。也就是说它把一个双字当成两个字依次传输每个字内部还是大端。听起来好像没毛病但在做上位机解析时就出过问题。我用C#的Socket接收数据直接用BinaryReader的ReadInt32方法去读得到的结果却是0x34127856数值完全错乱。原因就是C#默认按小端解析但FINS传入的数据是大端。解决办法就是手动对字节数组做反转或者使用专门处理大端序的库。我在项目里写过一个简单的字节封包函数// 将ushort值转为FINS格式的大端字节 byte[] UInt16ToFinsBytes(ushort value) { byte[] bytes new byte[2]; bytes[0] (byte)(value 8); bytes[1] (byte)(value 0xFF); return bytes; }这个细节看起来不起眼但项目中几乎每个新手都会在这里栽一次跟头。串口调试助手显示的报文明明正确上位机解析出来却全是乱码通常都是大小端没处理好。4. 手把手实操用UDP从零读取PLC的DM区数据4.1 环境准备与参数确认开始写代码之前先确认几个基础参数。我以某次项目里用CJ2M PLC和一台工控机通信为例说明完整的操作步骤。首先要确认PLC侧的FINS节点号。在PLC编程软件里进入“PLC设置”打开“内置以太网口设置”可以看到FINS节点号、IP地址、子网掩码。我那次项目里PLC的IP是192.168.1.10FINS节点号是0x01。工控机的IP是192.168.1.20FINS节点号手动设为0x64十进制100。这里提醒一个关键点FINS节点号必须和IP地址的最后一段一致或者手动映射一致。早期的欧姆龙PLC在默认情况下以太网口的FINS节点号就是和IP地址末位绑定的。如果你把PLC的IP设成192.168.1.10节点号却设成0x02通信大概率会失败因为PLC内部做地址解析时会对不上。现在NJ/NX系列可以通过内置交换机自由映射但传统CJ系列还是建议老老实实让节点号IP末位。端口方面FINS/UDP使用9600端口FINS/TCP使用9600端口但TCP方式需要先建立连接并发送一个Node Address Data Send命令。我自己更偏好UDP原因后面会说。4.2 组包实例构造一条完整的读命令现在假设我要读取PLC的DM区地址0000到0009共10个字的数据。用FINS/UDP的完整报文如下80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 01 01 01 82 00 00 00 00 00 00 0A逐段拆解一下ICF0x80命令帧RSV0x00GCT0x02DNA0x00目标网络本地DA10x01PLC节点号1DA20x00CPU单元SNA0x00源网络本地SA10x64上位机节点号100SA20x00SID0x00服务ID这次我用0命令码0x01 0x01读内存区内存区代码0x82DM区起始字地址0x0000DM0起始位地址0x0000数据长度0x000A10个字十六进制写出来就是上面那串。这里有个易错点读DM区命令里内存区代码用0x82而位地址字段虽然叫“位地址”但读字操作时这个字段必须填0x0000。不要因为想读DM区第5个位的状态就把位地址填成0x0005那样命令会出错。读位有专门的命令和内存区代码比如0x01 0x01配合0x30按位访问模式。4.3 用Python实测一组读写示例我在调试阶段最喜欢用Python写快速验证脚本因为它组包方便还能直接打印返回报文对照分析。下面这个是完整的UDP读写Demo可以直接改IP和地址参数用于现场测试。import socket import struct PLC_IP 192.168.1.10 PLC_PORT 9600 PLC_NODE 0x01 MY_NODE 0x64 def build_fins_header(commandTrue): icf 0x80 if command else 0x00 header bytes([icf, 0x00, 0x02, 0x00, PLC_NODE, 0x00, 0x00, MY_NODE, 0x00, 0x00]) return header def read_dm(start_addr, count): # 命令区: 命令码 01 01 内存区 82 起始字地址 起始位地址 长度 cmd_code bytes([0x01, 0x01]) mem_type bytes([0x82]) start struct.pack(H, start_addr) bit_addr struct.pack(H, 0x0000) length struct.pack(H, count) command_area cmd_code mem_type start bit_addr length return build_fins_header(True) command_area def parse_read_response(data): # 跳过10字节头前2字节是命令码第3字节是结束码 end_code struct.unpack(H, data[10:12])[0] if end_code ! 0x0000: print(f错误码: {hex(end_code)}) return None payload data[12:] words [] for i in range(0, len(payload), 2): words.append(struct.unpack(H, payload[i:i2])[0]) return words sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(2) request read_dm(0, 10) print(发送报文:, request.hex().upper()) sock.sendto(request, (PLC_IP, PLC_PORT)) response, addr sock.recvfrom(1024) print(接收报文:, response.hex().upper()) values parse_read_response(response) print(读取到的DM值:, [hex(v) for v in values])这个脚本在真实PLC上测试时关键点是发送报文的hex().upper()要和抓包工具里的报文完全一致。如果PLC返回的结束码不是0x0000比如返回0x1101内存区代码错误或者0x1103地址越界那就按照结束码对照表去排查。我在现场调试时发现最容易出现的错误码是0x1103原因通常是起始地址加上长度超出了DM区的最大地址范围。例如DM区最大只有32767字你却从32760开始一次性读了20个字地址越界PLC直接拒绝执行。这个必须在组包前做边界检查。4.4 UDP与TCP怎么选这里展开说说为什么我偏爱UDP。FINS/TCP的确有好处长连接、可靠传输、PLC会维护一个连接状态表。但TCP模式有个麻烦——必须先跟PLC建立一个连接之后PLC会持续维护这个连接如果上位机异常退出PLC侧可能要等TCP超时才释放连接这段时间内重新连接会被拒绝一套流程下来体验很差。UDP的优势在于无连接、无状态我发一条命令PC收到响应通信就结束了不用管连接管理。现场环境只要不是网络丢包率极高UDP用于PLC数据交换完全够用。况且FINS协议本身自带结束码校验应用层已经做了“收到数据才认为发送成功”的确认机制。FINS/TCP适合那些需要持续的大批量数据上传的场景例如上位机通过多条命令持续高速读取PLC数据时TCP能避免UDP端口耗尽这样的小概率问题。但大多数监控项目数据量不大、频率不高UDP完全不吃力。所以我的建议是如果只是读写几十个字的数据直接UDP如果要在秒级内轮询上千个点位可以考虑TCP并做好断线重连机制。5. 常见错误码与调试心得踩过坑才知道的细节5.1 错误结束码速查与含义FINS响应帧里的结束码占2字节是排查问题最重要的入口。常见的返回码含义如下结束码含义排查方向0x0000正常完成无需处理0x0101本地节点错误检查源节点号设置0x0102目标节点错误检查目标节点号是否可达0x0104目标节点不存在检查PLC节点号0x1101命令长度错误检查报文字节数0x1103地址越界检查起始地址与长度0x110B内存区代码错误检查读/写模式代码0x2002数据错误检查写入的数据格式0x2003数据长度错误检查数据字节数记得有一次调试读写DM区一直返回0x1101折腾了很久才发现是发过去的报文多了一个字节。因为组包时我在命令区末尾多加了一个0x00导致协议认为命令长度不对。这类错误说实话没什么捷径只能逐个字节比对标准报文结构建议把正常模板报文存成常量组包后先打印hex值做对比再发送。5.2 节点号、SID、超时时间这些容易忽略的坑节点号的问题上面提过这里再补充一个细节如果你用串口方式连接PLC节点号默认是0x00但用以太网方式时节点号必须和IP末位保持一致。很多人把串口的0x00习惯带到以太网来导致目标节点号填0x00PLC认为这个节点是自己直接把报文吞掉了表现就是“发请求永远等不到响应”。如果你用网络抓包工具看到请求发出去了但PLC没有任何回包第一反应就查DA1字段。SID字段在单条命令调试时看不出问题但并发现场调试时就重要了。我用C#写了一个多线程轮询程序每个线程发不同的命令开始没注意SID所有报文的SID都是0。结果PLC回包后程序根本分不清哪个回包对应哪条命令逻辑全乱了。后来给每条命令根据功能分配不同的SID比如读温度用0x01、读压力用0x02、写阀门用0x03回包才能准确对号入座。超时设置也值得花点心思。上位机发送UDP报文后建议把超时设成500ms到1000ms然后配合重试机制。有些工程师把超时设成10秒结果某个节点离线时整个监控界面卡死在等待响应上按钮点半天没反应实际体验非常糟糕。我的一般做法是请求发出后如果500ms内没收到响应重试一次如果第二次还没收到把这个节点标记为“通信异常”不再阻塞程序主流程让其他节点的数据继续刷新。5.3 从抓包到定位一个实际排查过程实录我印象最深的一次排查是一个跨平台系统对接项目。PLC侧是NJ系列上位机用C#开发的监控软件通过FINS/UDP读取数据通信周期是200ms一次偶尔会出现某一次读取超时其他时候一切正常。第一反应是网络问题但ping PLC的IP非常稳定0丢包。然后用WireShark抓包发现超时发生的时间点很随机而且出现了PLC回包延迟的情况。后来仔细看抓包数据发现上位机有一次在300ms内连续发了20条读命令PLC按顺序处理前面有一两条命令处理时间稍长导致最后一条命令的响应超过了上位机设置的重试时间。这就暴露了一个实际项目里的通病上位机用多个线程分别读不同数据区结果多个线程同时发命令PLC的串行处理队列堆积响应延迟变大。解决办法是在上位机侧加一个命令队列所有FINS请求统一由一个线程发送发送频率控制在PLC能承受的范围实测200ms间隔读10个字完全没问题但40ms间隔读相同数量会偶尔超时同时保留SID机制用于区分响应。这个调整之后连续跑了一个星期再没出现过超时。所以当你遇到偶发超时不要第一个怀疑PLC坏了先看看是不是自己发送频率太高或者多线程并发导致PLC处理不过来。6. 进阶扩展FINS协议读写位、写多区数据与时钟同步6.1 位读写命令的实际报文实际生产环境中除了读写DM区整字数据还经常需要读取单个开关量信号例如某个传感器的到位信号、设备运行状态位。FINS读位命令和读字命令的区别在于内存区代码和命令参数组织方式。读一个CIO位的报文内存区代码要填0x30CIO区按位访问起始字地址和起始位地址按位方式计算。举个例子读CIO 100.05位的命令区01 01 30 00 06 00 45 00 00注意这里的字地址变成了0x0006位地址变成0x0045。为什么是这两个值因为100.05的总位编号是100*16516050x0645字地址取0x0645的高位即0x0006位地址取低16位即0x0045。这个计算方法和前面3.2节讲的一致FINS把位地址编码成字地址位地址两个字段。响应报文里读取的位数据放在一个16位字中最低位就是你要的值。所以上位机解析时取响应数据第一个字节的最低位即可。写入位时更要注意数据区必须写成0x0000OFF或0x0001ON写成其他值会返回数据错误。这跟Modbus写线圈0x00/0xFF的规则类似但FINS这里只认0和1写0xFF反而会报错。6.2 一次写入多个非连续区域Multiple Memory Area Write命令FINS有个高级命令01 03写多个内存区可以用一条命令往不同内存区写入不同数据。典型应用场景是一次下发生成配方同时往DM区写温度设定值、往WR区写启动标志、往HR区写保持参数。如果用普通写命令需要发三条请求耗时三倍用01 03命令一条报文全搞定。格式上这条命令的参数区更加灵活前半部分是写入的内存区数量后面跟若干个子块每个子块包含“内存区代码 字地址 位地址 数据长度 数据”。具体长度要根据实际子块数计算这是最容易出错的地方因为每条子块多出来的字节数直接改变了命令区的总长。我建议第一次用这个功能时先写一个命令解析器把每个子块用独立的字节数组拼装好最后再拼接组合不要一口气硬凑hex字符串。6.3 时钟读取与写入让PLC和上位机时间保持一致很多数据采集系统需要记录精确到秒甚至毫秒的数据时间戳如果PLC的时钟和上位机时间不一致诊断追溯时非常头痛。幸好FINS提供了时钟读写命令07 01读取时钟07 02写入时钟。读时钟请求的命令区是07 01 00 00响应会返回年、月、日、时、分、秒、星期共7个字节。需要注意返回的年份只有2位十六进制例如2025年会返回0x25上位机解析时要自己加上世纪前缀。写时钟请求的命令区是07 02后跟7个数据字节年、月、日、时、分、秒、星期全部按BCD码编址。比如要写2025年6月15日10点30分0秒数据就是25 06 15 10 30 00 00。这里特殊点在于“星期”字段需要自己计算星期几并填进去很多工程师在这一个小细节上翻车。计算星期可以用现成的库函数但冲PLC写入时数据必须是BCD编码不能直接填十进制10得填0x10。我还遇到过一个时钟同步的实际需求工厂里PLC在产线上位机在办公室双方时间差了30多秒。后续干脆写了一个定时任务程序每天早上8点用上位机时间通过FINS写入PLC时钟从此所有报表的时间戳对得上追溯数据再也不用来回猜时间差。7. 上位机项目实战从通信库到轮询架构7.1 抽象一个精简的FINS通信类完成上面这些基础测试后就可以把报文组包逻辑封装成可复用的通信库了。我自己的习惯是设计一个非常薄的FinsClient类只暴露几个方法和事件业务逻辑完全在上位机应用层实现。这样做的好处是即使后面换了PLC型号、换了通信协议比如从UDP换成TCP修改点只集中在通信库内部业务代码一行不用改。public class FinsClient { private UdpClient udp; private IPEndPoint plcEndPoint; public FinsClient(string plcIp, int plcNode, int localNode) { udp new UdpClient(0); plcEndPoint new IPEndPoint(IPAddress.Parse(plcIp), 9600); // 初始化FINS Header参数 } public ushort[] ReadDm(int startAddr, int count) { byte[] req BuildReadDmRequest(startAddr, count); byte[] resp Transceive(req); return ParseWords(resp); } public void WriteDm(int startAddr, ushort[] values) { byte[] req BuildWriteDmRequest(startAddr, values); byte[] resp Transceive(req); CheckEndCode(resp); } // 其他读写方法... private byte[] Transceive(byte[] request) { // 统一发送接收超时重试逻辑 } }这个类里最重要的就是Transceive方法它统一处理超时重试和结束码检查。配置了当前PLC的节点号、IP、端口后业务代码里直接调用ReadDm(0, 10)就能拿到对应的数据数组非常清爽。7.2 轮询架构500个点位怎么读才不卡上位机监控几十个设备、每个设备几百个点位是常见的工程规模。如果每个点位发一条FINS命令那不仅PLC忙不过来网络也会被报文塞满。这里就需要用到批量读取和合理的轮询分组策略。我常用的一种模式是把要监控的点位按区域归组比如同一台设备的所有温度数据在一个DM块里连续存放那就可以用ReadDm一次性把整个块读完然后在上位机内存里去按偏移量取各个点位。一个DM块100个字一次读取能覆盖100个温度点比逐点读取快了100倍。还有一种思路是动态轮询分组按数据变化频率把点位分为快速组100ms轮询、中速组500ms轮询、慢速组5s轮询这样既保证了关键数据的实时性又大大降低了PLC的负载。我在一个能源监控项目中把原本每秒读取所有点位的模式改成快速组100ms、中速组1s、慢速组10s结果PLC的扫描周期稳定了上位机CPU占用也下降了一半。7.3 上线前必做的三种通信测试任何FINS通信程序写完我强烈建议不要直接接到真实PLC上先在电脑上模拟测试。最简单的模拟方式是用一个UDP回环工具把PLC那侧的回应逻辑先不做只验证组包格式是否正确。但更靠谱的是利用某个支持FINS模拟的调试软件它会根据收到的FINS请求返回合理的响应可以在不上真机的情况下验证组包逻辑。第一项测试是报文格式验证。把每条请求的hex打印出来和标准文档逐字节对比尤其是命令码、内存区代码、地址字段。这一步能过滤掉90%以上的低级错误。第二项测试是边界压力测试。连续发送1000次读写请求观察是否出现超时、错包、累计延迟等问题顺便验证SID区分响应的逻辑是否靠谱。第三项测试是异常模拟测试。人为断开网线观察上位机是否能在预设超时时间内报出“通信中断”并且恢复网线后能否自动重连继续工作。很多上位机程序正常工作时看着挺好一断网就各种卡死报错就是没做这项测试。8. 协议对比与选型FINS、Modbus TCP与EtherNet/IP怎么选8.1 三种协议的核心差异很多工程师刚接触欧姆龙PLC时会纠结既然支持Modbus TCP为什么还要学FINS我的答案是如果只是偶尔读写一个寄存器Modbus TCP确实够用但如果要把欧姆龙PLC的全部能力发挥出来FINS是不能不学的。对比维度FINSModbus TCPEtherNet/IP原生支持欧姆龙全系PLC部分型号需额外配置高端型号原生支持读字命令01 0103隐式/显式报文写字命令01 0206/16显式报文地址模型内存区代码字地址位地址寄存器地址标签地址学习成本中等低较高故障排查结束码清晰常规异常码需要懂CIP协议栈Modbus TCP的优势是跨品牌兼容性极好如果你要同时对接西门子、施耐德、欧姆龙等多个品牌的PLC统一用Modbus TCP是一种省事的选择。但代价是欧姆龙特有的数据区类型例如WR区、HR区、AR区在Modbus TCP里没有标准映射你需要先在PLC侧用梯形图程序做数据搬运把需要通信的数据全部集中到某个固定地址的DM区再通过Modbus寄存器去读写这本身增加了很多工作量。EtherNet/IP是罗克韦尔和欧姆龙共同力推的协议基于CIP协议栈支持面向对象的数据访问性能最强。如果项目里有AB罗克韦尔的PLC和欧姆龙PLC互联用EtherNet/IP是正道。但它的上位机开发难度也大你需要引入一个完整的CIP协议栈库对于只做简单监控的项目来说有点杀鸡用牛刀。8.2 欧姆龙PLC之间FINS通信上位机用FINS只是其中一种用法。欧姆龙PLC之间也可以用FINS协议做数据交换比如一台作为主站定时读取另外几台PLC的数据这种方式在分布式控制系统中经常用到。PLC之间通过FINS通信时用到的是PLC内自带的SEND/RECV指令。SEND指令负责把本地内存数据发送到目标PLCRECV指令则把目标PLC的数据读到本地。参数里同样要指定目标网络号、节点号、单元号和数据区地址。如果多台PLC不在同一个网络里还要配置网络转发参数让报文能跨网络路由。这在控制层和监控层分离的架构中非常实用。我参与过一个模拟项目三台CJ2M分别控制三条产线一台NS触摸屏做主监控触摸屏通过FINS/UDP分别读写三台PLC的数据。配置时有个坑三台PLC的节点号如果从默认的0x00开始不改那么触摸屏发给节点0x00的报文会根据IP路由到其中一台但目标节点号检查不过直接返回错误。后面把三台PLC的FINS节点号分别改成1、2、3并且关闭了PLC的“节点号自动确认”选项通信才稳定下来。9. 写在调试台边的几句实话FINS协议本身不难难的是你愿不愿意静下心把它的报文逐字节拆开。很多工程师习惯全靠厂家提供的通信库遇到问题只能黑盒排查一旦库不顺手就抓瞎。我的经验是哪怕最终项目里还是用现成库也最好手写一遍组包和解析的流程这能让你真正理解协议在干什么排查故障时心里有底。关于资料欧姆龙官方通信手册虽然厚但核心其实就是命令码表和地址计算公式我建议大家把常用命令码整理成一张速查表贴在工位旁。实际调试时不要怕动手先用Python或C#写个几十行的小工具把读写字、读位、时钟同步这几个最基础的功能跑通比看十遍文档都管用。如果你能把上面这些内容都消化掉再遇到FINS相关的现场问题基本都可以自己解决。后续如果你们项目上有PLC之间数据交换、FINS网关转发这类更进阶的需求随时可以沿着这个基础继续深入。最后分享一个小习惯现场调试前先给所有FINS命令设计好统一的SID分配规则并在代码注释里写明每条命令的作用这个习惯能在你维护三个月前的代码时替你省下大把时间。