欧姆龙PLC的FINS协议详解：报文结构、地址映射与通信实战

1. 为什么绕不开 FINS：先从一次产线数据采集说起

1.1 一次典型的欧姆龙 PLC 接入场景

几个月前帮朋友看一个产线数据采集项目，现场用的是某款 CJ 系列 PLC，上位机要把一批 D 寄存器里的工艺参数弄到数据库里。朋友一开始想走 Modbus-TCP，结果翻了几百页手册发现欧姆龙这边原生支持的以太网协议是 FINS，官方也叫 Factory Interface Network Service。如果坚持用 Modbus，还得在 PLC 侧额外配置或者加协议转换模块，成本和技术风险都不划算。

那次排查的结论很简单：别绕，直接用 FINS。FINS 是欧姆龙自己定义的应用层协议，精通它的一个好处是，不管你是通过网络（FINS/TCP、FINS/UDP）还是串口（Host Link）跟 PLC 通信，只要地址和帧格式的规则通了，后面的开发大部分都是体力活。这篇文章就是我后来整理出来的完整笔记，从帧结构、地址映射、常用指令到排错经验，全部按项目实操的角度写。

适合谁看？一个是搞上位机软件、SCADA、MES 对接的工程师，另一个是刚接触欧姆龙 PLC、想搞明白网络通信的新手。读完至少能达到这个程度：不依赖库文件，自己用 Python 或 C# 拼出一帧 FINS 报文，并且知道收到响应后怎么解析。

1.2 FINS 解决的三个实际问题

FINS 出现在欧姆龙 PLC 体系里，其实就是为了解决三件通信上的麻烦事。

第一，跨网段路由。FINS 协议里专门设计了网络号（Network）、节点号（Node）、单元号（Unit）这三个编址概念。这意味着你可以通过路由一跳一跳地访问不同网段里的 PLC，而不需要在上位机上临时加一堆路由表。这一点在设备分散的工厂现场非常实用。

第二，不同型号之间的兼容。欧姆龙的 PLC 历史很长，从老式的 C 系列到后来的 CS/CJ/NJ/NX，寄存器叫法一直在变，但 FINS 用一套统一的内存区代码把 D、W、H、CIO 这些区域抽象了出来。上位机程序员不用关心底层是哪个型号，只要知道当前设备支持哪些内存区就行。

第三，上位机、HMI、PLC 之间互相通信。FINS 既可以由 PC 发起读写，也允许 PLC 主动向上位机发送数据。很多要求实时性比较高的场合，比如设备完成动作后立刻上报状态，直接让 PLC 通过 FINS 指令发帧给上位机，比上位机反复轮询更高效。

2. FINS 报文拆开看：命令帧里的每个字节都得认识

2.1 帧头：那 10 个字节到底在干什么

FINS 的报文结构并不复杂，但第一次接触的人很容易被一堆十六进制字节吓到。其实你只需要把它分成三段来理解：FINS 帧头（10 字节） + 命令区（2 字节） + 参数区（N 字节）。

先看帧头部分，这是整条报文最固定的部分。

以 UDP 通信为例，一个请求帧的完整组成如下：

为什么要特别强调 ICF？因为 ICF 的 bit0 到 bit2 是控制数据响应方向的标志，很多初学者拿到手册只知道填 0x80，但等到 PLC 返回响应帧时，发现第一字节变成了 0xC0，就以为报文错了。其实那是正常的，响应帧的 ICF 最高位会被置位，表示这是一条来自 PLC 的应答。

GCT 这个字段是当年为了支持多级网络设计的，普通局域网通信填 0x02 就好，别自作聪明填 0x80。DA1 和 SA1 是调试中最容易出错的字段，尤其要注意：PLC 侧设置的节点号必须和 DA1 保持一致，上位机发送时用的源节点号要和当地网络配置一致，否则 PLC 会直接丢弃这条请求。

2.2 命令区和参数区：真正干活的 MRC/SRC

帧头后面紧跟着两个字节，叫 MRC（主命令码）和 SRC（子命令码），它们组合在一起决定这条报文要做什么事情。

我整理了一份高频命令速查表，日常开发基本逃不出这几条：

MRC 和 SRC 本身不携带地址信息，真正的干活参数在后面。比如内存区读取（0101）的参数部分就是：区代码（1 字节）、起始地址（2 字节）、读取长度（2 字节）。也就是说，每次必须把“读哪里、从哪开始、读多少”这三件事交代清楚。

