企业官网建设流程全解析

1. 搞懂FINS协议前，先弄明白它到底解决什么问题

很多人第一次接触欧姆龙PLC通信的时候，脑子里冒出来的第一个词就是FINS。但真要问FINS是什么、为什么需要它、跟其他协议有什么区别，能说清楚的人其实不多。我刚开始做产线数据采集那会儿，也是被各种协议名词绕得头晕，直到在一个实际项目里被逼着从零啃了一遍FINS的手册，才算真正搞明白它的定位。

FINS全称是Factory Interface Network Service，翻译过来就是工厂接口网络服务。这个名字听起来很唬人，但说白了它就是欧姆龙自家的一套通信协议，用来让上位机（比如工控机、SCADA系统、MES系统）跟欧姆龙的PLC、运动控制器、传感器等设备进行数据交互。你可以把它理解成欧姆龙设备之间、以及欧姆龙设备与上位机之间的一种“普通话”——只要双方都说FINS，不管底层走的是串口、以太网还是其他总线，都能互相听懂。

那它解决了什么问题呢？最核心的一点就是统一寻址。在没有FINS之前，你要读写不同型号PLC的不同区域，可能需要用不同的命令格式、不同的地址表达方式，换一个型号就得重新写一遍代码。FINS把这些差异抽象掉了，它定义了一套统一的命令帧格式和地址空间模型，你只要按照FINS的规则发指令，PLC那边就能正确解析并返回结果。这对于做数据采集和远程控制的人来说，省了太多事。

这篇文章适合谁看？如果你是做工业自动化的工程师、上位机软件开发人员、设备集成商的技术人员，或者单纯是对PLC通信感兴趣想入门的初学者，那这篇内容应该能帮你省下不少翻手册的时间。我会从协议结构、通信建立、命令读写、常见坑几个维度，把FINS协议拆开揉碎讲清楚，尽量用大白话把那些手册里绕来绕去的术语翻译成人话。

2. FINS协议的核心架构与通信模型拆解

2.1 FINS的分层设计思路

FINS协议在设计上采用了一种分层的思想，但它不像TCP/IP那样有严格的七层模型，而是更偏向实用主义的精简分层。你可以把它大致分为两层：命令层和传输层。

命令层负责定义“要做什么”——比如读数据、写数据、读设备状态、强制置位等等。这一层定义了具体的命令码（Command Code）和响应码（Response Code），以及数据的排列格式。传输层负责定义“怎么送过去”——FINS帧可以通过多种物理载体传输，包括串口（Host Link模式下的FINS）、以太网（FINS/TCP或FINS/UDP）、以及控制器之间的网络（Controller Link、EtherNet/IP等）。

这种分层的好处是，命令层的定义跟传输层解耦了。也就是说，你学会了FINS的命令格式，不管底层是以太网还是串口，命令部分是一样的，只是外面包的“信封”不同。这就像你写信的内容不变，但可以通过平邮、快递、电子邮件等不同方式寄出去。

2.2 FINS帧的基本结构

一个完整的FINS帧由头部和数据区两部分组成。头部包含了目标节点信息、源节点信息、命令码等元数据，数据区则是具体的操作参数。

以FINS/TCP为例，一个典型的命令帧结构如下：

这12个字节的头部是FINS命令的“标配”，不管你是读DM区还是写CIO区，这部分格式都是固定的。理解这个头部结构是读懂FINS协议的第一步，也是最关键的一步。

2.3 地址空间模型：DM区、CIO区、WR区到底有什么区别

FINS协议里最让人头大的可能就是各种数据区域的命名了。DM区、CIO区、WR区、HR区、AR区……新手看到这些缩写往往一脸懵。我用一个类比来解释：把PLC的内存想象成一栋大楼，不同的区域就是不同的楼层，每个楼层有自己的房间编号规则。

DM区（Data Memory）是最常用的数据存储区，相当于大楼里的“仓库”。它只能以字（16位）为单位读写，地址范围通常是D0到D32767（不同型号有差异）。DM区掉电保持，适合存储配方参数、累计值这类需要断电保存的数据。

