1. 项目缘起与整体方案设计车间里那台欧姆龙CP1H跑了快八年一直靠RS-232串口跟上位机通讯采样周期200ms勉强够用。直到去年产线加了两台视觉检测工位数据量一下子翻了四倍串口轮询开始频繁丢包最要命的是每次插拔串口线都得停线重启。痛定思痛决定把CP1H的以太网口用起来走FINS/TCP协议跟上位机直连。这个改造的核心思路很直接CP1H本体自带一个以太网口CP1H-Y型或加装CP1W-CIF41模块支持FINS/TCP和FINS/UDP两种通讯方式。选TCP不选UDP的原因很简单——车间电磁环境复杂UDP丢包后没有重传机制而FINS/TCP自带连接管理和命令响应确认虽然实时性略逊于UDP但胜在稳定可靠。实测下来TCP方式下单次读写响应时间稳定在8-15ms完全满足产线200ms的采样周期要求。整个方案涉及三个层面的配置PLC侧的以太网参数设置、上位机侧的FINS/TCP客户端实现、以及网络基础设施的配合。PLC侧需要设定IP地址、子网掩码、FINS节点号等参数上位机侧需要按照FINS/TCP帧格式封装命令网络层面要确保PLC和上位机在同一网段且交换机没有做端口隔离。这套方案适合有一定PLC基础、需要将欧姆龙PLC接入上位机系统的工程师参考无论是做数据采集、远程监控还是MES对接FINS/TCP都是绕不开的基础技能。注意CP1H本体以太网口仅CP1H-Y系列标配普通CP1H需要加装CP1W-CIF41以太网选件板。选件板安装在PLC左侧的选件槽中安装前务必断电。2. FINS/TCP协议核心细节拆解2.1 FINS协议帧结构详解FINSFactory Interface Network Service是欧姆龙定义的跨网络通讯协议可以理解为欧姆龙设备之间的普通话。它的帧结构分为两层FINS帧头和FINS命令帧。FINS/TCP则是在FINS帧前面再加一个TCP帧头形成三层结构。先看TCP帧头固定8个字节前4字节是魔术字FINS的ASCII码0x46 0x49 0x4E 0x53后4字节是后续数据的长度从FINS帧头开始算。这个设计很巧妙接收方先读8字节校验魔术字确认是FINS/TCP帧再根据长度字段读取剩余数据避免粘包问题。FINS帧头固定12字节包含ICF、RSV、GCT、DNA、DA1、DA2、SNA、SA1、SA2、SID这些字段。其中DA1是目标网络号DA2是目标节点号SA1是源网络号SA2是源节点号。对于同一网段内的通讯DNA和SNA都填0DA1填0DA2填PLC的FINS节点号SA1填0SA2填上位机的FINS节点号。SID是服务ID每次请求递增即可响应帧会原样返回用来匹配请求和响应。FINS命令帧由MRC主命令码、SRC子命令码和命令数据组成。读写CIO区用MRC0x01读操作用SRC0x01写操作用SRC0x02。读DM区用MRC0x02SRC0x01。这些命令码需要记牢调试时抓包分析全靠它们。2.2 FINS/TCP连接建立与保持机制FINS/TCP跟普通TCP最大的区别在于连接建立后需要先发一个节点地址请求命令。这个命令的TCP帧头魔术字是FINS但FINS帧头部分比较特殊ICF0x00其余字段全填0命令数据部分携带客户端希望的FINS节点号通常填0让服务器自动分配。PLC收到这个请求后会返回一个响应帧其中包含分配给客户端的FINS节点号。这个节点号后续所有通讯都要用到相当于TCP连接上的身份证。如果客户端指定的节点号已被占用PLC会返回错误码此时需要换一个节点号重试。连接保持方面FINS/TCP没有心跳机制但PLC侧有连接超时设置。默认情况下如果连接空闲超过一定时间通常几十秒到几分钟PLC会主动断开。上位机侧需要定期发送命令维持连接或者实现断线重连逻辑。我一般会在上位机做一个定时器每5秒发一次读命令既维持连接又刷新数据。实操心得节点地址请求命令的响应中第24字节开始是PLC分配的FINS节点号。如果这个值是0说明PLC没有分配成功需要检查PLC的FINS节点号设置是否与其它设备冲突。2.3 常用FINS命令码速查实际项目中最常用的命令就那么几条整理成表格方便查阅操作MRCSRC说明读CIO区0x010x01按字读取起始地址数量写CIO区0x010x02按字写入起始地址数据读DM区0x020x01按字读取起始地址数量写DM区0x020x02按字写入起始地址数据读CIO位0x010x01按位读取起始地址数量强制置位0x230x01强制CIO位ON强制复位0x230x02强制CIO位OFF读CPU状态0x060x01读取CPU运行状态读命令的响应帧中命令数据部分第一个字节是结束码0x00表示正常其它值表示错误。结束码后面才是实际数据按大端序排列。比如读DM0开始的2个字响应数据是4个字节高字节在前。3. PLC侧以太网参数配置实操3.1 硬件连接与IP地址设定CP1H加装CP1W-CIF41后用网线把选件板的RJ45口连接到交换机。注意CP1W-CIF41是百兆口不支持千兆自适应如果交换机是千兆口需要确认端口能向下兼容百兆。我遇到过某品牌交换机千兆口对百兆设备兼容性不好换到百兆口就正常了。IP地址设定通过CX-Programmer软件完成。打开工程后在左侧树形菜单找到设置-内置以太网端口如果是选件板则选选件板以太网端口双击打开设置界面。这里需要填几个关键参数IP地址根据车间网络规划填写比如192.168.1.10子网掩码通常255.255.255.0FINS节点号1-254之间的唯一值不能与网络上其它FINS设备冲突FINS/UDP端口默认9600一般不改FINS/TCP端口默认9600一般不改设置完成后需要下载到PLC并断电重启以太网参数才会生效。这里有个坑CX-Programmer在线修改以太网设置后必须断电重启软复位不行。我当初不知道改完IP后死活连不上折腾了半小时才发现要断电。3.2 路由表与网络参数配置如果PLC和上位机不在同一网段还需要配置路由表。CP1H的路由表在设置-路由表中配置需要填写目标网络号、目标节点号、网关地址。同网段通讯时路由表可以不管但FINS帧头中的DNA和DA1要填0。网络参数中还有一个FINS节点号自动分配选项如果勾选PLC会在FINS/TCP连接建立时自动分配节点号。我一般建议不勾选手动指定固定节点号方便上位机程序硬编码。注意修改以太网参数后务必用CX-Programmer的在线工作确认参数已写入。有时候下载过程中断会导致参数不完整PLC重启后以太网口不工作。3.3 用CX-Programmer做通讯测试CX-Programmer自带FINS/TCP测试功能可以在不写代码的情况下验证PLC以太网通讯是否正常。操作路径在线工作后选择PLC-通讯设置在通讯设置对话框中选择以太网(FINS/TCP)填入PLC的IP地址和端口号点击测试按钮。如果连接成功会显示PLC的型号和节点号。这个测试功能底层就是发FINS/TCP命令可以用来快速排查是PLC侧问题还是上位机代码问题。我习惯在项目初期先用CX-Programmer测试通过再写上位机代码这样能把问题范围缩小。测试时如果报无法连接按以下顺序排查先ping PLC的IP地址确认网络层通不通再用telnet连PLC的9600端口确认TCP层通不通最后用CX-Programmer的FINS/TCP测试确认FINS层通不通。三层逐一排查基本能定位到问题所在。4. 上位机FINS/TCP客户端实现4.1 用Python快速搭建测试客户端正式项目用C#或C写但调试阶段我强烈建议先用Python快速验证协议。Python的socket库足够底层能精确控制每个字节而且改起来快。下面是一个最小可用的FINS/TCP客户端示例import socket import struct class FinsTcpClient: def __init__(self, ip, port9600): self.ip ip self.port port self.sock None self.dest_node 0 self.src_node 0 def connect(self): self.sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.settimeout(3.0) self.sock.connect((self.ip, self.port)) self._node_address_request() def _node_address_request(self): # TCP帧头: FINS 长度(12) tcp_header bFINS struct.pack(I, 12) # FINS帧头: ICF0, 其余全0 fins_header bytes(12) # 命令数据: 客户端节点号(4字节, 填0让服务器分配) cmd_data struct.pack(I, 0) self.sock.send(tcp_header fins_header cmd_data) resp self.sock.recv(1024) # 响应中第24字节开始是分配的节点号 self.dest_node resp[23] self.src_node resp[19] def read_dm(self, start_addr, count): # 构造FINS命令 fins_cmd struct.pack(BB, 0x01, 0x01) # MRC, SRC fins_cmd struct.pack(H, start_addr) # 起始地址 fins_cmd struct.pack(H, count) # 读取数量 # FINS帧头 fins_header struct.pack(BBBBBBBBBBBB, 0x80, # ICF 0x00, # RSV 0x02, # GCT 0x00, # DNA 0x00, # DA1 self.dest_node, # DA2 0x00, # SNA 0x00, # SA1 self.src_node, # SA2 0x00, # SID 0x00, 0x00) # 填充 # 组装完整帧 payload fins_header fins_cmd tcp_header bFINS struct.pack(I, len(payload)) self.sock.send(tcp_header payload) resp self.sock.recv(1024) # 解析响应 end_code resp[20] if end_code ! 0: raise Exception(fFINS error: {end_code}) data resp[22:] return struct.unpack(f{count}H, data[:count*2])这段代码的关键点在于FINS帧头的构造。ICF填0x80表示需要响应GCT填0x02表示网关数量DA2填PLC的节点号SA2填上位机的节点号。SID我填0实际项目中应该递增用来匹配请求和响应。4.2 C#生产级客户端的关键设计Python验证通过后生产环境我一般用C#重写。C#的异步socket模型更适合长时间运行的采集程序。核心设计要点有三个第一连接管理要独立成一个类封装连接、断开、重连逻辑。重连采用指数退避策略第一次断线后1秒重连第二次2秒第三次4秒最多退到30秒。这样既能快速恢复又不会在PLC断电时疯狂重连把网络打满。第二命令发送和响应接收要分离。用一个队列存放待发送命令另一个队列存放已发送待响应的命令。发送线程从待发送队列取命令发送后把命令移到待响应队列并记录时间戳。接收线程收到响应后根据SID从待响应队列中找到对应命令完成回调。如果超时一般设500ms从待响应队列移除并触发超时回调。第三数据解析要处理粘包和半包。TCP是流式协议一次recv可能收到多个响应帧也可能只收到半个帧。我的做法是维护一个接收缓冲区每次recv后追加到缓冲区然后循环检查缓冲区头部如果缓冲区长度小于8等待更多数据如果魔术字不是FINS清空缓冲区重新同步如果长度字段大于缓冲区剩余长度等待更多数据否则取出完整帧处理。4.3 批量读写与性能优化单点读写效率太低实际项目都是批量操作。FINS协议单次最多读990个字CIO区或999个字DM区但实际测试发现单次读500个字以上响应时间明显增加。我的经验是单次读200-300个字比较合适响应时间在20ms以内。如果需要读取大量连续地址可以分多次读每次读200个字。比如读DM0到DM999分5次读每次200个字。这样总时间大约100ms比单次读1000个字可能超时更可靠。写操作同理单次写不要超过200个字。另外写操作要注意FINS协议没有原子性保证如果写200个字的过程中连接断开可能只写入了前100个字。对数据一致性要求高的场景需要写完后回读校验。实操心得FINS/TCP的响应时间跟PLC的扫描周期有关。如果PLC扫描周期是10ms那么FINS命令最快也要等一个扫描周期才能被处理。所以不要指望响应时间低于PLC扫描周期。我一般会把上位机的超时时间设为PLC扫描周期的3-5倍。5. 调试实战与问题排查5.1 用Wireshark抓包分析FINS/TCP调试FINS/TCP最有效的工具是Wireshark。在交换机上做端口镜像或者在上位机装Wireshark直接抓本机网卡。过滤器填tcp.port 9600就能看到所有FINS/TCP通讯。抓包后重点看三个地方一是TCP三次握手是否正常如果SYN发出后没有SYN-ACK说明PLC的9600端口没开或者网络不通二是节点地址请求的响应看PLC分配的节点号是多少三是读写命令的响应看结束码是否为0。我遇到过一个诡异问题TCP连接正常节点地址请求也正常但读命令发出去后PLC不响应。抓包发现PLC收到了命令但没回。后来查手册发现FINS帧头中的GCT字段我填了0x00应该填0x02。GCT是网关数量填0表示没有网关PLC会忽略这个命令。改成0x02后立刻正常。5.2 常见错误码与排查方法FINS响应中的结束码是排查问题的关键。整理几个常见的结束码含义排查方向0x00正常无0x01命令码错误检查MRC/SRC是否正确0x02地址越界检查起始地址数量是否超出区域范围0x03数据长度错误检查读写数量是否超出限制0x20目标节点未响应检查PLC节点号是否正确0x21目标节点忙降低通讯频率增加间隔0x22网络未就绪检查PLC以太网口状态0x23路由错误检查路由表配置0x24目标节点不存在检查FINS节点号是否冲突0x21错误我遇到最多一般是上位机发送频率太高PLC来不及处理。解决办法是在两次命令之间加10-20ms延时或者降低采集频率。CP1H的FINS处理能力有限实测每秒最多处理50-60条命令超过这个频率就会报0x21。5.3 网络基础设施的坑FINS/TCP虽然跑在标准TCP/IP上但车间网络环境跟办公室不一样。我踩过的坑包括交换机端口隔离导致PLC和上位机不通有些工业交换机默认开启端口隔离VLAN划分导致跨网段不通需要配置路由表网线质量差导致丢包工业环境一定要用屏蔽网线。还有一个容易被忽略的点PLC的以太网口和选件板以太网口可能不在同一网段。CP1H-Y本体有一个以太网口CP1W-CIF41选件板也有一个两个口可以配不同IP。如果上位机连的是本体口但FINS节点号配在选件板上就会连不上。我一般建议只用选件板口本体口留作备用。注意CP1W-CIF41选件板的以太网口不支持自动MDI/MDIX连接交换机时可能需要交叉线。不过现在大部分交换机都支持自动翻转直通线也能用。如果连不上先换根线试试。5.4 长时间运行的稳定性保障产线设备要求7x24小时运行FINS/TCP连接的稳定性至关重要。我在项目中加了几个保障机制第一心跳检测。上位机每5秒发一次读CPU状态命令MRC0x06, SRC0x01如果连续3次超时判定连接断开触发重连。第二断线重连。重连时先关闭旧socket再新建socket避免socket泄漏。重连成功后重新发节点地址请求因为PLC可能分配了不同的节点号。第三日志记录。所有发送和接收的原始字节都记录到日志文件按天分割保留30天。出问题时可以回溯分析。日志文件我一般用二进制格式比文本格式省空间解析也快。第四看门狗。上位机程序启动一个看门狗线程如果采集线程超过10秒没有更新数据看门狗触发报警并尝试重启采集线程。这套机制跑了一年多除了计划内停机没有因为通讯问题停过线。最惊险的一次是车间网络改造交换机被换掉IP网段变了但上位机程序自动重连后通过DHCP拿到了新IP居然自己恢复了。当然这是运气好正规做法还是应该用固定IP。6. 从FINS/TCP到OPC UA的演进思考FINS/TCP解决了CP1H的以太网通讯问题但它毕竟是欧姆龙的私有协议上位机需要针对FINS写专门的代码。如果产线有多个品牌的PLC每个品牌都要写一套通讯代码维护成本很高。后来我在新项目里开始用OPC UA做统一接入。CP1H本身不支持OPC UA但可以通过中间网关转换。网关从CP1H读FINS/TCP再以OPC UA Server的形式对外提供数据。上位机只需要实现OPC UA客户端就能同时访问多个品牌的PLC。这个方案的好处是解耦上位机不关心底层是FINS还是Modbus还是EtherNet/IP只关心数据模型。坏处是增加了一个网关设备成本和故障点都增加了。对于只有欧姆龙PLC的产线直接用FINS/TCP更简单直接对于多品牌混线OPC UA网关更合适。我个人的选择是小项目单品牌、点数少直接用FINS/TCP大项目多品牌、点数多上OPC UA网关。没有绝对的好坏看场景。最后分享一个调试小技巧FINS/TCP调试时可以先用CX-Programmer的FINS/TCP测试功能确认PLC侧正常再用Python脚本验证协议实现最后才写生产代码。这个顺序能把问题隔离在最小范围内避免同时调试PLC和上位机代码。我当初就是没按这个顺序来PLC和代码同时调出了问题不知道是哪边的问题白白多花了两天时间。