FINS 还有一个让多数工程师觉得友好的设计：报文里没有 CRC 校验码。这在当时是为了降低协议复杂度，让 PLC 这种资源紧张的嵌入式设备能快速处理，但同时也意味着你在应用层必须自己处理好超时重试。如果用 UDP，还得靠 SID 和超时机制来保证可靠性。这点我后面会详细讲。

3. 地址映射：D、W、H、CIO 可不是拍脑袋写的

3.1 内存区代码与位/字访问

FINS 协议里，内存地址不是直接填“D100”这种字符串，而是要转换成字节型的“区代码 + 地址数值”。区代码是协议里固定的，你写上位机时记住最常用的几个就够。

对于欧姆龙 CJ/CS/NJ 系列，我习惯用这套对应关系：

举个例子，如果你想读取 D100 开始的 10 个字，那么内存区读取命令的参数区域应该这么填：区代码 0x82，起始地址 0x00 0x64（100 的十六进制），读取数量 0x00 0x0A（10 个字）。

位访问的地址算法要特别注意。很多第一次写的人会直接把位号当地址填进去，比如想读 W10.03，地址却填成了 0x0003，这绝对错。FINS 的位地址计算方式是：字编号乘以 16，再加上位偏移。W10.03 对应的位地址是 10 × 16 + 3 = 163，也就是十六进制的 0x00A3。只要翻过这个错，位访问基本就通了。

3.2 不同系列 PLC 的前后兼容问题

有的老工程师可能印象里还有 IR、SR、TR 这些老式继电器区的叫法，那是在 C 系列年代。后来的 CS1/CJ1/CJ2/NJ 系列统一改成了 CIO 区，并保留了 W、H、D 这些常用区域，FINS 区代码的对应关系也跟着做了调整。

从实际项目角度看，我建议你不要把区代码背死，而是要养成“先看型号手册”的习惯。比如有些特殊模块地址落在 CIO 的扩展区里，光用 0x00 字访问还做不对，可能需要配合 CIO 区的高位扩展地址。再比如 NJ/NX 系列使用符号寻址更多，FINS 直连反而变成了兜底手段。

另外一个容易踩的坑是设备内存区的大小限制。不要以为协议支持 65535 个地址就一定能访问到，不同型号的 DM 区实际范围可能只有 32768 或更少。如果你批量读取时把地址加超了，PLC 会返回一个错误完成码，不会默默帮你截断。所以写通用程序时，最好把 PLC 型号对应的地址范围做成配置文件，不要写死在代码里。

4. 最常用的三类指令：读、写、强制

4.1 内存区读取（0101）

假设目标 PLC 节点号是 1，上位机节点号是 0，我们要读取 D100 开始的 10 个字。完整请求帧按十六进制写出来就是：

80 00 02 00 01 00 00 00 00 01 01 01 82 00 64 00 0A

前 10 字节是 FINS 帧头，第 11、12 字节是 01 01，表示内存区读取命令，后面从 0x82 开始是参数区。这条报文总共 17 字节。

注意起始地址和数量都是两个字节，而且必须按高位在前、低位在后的顺序排。D100 = 0x0064，所以地址部分是 00 64；10 个字 = 0x000A，所以数量部分是 00 0A。

收到响应后，帧头 10 字节不变，第 11、12 字节还是会原样返回 01 01。第 13、14 字节是完成码，0000 代表成功，如果出现其他值就要去查手册对应的错误含义。成功时，从第 15 字节开始就是纯数据区，每两个字节组成一个字。这里有个实用经验：不要只看第一个数据的值，先把返回的字节数和请求长度对一遍，因为有的 PLC 在访问非法地址时会返回正常完成码但数据区塞满 0。

4.2 内存区写入（0102）

写入命令和读取命令只有两个地方不同：SRC 从 01 变成 02，参数区最后多了一段要写入的数据。

比如向 D200 写入两个字，第一个字是 0x1234，第二个字是 0xABCD，请求帧是这样的：

80 00 02 00 01 00 00 00 00 01 01 02 82 00 C8 00 02 12 34 AB CD

前面到 00 02 为止和读取是一样的逻辑，后面的 12 34 AB CD 就是要写入的数据。写入数据的总字节数必须是偶数，因为 FINS 以字为基本单位组织数据。如果你打算写一个 8 位的字节，也得凑成一个字再写进去。