CIO区（Common I/O）相当于大楼的“控制面板”。它包含了输入输出继电器区、内部辅助继电器区、定时器区、计数器区等。CIO区可以按位操作也可以按字操作，地址表达方式比较灵活。比如CIO 0.00表示第0字的第0位，CIO 100表示第100个字。

WR区（Work Relay）是工作继电器区，相当于“临时工作台”。它掉电不保持，适合存放中间计算结果或临时状态。地址范围通常是W0到W511。

HR区（Holding Relay）是保持继电器区，掉电保持，地址范围H0到H511。AR区（Auxiliary Relay）是辅助继电器区，通常用于系统状态和控制位，部分地址有特定功能定义。

理解这些区域的差异非常重要，因为你在发FINS命令的时候，必须指定你要操作的是哪个区域。命令码里的内存区域代码就是用来区分这些区域的。比如读DM区的命令码是0x0101（MRC=01, SRC=01），读CIO区的命令码是0x0101但内存区域代码不同。

2.4 FINS/TCP与FINS/UDP的选择逻辑

FINS协议在以太网上传输时，有两种方式：FINS/TCP和FINS/UDP。这两种方式各有适用场景，选错了可能会遇到莫名其妙的通信问题。

FINS/TCP是面向连接的，通信前需要先建立TCP连接（默认端口9600），然后在这个连接上发送FINS帧。它的优点是可靠，有重传机制，适合对数据完整性要求高的场景，比如参数下发、配方切换。缺点是开销稍大，连接维护需要额外处理。

FINS/UDP是无连接的，直接发数据包，不需要建立连接。它的优点是轻量、快速，适合高频次的数据采集，比如每秒读几十次传感器状态。缺点是丢包不重传，需要应用层自己做超时和重试。

我个人的经验是：如果是做数据采集且对实时性要求高，用UDP；如果是做控制指令下发或者对可靠性要求极高，用TCP。当然，如果网络环境不稳定，UDP的丢包率可能会让你怀疑人生，这时候还是老老实实用TCP。

3. 手把手搭建FINS通信环境

3.1 硬件连接与网络配置要点

在开始写代码之前，得先把物理连接和网络配置搞定。这一步看起来简单，但实际项目中很多通信问题都出在这里。

首先确认PLC的以太网口型号。欧姆龙的NJ/NX系列通常自带以太网口，CS/CJ系列可能需要额外的以太网单元（比如ETN21）。确认硬件支持后，用网线把PLC和上位机连接到同一个交换机或直连。

接下来是IP地址配置。PLC的IP地址通常通过CX-Programmer或Sysmac Studio来设置。我建议给PLC分配一个固定的IP，不要用DHCP，否则IP变了之后你的程序就连不上了。上位机的IP要和PLC在同一网段，子网掩码一致。

注意：如果你用的是FINS/UDP，还需要确认PLC的FINS/UDP端口号（默认9600）没有被防火墙拦截。Windows防火墙有时候会默默地把UDP包丢掉，排查半天才发现是防火墙的问题。

还有一个容易忽略的点是节点地址（Node Address）的设置。FINS协议里每个设备都有一个节点地址，范围通常是1到254。以太网通信时，节点地址通常是IP地址的最后一段，但也可以手动设置。如果节点地址冲突，通信会出问题。我遇到过两次因为节点地址重复导致通信时断时续的情况，查了好久才定位到。

3.2 上位机端FINS通信库的选择

上位机要跟PLC通信，可以选择自己组帧发送，也可以用现成的通信库。自己组帧的好处是理解深刻、可控性强，缺点是工作量大、容易出错。用现成库的好处是开发快，缺点是遇到问题不好排查。

常见的FINS通信库有：

• Python：pyfins、omron-fins等第三方库，也有直接用socket自己组帧的方案
• C#：HslCommunication（国内用得比较多）、OmronFins等
• Java：jFINS等
• C++：通常直接socket编程或使用厂商提供的API

如果你只是想快速验证通信是否正常，我建议先用Python写个简单的测试脚本，用socket直接发FINS帧。这样你能清楚地看到每一字节的内容，对理解协议非常有帮助。等验证通了，再考虑用封装好的库来提高开发效率。

3.3 用Python实现一个最小可用的FINS/TCP客户端

下面我用Python写一个最简单的FINS/TCP客户端，实现读取DM区数据的操作。这个例子会帮你把前面讲的帧结构真正串起来。

import socket import struct def build_fins_tcp_header(command_length): # FINS/TCP帧头：魔术字"FINS" + 长度 + 命令码 + 错误码 magic = b'FINS' length = struct.pack('>I', command_length + 8) command = struct.pack('>I', 0x00000002) # 2表示FINS帧发送 error_code = struct.pack('>I', 0) return magic + length + command + error_code def build_fins_command(dna, da1, da2, sna, sa1, sa2, mrc, src, data): icf = 0x80 # 需要响应 rsv = 0x00 gct = 0x02 # 经过网关 sid = 0x01 # 服务ID header = struct.pack('BBBBBBBBBB', icf, rsv, gct, dna, da1, da2, sna, sa1, sa2, sid) command = struct.pack('BB', mrc, src) return header + command + data def read_dm_area(plc_ip, plc_port, dm_address, count): # 构建读取DM区的FINS命令 # MRC=0x01, SRC=0x01 表示内存区域读取 # 数据部分：内存区域代码(0x82=DM) + 起始地址 + 位数 + 数量 memory_code = 0x82 # DM区 start_addr = struct.pack('>H', dm_address) bit_position = 0x00 # 按字读取 read_count = struct.pack('>H', count) data = struct.pack('B', memory_code) + start_addr + struct.pack('B', bit_position) + read_count fins_cmd = build_fins_command(0, 0, 0, 0, 0, 0, 0x01, 0x01, data) tcp_header = build_fins_tcp_header(len(fins_cmd)) sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(5) sock.connect((plc_ip, plc_port)) sock.send(tcp_header + fins_cmd) response = sock.recv(1024) sock.close() # 解析响应：跳过FINS/TCP头(16字节)和FINS头(10字节) fins_response = response[16:] end_code = struct.unpack('>H', fins_response[10:12])[0] if end_code != 0: print(f"通信错误，结束码：{hex(end_code)}") return None # 解析数据部分 data_part = fins_response[12:] values = [] for i in range(count): val = struct.unpack('>H', data_part[i*2:(i+1)*2])[0] values.append(val) return values # 使用示例 if __name__ == '__main__': result = read_dm_area('192.168.1.10', 9600, 100, 10) if result: print(f"DM100-DM109的值：{result}")

这段代码虽然不长，但包含了FINS/TCP通信的完整流程：建立TCP连接、构建FINS/TCP帧头、构建FINS命令帧、发送、接收、解析响应。你可以拿它作为起点，逐步扩展出写数据、读CIO区、批量读取等功能。

提示：实际项目中，PLC的IP地址和端口号需要根据你的实际配置来修改。另外，FINS/TCP的默认端口是9600，但有些项目会改成其他端口，记得确认。

3.4 用FINS/UDP实现高频数据采集

如果你的场景是高频采集，比如每100毫秒读一次数据，那UDP会更合适。UDP的代码比TCP简单一些，不需要建立连接，直接发就行。

import socket import struct def read_dm_udp(plc_ip, plc_port, dm_address, count): memory_code = 0x82 start_addr = struct.pack('>H', dm_address) bit_position = 0x00 read_count = struct.pack('>H', count) data = struct.pack('B', memory_code) + start_addr + struct.pack('B', bit_position) + read_count fins_cmd = build_fins_command(0, 0, 0, 0, 0, 0, 0x01, 0x01, data) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(2) sock.sendto(fins_cmd, (plc_ip, plc_port)) try: response, _ = sock.recvfrom(1024) end_code = struct.unpack('>H', response[10:12])[0] if end_code != 0: return None data_part = response[12:] values = [struct.unpack('>H', data_part[i*2:(i+1)*2])[0] for i in range(count)] return values except socket.timeout: return None finally: sock.close()