这里想提醒一件事：写入操作属于破坏性操作，尤其在生产环境里，一定要在调试软件里保留上一次写入值的记录。我见过不少同事在测试时把长度写错，一次写出去几十个字，把旁边的配方数据全冲掉了。所以写入前建议先发一条读取命令，把目标区域原值读回来打印在界面上，确认之后再写。

4.3 强制 ON/OFF（0103/0104）

强制类指令在调试设备时非常好用，比如你想单独测试某个气缸的输出位，又不想改梯形图，直接对 CIO 区或 W 区的一个位做强制置位就行。

强制置位命令是 0103，强制复位命令是 0104。参数区和读取命令相似，只是最后多了一个 2 字节的写入数据。对于位访问，写入数据一般用 0x0000 表示 OFF，0xFFFF 表示 ON。对于字访问，就把这个 2 字节数据当作要强制的值。

举个例子，强制 W10.03 为 ON。先按前面的公式算位地址：10 乘以 16 加 3 等于 163，也就是 0x00A3。请求帧为：

80 00 02 00 01 00 00 00 00 01 01 03 03 00 A3 FF FF

注意这里区代码是 0x03，因为 W 区位访问用的是 0x03。很多同学在这一步翻车，区代码写成了 0x02，那就是在强制作一个字，语义完全变了。

强制操作是有风险的动作：程序里如果同一个位既被强制，又被梯形图正常控制，运行状态会变得很难排查。所以在现场调试结束后，记得把不需要的强制全部复位。另外，某些安全回路里的输出点可能被 PLC 的辅助功能锁住，强制指令执行成功但外部输出不动，这不一定是协议问题，要结合 PLC 的程序逻辑和硬件接线来看。

5. 用 UDP 把报文真发出去：可运行的 Python 示例

5.1 为什么建议先从 UDP 起步

FINS 在以太网上有两种传输方式：UDP 和 TCP。如果只是做上位机数据采集，我强烈建议先从 UDP 版本入手。原因很简单：UDP 报文就是裸的 FINS 帧，十六进制结构和手册一一对应，调试时用抓包工具一眼就能看懂；而 FINS/TCP 外面还包了一层 TCP 头，包含命令代码、错误码、长度字段，初学者很容易把这层结构搅混。

UDP 的默认端口是 9600，PLC 侧配置好 IP 地址和节点号之后，用微信小程序、网络调试助手或者 Wireshark 就能直接看到报文。先通过简单工具确认链路通不通，再去写正式代码，效率高得多。

5.2 发送帧与接收响应的完整脚本

我贴一段项目里常用的小工具，功能是读取 D 区数据。代码做了最小化处理，方便你直接抄走改参数。

import socket PLC_IP = "192.168.0.10" PLC_PORT = 9600 PLC_NODE = 1 # PLC 侧设置的 FINS 节点号 PC_NODE = 0 # 上位机 FINS 节点号 def fins_read_dm(start, count, sid=1): # 10 字节 FINS 帧头 header = bytes([ 0x80, 0x00, 0x02, 0x00, PLC_NODE, 0x00, 0x00, PC_NODE, 0x00, sid ]) # 内存区读取命令 + 参数区 cmd = bytes([ 0x01, 0x01, # MRC=01, SRC=01 0x82, # DM 区，字访问 (start >> 8) & 0xFF, start & 0xFF, (count >> 8) & 0xFF, count & 0xFF ]) frame = header + cmd sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(2) sock.sendto(frame, (PLC_IP, PLC_PORT)) resp, _ = sock.recvfrom(1024) sock.close() if len(resp) < 15: raise ValueError("响应帧长度不完整") # 响应帧：头部10字节 + MRC/SRC 2字节 + 完成码2字节 + 数据区 command = resp[10:12] if command != b'\x01\x01': raise ValueError(f"命令码不匹配: {command.hex()}") completion = int.from_bytes(resp[12:14], "big") if completion != 0: raise ValueError(f"PLC 返回错误完成码: 0x{completion:04X}") data = resp[14:] words = [] for i in range(0, len(data), 2): if i + 1 < len(data): words.append(int.from_bytes(data[i:i+2], "big")) return words if __name__ == "__main__": result = fins_read_dm(start=100, count=10) for idx, val in enumerate(result): print(f"D{100 + idx}: 0x{val:04X} ({val})")

这段代码重点解释两个细节。