UDP模式下，FINS帧不需要FINS/TCP的那层头部，直接发FINS命令帧就行。这也是为什么UDP更轻量的原因。

4. FINS命令详解与实战案例

4.1 内存区域读取命令的完整拆解

内存区域读取是FINS协议里最常用的命令，命令码是MRC=0x01、SRC=0x01。这个命令可以用来读取DM区、CIO区、WR区、HR区等几乎所有数据区域。

命令的数据部分格式如下：

内存区域代码的取值需要特别注意，不同区域的代码不一样：

响应帧的数据部分就是读取到的数据，按大端序排列。如果读的是字数据，每个字占2字节；如果读的是位数据，每个位占1字节（0x00或0x01）。

4.2 内存区域写入命令的注意事项

写入命令的命令码是MRC=0x01、SRC=0x02。数据部分的格式跟读取类似，只是在读取数量后面加上了要写入的数据。

写入操作有几个坑需要注意：

第一，写入DM区时数据长度必须匹配。比如你声明写10个字，那后面必须跟20字节的数据，少一个字节PLC都会返回错误码。

第二，写入CIO区时要注意位/字模式。如果你是按位写，位位置字段要填具体的位号（0-15），写入数据每个位占1字节。如果你是按字写，位位置填0x00，写入数据每个字占2字节。

第三，写入操作可能被PLC的状态限制。如果PLC处于PROGRAM模式或者被其他设备锁定，写入命令会失败。这时候需要检查PLC的运行状态。

第四，批量写入时注意单帧数据量限制。FINS协议单帧最大数据量通常是2000字节左右，超过这个限制需要分多次写入。我一般会把批量写入控制在500字以内，避免帧过长导致通信不稳定。

4.3 实战案例：读取产线计数器并写入MES系统

假设你有一个产线，PLC的DM100寄存器里存的是当班产量，DM101存的是累计产量。你需要每隔5秒读取这两个值，然后写入MES系统的数据库。

这个场景的实现思路是：用Python写一个定时采集脚本，通过FINS/UDP读取DM100和DM101的值，然后通过数据库接口写入MES。

import time import struct import socket import pymysql def read_production_data(plc_ip, plc_port): # 读取DM100-DM101，共2个字 memory_code = 0x82 start_addr = struct.pack('>H', 100) bit_position = 0x00 read_count = struct.pack('>H', 2) data = struct.pack('B', memory_code) + start_addr + struct.pack('B', bit_position) + read_count fins_cmd = build_fins_command(0, 0, 0, 0, 0, 0, 0x01, 0x01, data) sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(2) sock.sendto(fins_cmd, (plc_ip, plc_port)) try: response, _ = sock.recvfrom(1024) end_code = struct.unpack('>H', response[10:12])[0] if end_code != 0: return None data_part = response[12:] shift_output = struct.unpack('>H', data_part[0:2])[0] total_output = struct.unpack('>H', data_part[2:4])[0] return shift_output, total_output except socket.timeout: return None finally: sock.close() def write_to_mes(shift_output, total_output): conn = pymysql.connect(host='mes_db_host', user='user', password='pass', database='production') cursor = conn.cursor() sql = "INSERT INTO production_data (shift_output, total_output, timestamp) VALUES (%s, %s, NOW())" cursor.execute(sql, (shift_output, total_output)) conn.commit() cursor.close() conn.close() if __name__ == '__main__': while True: result = read_production_data('192.168.1.10', 9600) if result: shift_output, total_output = result write_to_mes(shift_output, total_output) print(f"采集成功：当班产量={shift_output}，累计产量={total_output}") else: print("采集失败，等待重试") time.sleep(5)

这个脚本虽然简单，但已经包含了工业数据采集的核心逻辑：定时读取、异常处理、数据入库。实际项目中你可能还需要加上日志记录、断线重连、数据缓存等功能。

4.4 多PLC组网时的FINS路由配置

在实际产线中，往往有多台PLC分布在不同的工位上，上位机需要同时跟多台PLC通信。这时候FINS的网络路由功能就派上用场了。

FINS协议支持多级网络路由，通过DNA（目标网络地址）、DA1（目标节点地址）、DA2（目标单元地址）三个字段来定位目标设备。如果上位机和PLC在同一个网络里，DNA通常填0，DA1填PLC的节点地址，DA2填0。如果需要跨网段通信，DNA就要填目标网络的网络号，网关设备会自动转发。

我做过一个项目，上位机在办公网，PLC在产线网，两个网络通过一个网关模块连接。这种情况下，FINS帧的DNA要填产线网的网络号，DA1填PLC节点地址，GCT（网关计数）要设为2，表示经过两个网关。如果GCT设错了，帧会被网关丢弃，通信就会失败。

注意：跨网段通信时，网络号和节点地址的规划非常重要。建议在项目初期就把网络拓扑和地址分配表做好，不然后期排查问题会非常痛苦。

5. 常见通信故障与排查技巧实录

5.1 FINS通信故障速查表

5.2 我踩过的那些坑

第一个坑：节点地址冲突。有一次在客户现场调试，通信总是时断时续，有时候能通有时候不通。查了IP、查了网线、查了防火墙，都没问题。最后发现是两台PLC的节点地址设成了同一个值，导致FINS响应有时候被错误的设备接收了。把节点地址改成唯一的之后，问题立刻解决。

第二个坑：UDP缓冲区溢出。有个项目用UDP做高频采集，频率是每50毫秒一次。跑了一段时间后发现偶尔会丢数据。排查后发现是PLC的UDP接收缓冲区满了，因为发送频率太高，PLC处理不过来。后来把频率降到200毫秒一次，问题就消失了。所以UDP虽然快，但也要考虑PLC的处理能力。

第三个坑：FINS/TCP连接未正确关闭。用TCP模式时，如果程序异常退出没有关闭连接，PLC那边的连接资源不会被立即释放。下次再连接时可能会被拒绝。解决办法是在程序里加异常处理，确保连接被正确关闭，或者设置连接超时时间让PLC自动释放。

第四个坑：地址表达方式混淆。欧姆龙PLC的地址表达方式有几种，比如DM区可以用D100表示，也可以用DM100表示，但在FINS命令里必须用数字地址。我刚开始的时候把D100直接当成100填进去，结果读出来的数据完全不对。后来才搞明白，D100对应的FINS地址就是100，但CIO区的地址表达方式又不一样，需要转换。

第五个坑：字节序问题。FINS协议使用大端序（Big-Endian），而x86架构的PC是小端序。如果你用C语言直接memcpy结构体，字节序会反掉。Python的struct模块用'>'前缀可以指定大端序，但如果你用其他语言，一定要确认字节序处理正确。

5.3 提高通信稳定性的几个实用技巧

第一，加心跳检测。定期发送一个简单的读取命令，确认PLC还在线。如果连续几次超时，就触发重连逻辑。

第二，做数据缓存。如果通信中断，先把采集任务缓存起来，等通信恢复后补传。这在MES数据采集场景里特别重要，丢数据可能会影响生产报表的准确性。

第三，控制采集频率。不要盲目追求高频采集，先确认PLC的处理能力。一般来说，NJ/NX系列的处理能力比较强，CS/CJ系列相对弱一些。我一般会从500毫秒开始试，如果稳定再逐步降低间隔。

第四，用TCP做控制，UDP做采集。控制指令对可靠性要求高，用TCP；数据采集对实时性要求高，用UDP。两者结合，各取所长。

第五，记录通信日志。把每次通信的请求帧、响应帧、时间戳都记录下来。出问题的时候，这些日志就是最好的排查依据。我一般会把日志按天分割，保留最近30天。

6. FINS协议在不同场景下的扩展应用