第一个是地址拆字节。start=100，就得用(start >> 8) & 0xFF取高字节，再用start & 0xFF取低字节。不要直接写出100的 ASCII 或者十进制文本，FINS 只认二进制字节。

第二个是响应帧的完成码位置。网上很多旧代码把完成码当成第 13、14 字节，那是因为他们用的报文结构里把 MRC/SRC 当作命令区后直接跟数据。以我这份精力核对过的结构为准：前 10 字节是帧头，第 11、12 字节是 MRC/SRC，第 13、14 字节才是完成码。不过也提醒一句：不同上位机库和网关透传工具可能在帧格式上做了二次封装，你要是用第三方组件，先抓包确认偏移量。

5.3 响应完成码与常见错误码

响应帧里的完成码是一个 2 字节大端整数。0000 表示一切正常，其他值就需要结合命令上下文判断。我挑几个实际遇到过的：

写程序时建议把完成码转成字符串输出到日志里，而不是只显示一个数字。故障发生时，一条清晰的错误提示比抓半天包有用得多。

6. FINS/TCP 与串口 Host Link：什么时候该换一种走法

6.1 UDP 和 TCP 的差异决定使用取舍

UDP 做采集足够快，但它有一个特点：无连接、不保证送达。在局域网里直接和 PLC 通信，丢包概率不高，但如果你要跨路由转发，或者现场网络里有大量的广播风暴，UDP 就会变得不稳定。

FINS/TCP 的好处是 TCP 自带重传和保序，链路断了马上知道，更适合长时间运行的关键任务。它的结构大概是：前面加一个 FINS/TCP 帧头，包含命令代码、错误码、总长度，后面才跟标准的 FINS 帧。端口同样是 9600，但是 TCP 会先建立连接，之后在这个连接上持续收发。

取舍很简单：

• 数据采集频率高、允许偶尔丢一帧重读的情况，优先 UDP。
• 需要上位机持续监控 PLC 状态、断开要快速报警的情况，考虑 TCP。
• 跨网段、多级路由的情况，UDP 配路由表更灵活，但也要评估链路稳定性。

我的经验是：普通车间内部用 UDP 足够了，但生产系统对接 MES 时，报文要上一层数据库，哪怕丢一帧数据都会造成质量追溯缺口，这时我更倾向 FINS/TCP，再配合 PLC 侧的“主动发送”或者上位机的高频轮询兜底。

6.2 串口 Host Link 的经典帧格式

不要以为所有欧姆龙 PLC 都带网口。老设备、小 PLC 往往只有串口。串口上跑的 FINS 变体叫 Host Link，帧格式和以太网 FINS 差别很大。

Host Link 报文的开头是一个@字符，然后是两位 PLC 单元号、两位命令码、中间是参数正文，最后是两位 FCS 校验码，以*和回车的 CR 结束。例如读取 D100 的 Host Link 帧看起来会像：

@0010RD00010000000A00FCS*CR

这里的命令码 RD 表示内存读取，数据长度和地址都用 ASCII 码表示，计算方式是“字地址乘 2 再转 ASCII”。也就是说 D100 实际上要换算成十六进制地址 0064，但 Host Link 是按字节地址计算的，要乘以 2，变为 00C8。很多人第一次从 FINS 切到 Host Link 就挂在这里。

如果你现在要开发的产品还需要兼容串口老设备，建议把 Host Link 单独封装一层通信驱动，别和以太网 FINS 混在一个对象里。两者的帧分隔、校验、地址算法完全不同，硬套逻辑会让代码充满 if 分支。本篇文章以 FINS 以太网为核心，Host Link 先记住这个坑，后面做项目遇到时再去翻具体型号手册。

7. 排查与避坑：几类让我耗过通宵的问题

7.1 收不到响应：先从节点号和网络号下手

收不到响应是 FINS 调试里最折磨人的问题。我见过太多人上来就抓包、改防火墙，折腾半天发现是 PLC 那边的节点号根本没设对。

排查顺序应该按这个来：

1. 确认 PLC 的 IP 地址和上位机在同一网段，不能通的情况下后面都白搭。
2. 用网络调试助手发一帧最简单的 FINS 报文，比如读取 CPU 状态，看 PLC 有没有回应。
3. 如果没回应，去 PLC 参数设置里检查 FINS 节点号。欧姆龙 PLC 的节点号默认可能不是 1，有人设了 3、有人设了 11，你的 DA1 必须和它一致。
4. 检查上位机节点号 SA1。有的 PLC 在设置里开启了节点号检查，SA1 是 0 或和别的设备冲突，都会被丢弃。
5. 最后再检查 Windows 防火墙、路由器端口映射、交换机端口隔离这些问题。