6.1 与SCADA系统集成时的注意事项

SCADA系统通常支持多种通信协议，FINS是其中比较常见的一种。在集成时，需要注意SCADA系统的驱动版本是否支持你的PLC型号。有些老版本的驱动可能不支持NJ/NX系列的新PLC。

另外，SCADA系统通常会对FINS通信做一层封装，你只需要配置IP地址、节点地址、数据点表就行。但数据点表的地址格式要跟FINS的地址格式对应上。比如DM区的D100，在SCADA里可能配置成"DM100"或"D100"，具体要看驱动的定义。

6.2 通过FINS实现PLC间的数据交换

FINS不仅支持上位机跟PLC通信，还支持PLC跟PLC之间的通信。在欧姆龙的PLC里，可以通过FINS指令（比如SEND、RECV、CMND）来实现PLC间的数据交换。

这种方式的优势是不需要上位机参与，PLC之间直接通信，响应更快。缺点是配置相对复杂，需要在PLC程序里写通信指令，调试起来没有上位机那么方便。

我做过一个项目，两台PLC需要共享一些状态数据，用FINS的SEND/RECV指令实现。配置的时候需要注意网络地址和节点地址的对应关系，以及数据区的映射。调试的时候可以用CX-Programmer的在线监控功能来观察通信状态。

6.3 FINS协议在数据采集网关中的应用

现在很多数据采集网关都支持FINS协议，可以把PLC的数据采集上来，然后转换成MQTT、OPC UA等协议上传到云端。这种架构在工业物联网场景里很常见。

用网关的好处是不需要自己写通信代码，配置一下就行。但缺点是灵活性受限，如果有一些特殊的采集需求，网关可能不支持。我一般会建议客户先用网关做快速验证，如果功能满足就用网关，如果不够灵活再考虑自己开发。

6.4 FINS协议的安全考量

FINS协议本身没有加密机制，通信内容是明文的。如果在不可信的网络里传输，存在被窃听或篡改的风险。在实际项目中，我一般会建议把PLC网络和办公网络隔离，或者通过支持加密的网关设备来转发FINS通信。

另外，FINS协议没有严格的身份认证机制，任何知道IP地址和节点地址的设备都可以尝试通信。所以在安全要求高的场景里，需要在网络层做访问控制，限制只有授权的设备才能跟PLC通信。

7. 从协议理解到工程落地的经验总结

FINS协议本身并不复杂，但要在实际项目中用好它，需要关注的细节很多。我从最开始对着手册一行行啃，到后来能快速定位通信问题，中间踩了不少坑，也积累了一些经验。

最重要的一点是：先理解协议，再动手写代码。很多人一上来就找现成的库，调通了就完事，遇到问题就抓瞎。如果你能把FINS帧的结构、命令码的含义、地址空间的划分搞清楚，那不管用什么语言、什么库，你都能快速定位问题。

第二点是：做好网络规划和地址分配。FINS通信的很多问题都出在网络配置上，IP冲突、节点地址冲突、网关配置错误，这些问题在项目初期规划好就能避免。

第三点是：异常处理要到位。工业现场的网络环境往往不如办公网络稳定，通信中断是常态。你的程序必须能处理超时、重连、数据缓存这些情况，不能一断线就崩溃。

第四点是：日志和监控不能省。通信日志是排查问题的第一手资料，监控界面能让你快速发现异常。我一般会在采集程序里加一个简单的Web界面，实时显示通信状态和采集数据，方便现场调试。

最后分享一个小技巧：如果你不确定某个FINS命令的格式，可以用欧姆龙官方的通信测试工具先发一次，抓包看看实际的帧内容。这比对着手册猜要快得多。我刚开始学的时候就是这么干的，抓了几次包之后，帧结构就印在脑子里了。

FINS协议作为欧姆龙设备通信的基础，掌握它之后，你会发现很多工业通信协议的设计思路都是相通的。理解了FINS，再去看Modbus、EtherNet/IP、OPC UA，会容易很多。这个投入是值得的。