我遇到过一个情况：PLC 有两个 CPU 模块，用软件工具连的是第二个模块，但 DA2 还是填 0，导致请求全部发到了第一个模块。DA2（目标单元号）在多 CPU 系统里就等于选择哪个 CPU，现场千万别忽略。

7.2 多字数据读出来乱码：字节序最有嫌疑

FINS 协议本身用大端方式传数据，也就是高字节在前。很多 PLC 内部的 D 寄存器也是按高字节低字节顺序存储的，但等你把数据交给数据库或者上位机显示时，还要根据业务值做一次字节交换。

比如读回来一个浮点数 0x41200000，在欧姆龙 PLC 里可能是 D100 和 D101 两个字存的，究竟是 D100 存高 16 位还是低 16 位，不同程序写法会产生两种完全不同的结果。有的工程师写 C# 时直接用 BitConverter 转，结果发现所有数值都乘了个奇怪的系数，就是因为单字序和双字序没对齐。

我的建议是：在上位机代码里只做一层“数据转换层”，把原始字列表转成 float32、int32、BCD 等业务类型。这样 PLC 侧梯形图怎么排布双字，上位机只需改一个函数，不要在全工程里到处写解析逻辑。

7.3 响应超时和 SID 复用

SID 是服务 ID，用来把请求和响应配成一对。理想情况下，你每次发送请求时用递增的 SID，收到响应后对一下 SID，确保是当前请求的结果。

但当通信超时、你再次重发同一条命令时，一个很容易犯的错是：SID 仍然用之前那个值，而 PLC 网络栈里确实缓存着旧响应。结果就是你的程序收到了一个旧的响应，误以为这次重发成功了。更麻烦的是，有的 PLC 执行写命令后，数据已经写进去了，但响应因为网络原因没回到上位机，你超时后重发一次，等于把同一个值又写了一遍，问题不大；可如果中间现场被人工改过值，你的重发就成了破坏性操作。

所以重试逻辑一定要带两个条件：SID 必须递增，重试次数和冷却时间要可配置。我发现工业现场的通信故障常常是瞬时性的，几百毫秒级别，设置 500ms 到 1 秒的重试间隔通常就够。别一开始就把超时设成 10 秒，一旦 PLC 和上位机同时卡住，整个调度线程会越堵越深。

7.4 抓包工具看一眼，胜过十次瞎猜

调试 FINS 时我离不开 Wireshark，而且最好是直接用 Wireshark 自带的 FINS 过滤条件，比如fins或者按 UDP 端口 9600 过滤。

抓包的观察重点就这么几个：请求帧是不是完整 17 字节、DA1 和 SA1 是不是预期值、响应帧完成码是多少、耗时多少毫秒。很多时候你还没走到代码层面，抓包结果已经把问题指出来了。另外有些应用层的框架软件会把 FINS 帧打包成其他格式，比如通过网关转发的 Modbus 数据，这时候抓包反而会迷惑你，要记得区分原始协议和封装协议。

8. 最后的经验：从看懂到能干活还差什么

协议看懂了，帧也能拼了，但真正到了现场，你还会发现协议之外还有很多事项要落实。

我在实际项目里体会最深的一点是：工具链比协议本身更能决定调试效率。强烈建议你手里常备网络调试助手、Wireshark、一个可以自定义报文的脚本框架。别在公司开发的正式上位机里做实验，而是在一个独立测试工具里先把通信验证通，再搬进正式工程。

另外，FINS 报文没有校验码，这不代表你可以不做校验。UDP 在局域网里丢帧的概率虽然不高，但一旦发生，最好的对策是做好请求超时重发和日志记录。日志里把每一帧收发都留底，将来出问题能回溯。我们项目里上线初期碰到的很多诡异问题，最后都是靠日志里的原始帧数据定位的，不是靠猜。

如果你正在从串口通信转到以太网通信，我自己的经验是先把 UDP 版本跑通，再考虑 TCP。FINS 的地址映射、区代码、响应解析这些知识在两种传输方式里完全通用，先把一套传输通道吃透，后续扩展成本就会低很多。这份笔记写到这里，剩下就是你自己拿一台 PLC 或者一个模拟器，从 D100 开始读几个字，把它跑通，后面就顺了。