欧姆龙PLC通信协议全解析：Host Link到FINS的排错实战

做欧姆龙PLC的通信我前前后后折腾了小半年踩过的坑比走过的桥还多。从串口Host Link到以太网FINS从CP1H到NJ系列中间无数次对着示波器和串口调试助手发呆。今天把这套东西彻底捋一遍把我搞明白的事、踩过的坑、以及最后验证可行的排错路径全部写出来希望能帮你少走弯路。这篇文章适合这几类人刚入门PLC通信的电气工程师、做上位机开发要对接欧姆龙设备的朋友、以及那些正在被“PLC连不上”“数据读出来不对”折磨的现场调试人员。内容不涉及高深理论全是实打实的实操细节。1. 欧姆龙PLC通信协议的“全家福”别等接线了才去翻手册欧姆龙PLC的通信协议体系比西门子和三菱都要复杂一些因为它既有自有的FINS协议体系又兼容Host Link、Modbus-RTU等协议新老型号之间的协议支持能力还不一样。我刚开始接触时最困惑的就是这个明明都是欧姆龙PLC为什么CP1H和NJ/NX系列的通信配置方式完全不同后来才明白这跟产品线迭代路线有直接关系。1.1 串口时代的三个老家伙Host Link、Modbus-RTU、无协议模式CP1系列、CJ系列、CS系列这些中大型PLC一般自带串口RS-232C或RS-422A/485通信模式可以在CX-Programmer或Sysmac Studio里配置。Host Link上位机链接是欧姆龙最传统的串口协议用一个ASCII字符串构成命令帧比如00RD01000050FCS这种格式其中是帧头00是单元号RD是读命令后面跟起始地址和读取长度最后两位FCS是校验码。我在初学阶段最不习惯的就是这个FCS校验——它不是CRC或LRC而是把整帧ASCII字符的十六进制值逐字节异或之后取结果的最低两位十六进制字符补在帧尾。这个细节手册里有写但很多人第一次做Host Link通信时会漏掉结果上位机总是回复错误码。Modbus-RTU是欧姆龙后来才补上的。CP1H以太网口型号、CJ2M等可以通过串口或以太网口作为Modbus-RTU从站或主站。功能码主要用03读保持寄存器、06写单个寄存器、10写多个寄存器这几个。最需要注意的是欧姆龙的Modbus地址映射到PLC内部地址时有偏移规则比如保持寄存器40001对应PLC的DM区地址但不同型号的映射表不完全一致必须在手册里查“Modbus功能与PLC内存映射”那张表。无协议模式则是把串口当作自由口完全由用户自己拼帧来通信适合对接自定义协议的第三方设备。1.2 以太网时代的核心FINS协议FINSFactory Interface Network Service是欧姆龙自己的应用层协议承载在UDP或TCP之上。UDP端口号固定是9600TCP端口号也是9600。FINS帧的特点是有一个10字节的FINS Header后面跟着命令码和数据。举个例子读DM100开始的10个字命令码是0101帧结构看起来像这样46 49 4E 53 FINS ASCII标识部分型号没有 00 00 00 0C 命令长度UDP模式 80 00 02 00 FINS Header第一组字节 00 00 00 00 FINS Header第二组字节 00 00 FINS Header第三组字节 00 07 命令码01读取07字数据 01 01 子命令读取内存 82 00 64 00 0A 内存区代码起始地址长度FINS协议本身要记忆的点比较多但一旦理解了字节流结构后面排查问题就快多了。后面我会专门拿一节来讲FINS帧如何手工拆解。2. 最容易让人迷糊的内存区地址映射规则通信协议的坑有一半来自地址映射。我最初做上位机读PLC数据时明明在程序里看到数据在CIO区的W0.00里结果通过FINS读出来的数据跟梯形图里对不上后来才搞清楚地址计算方式。2.1 CIO区、WR区、DM区、HR区到底差在哪里这几个内存区是欧姆龙PLC最常见的CIO区I/O映射区包括输入输出、内部继电器等地址表示方式为CIO 0.00、CIO 100.05这种“字.位”结构。在FINS协议里CIO区的字地址就是纯数字地址。比如CIO 100这个字在FINS内存区代码中对应0x82地址就是100十进制0x0064。CIO 100.00这个位则在字地址100的基础上左移5位再加0得到位地址计算方式比较复杂建议查手册。WR区工作区相当于内部继电器在FINS协议中也属于CIO区的一部分内存区代码同样是0x82但地址从W0开始对应16进制0x0000开始算。欧姆龙的地址分配有个规律W区的字地址在FINS协议中就是从0开始计数而程序里显示的W0实际就是协议里的字地址0。这个转换很容易让人懵因为不同内存区在协议里的偏移基准不一样。DM区数据存储器按字访问协议内存区代码是0x82有的型号是0x80对应不同的协议命令。DM100在协议里的字地址就是100。HR区保持继电器区断电保持协议内存区代码同样是0x82但地址偏移规则又不同。我当时编制的对照表大概是这样的现在分享给你参考PLC内地址表示协议内存区代码十六进制协议字地址备注CI/O 0820000有的文档写作0000W0820000W区在FINS中位于CIO区地址块D100DM100820064十进制100→十六进制0064H0HR0820000有的型号HR区与CIO共用地址段注意不同系列PLC的FINS内存区代码可能有差异比如CJ2M的DM区代码和CP1H就不完全一样。做项目前先去下载对应的“通信命令参考”手册找到Memory Area Code那张表不要凭经验猜。2.2 Modbus-RTU的地址偏移协议地址与PLC地址相差1如果PLC作为Modbus-RTU从站地址偏移又是一个重灾区。Modbus协议规定保持寄存器的协议地址从0开始编号但功能码03读取时报文里的起始地址字段填0代表第一个保持寄存器。而我们在PLC程序里看到的DM区地址通常是从0或者从1开始。比如欧姆龙CP1H的Modbus-RTU从站协议地址0对应的就是DM0还是DM1答案是看手册不同型号可能不同。我在一个项目里用Modbus-RTU读CP1H的DM区数据上位机软件里填的地址是40001实际对应的是PLC的DM0但我的数据存在DM1导致读取结果偏移一个字节。后来才知道上位机的Modbus地址如果是40001对应协议地址0如果填40002对应协议地址1。所以PLC里数据放在DM1上位机必须填40002才能读到。这个“多1”还是“少1”的问题如果不先验证很容易栽进去。2.3 实操读写一个DM地址时我犯过的地址计算错误有一次现场调试客户要求把三个温度值从PLC通过Modbus-RTU传给触摸屏。我在PLC里把数据放在了D100、D101、D102触摸屏的Modbus地址按手册填了40001、40002、40003。结果是温度A显示正常温度B和温度C完全错乱。排查了半天才发现触摸屏的地址40001对应Modbus协议地址0而CP1H的Modbus从站地址映射表里协议地址0对应的是D0不是D100。也就是说想要读D100协议地址应该是100对应的Modbus地址40101。这个错误看起来简单但当时在冷库里冻了两个小时才反应过来就是因为没先查地址映射表。所以我的建议是第一次做通信时先在PLC里放一组递增的已知数值1、2、3、4……然后用上位机逐个地址去读读出来正好是1、2、3、4才说明地址映射对了。这个“先验证地址再联调”的习惯非常重要后面能救你无数次。3. 串口通信的坑Host Link连不上、Modbus-RTU数据对不上问题全都出在这三层串口通信看着简单但实际项目里八成的故障都出在物理连接、参数配置和帧格式这三层上。我把它们拆开讲每一个都是我亲自踩过的。3.1 参数配置层波特率、校验位、停止位、单元号一个都不能错Host Link和Modbus-RTU都是串口通信波特率、数据位、校验位、停止位必须完全一致否则收到的全是乱码或干脆没响应。但是“完全一致”只是第一层第二层是欧姆龙自己的单元号Unit Number。在Host Link协议里帧头后面的两位数字就是单元号默认是00。PLC侧必须把串口设置为Host Link模式同时单元号要和上位机发送的帧一致。如果PLC通信设置里的单元号是1而上位机发的是00RD...那PLC压根不响应。这个问题最容易在“把别人的程序拷过来改”的场景下出现——单元号放在PLC设置里而不是梯形图里容易遗漏。Modbus-RTU也有类似概念叫从站地址Slave Address范围1~247。如果上位机发的从站地址是1而PLC的Modbus从站地址配置成了2通信直接失败。我当时测试时用USB转485线插电脑后串口号都能识别但是Modbus Poll里怎么都连不上最后发现是PLC侧从站地址没改。3.2 硬件层485接线的A/B、终端电阻、地线以及USB转485的坑我遇到过最无语的一次Modbus-RTU通信时好时坏换了三台电脑都是这样后来发现是USB转485模块质量问题RS485芯片的驱动能力不够加上现场线缆过长导致信号畸变。RS485接线看似简单但有几个细节必须注意A/B线极性必须一致Modbus-RTU标准里A线有时叫D-和B线D一定要对应接反了通信完全不通。有些设备上标的是A和B-有些标的是A和B必须看说明书确认。终端电阻长距离通信超过100米时在链路两端各接一个120欧姆终端电阻可以防止信号反射。近距离几米到二三十米测试时可以不接但一旦测试不稳定先想终端电阻。地线问题RS485是差分信号理论上不依赖共地但如果两端设备的电源地电位差太大共模电压过高会把485芯片烧掉。我见过一个现场PLC和变频器之间距离虽然不远但变频器干扰大485芯片连续烧了两次后来在A、B线上加了TVS管和共模电感才稳定。3.3 帧校验层Host Link的FCS与Modbus的CRC帧校验是另一个串口通信中的大坑。Host Link用FCS校验Modbus-RTU用CRC16校验多项式0xA001低字节在前。写上位机时你可以直接用现成库比如C#的NModbus或者Python的pymodbus但如果你是自己拼帧Modbus-RTU的CRC计算绝对不能错。而且要特别注意CRC是低字节在前、高字节在后。这个字节序错误是很多人调试Modbus时报“通信超时”的常见原因——设备收到了帧但校验失败直接丢弃表现就是无响应。我写过一个Python测试脚本核心代码如下方便你在调试时验证通信链路import serial import struct def modbus_crc(data: bytes) - int: crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 else: crc 1 return crc # 读从站1保持寄存器起始地址0读5个字 cmd bytes([0x01, 0x03, 0x00, 0x00, 0x00, 0x05]) crc modbus_crc(cmd) frame cmd struct.pack(H, crc) ser serial.Serial(COM3, 9600, timeout1, parityserial.PARITY_NONE, stopbits1) ser.write(frame) resp ser.read(15) # 应答长度从站地址1功能码1字节数1数据10CRC2 print(resp.hex())这个脚本在验证“PLC作为Modbus从站”的通信链路时比任何第三方调试软件都可靠因为你能直接看到帧的每一个字节排查起来很清楚。4. 以太网FINS通信IP配置、节点号与抓包定位现在的新项目基本都走以太网了FINS协议也成了主流。但FINS的配置里有一个欧姆龙特有的“节点号”概念很多人一开始不知道导致通信不上。4.1 FINS/UDP与FINS/TCP的差异FINS协议可以承载在UDP上也可以承载在TCP上端口都是9600。FINS/UDP无连接用起来简单上位机发送请求帧后等待响应帧。但UDP没有握手如果PLC不在线或者IP不通上位机收不到任何响应排查问题时就容易拿不准到底是“帧发错了”还是“网络不通”。FINS/TCP需要先建立TCP连接然后才能收发FINS帧。好处是连接状态明确断了能立刻知道适合上位机长时间运行的情况。欧姆龙以太网单元最多支持8个TCP连接不同型号不一样。我在项目里更多使用UDP因为UDP帧结构简单而且可以用Wireshark直接抓包分析。UDP模式下上位机只需要知道PLC的IP和端口9600以及FINS节点号这个下面细说。4.2 IP地址和FINS节点号的隐藏关联FINS协议有一个特殊设计FINS Header里有几个字段——DNA目标网络号通常为0、DA1目标节点号、DA2目标单元号通常为0、SNA源网络号、SA1源节点号、SA2源单元号。其中DA1和SA1就是节点号。欧姆龙以太网单元的节点号设置默认情况下就是IP地址的最后一个字节。比如PLC的IP是192.168.1.10那它的节点号就是10。这个“IP末段即节点号”的约定让很多人吃了亏——如果IP地址是192.168.1.20你手动设了节点号为10FINS通信请求里的DA1发的是10PLC会直接丢弃因为FINS层不认识你。这个问题在CX-Programmer里尤其突出连接PLC时IP地址填对了节点号填错了软件会一直提示“无法连接到PLC”。我最初就是在这卡了很久后来把“节点号IP末段”这个规则记住后再也没犯过。Sysmac Studio里连接NJ/NX系列时也是类似逻辑在“连接目标”里设置IP地址后FINS节点号自动同步为IP末段一般不需要手动改。4.3 用Wireshark抓包定位FINS通信故障FINS/UDP抓包非常方便。在Wireshark里选择网卡过滤条件输入udp.port 9600就能看到所有FINS报文。我一般按这个顺序排查上位机发送的帧是否到达了PLC所在的网络。如果抓不到上位机的发送帧说明上位机程序本身就有问题。抓到了请求帧但没抓到响应帧说明PLC没收到或收到了但没处理。此时检查FINS Header里的DA1目标节点号是否和PLC的节点号一致。抓到了响应帧但上位机程序认为超时说明上位机解析响应帧的逻辑有bug比如端口绑定错误或Socket接收逻辑问题。我分享一个实际案例现场一台欧姆龙CJ2M上位机可以Ping通但FINS请求发出去总是超时。我用Wireshark抓包发现请求帧的DA1字段填的是0而PLC节点号是10于是响应帧发到了节点0上位机当然收不到。乍一看请求帧的格式都正确唯一的问题就是DA1字节。如果把FINS帧当成一个普通数据包来看这个错误根本发现不了。5. CX-Programmer/Sysmac Studio连接参数与工具链避坑很多通信问题不是出在PLC侧而是出在编程软件连接这一环。尤其是更换了电脑、换了USB驱动或网卡之后软件连不上PLC的情况特别常见。5.1 CX-Programmer连接CP系列时的关键设置用CX-Programmer通过以太网连接CP1H时要在“PLC型号”里选择正确型号然后在“Network Type”里选Ethernet。关键是下面的“Driver”和“FINS Node Address”设置Network TypeEthernetFINS Node Address填上位机电脑的节点号默认1即可IP Address填电脑的IP地址一定要和PLC在同一网段Port Number默认9600一般不需要改我遇到过一个很典型的故障电脑IP是192.168.1.50PLC是192.168.1.10子网掩码都是255.255.255.0但CX-Programmer连接时一直提示“节点号不对”。后来发现问题出在电脑上装了VMware虚拟网卡CX-Programmer自动选择了虚拟网卡作为通信通道导致发送的FINS帧根本到不了PLC所在的物理网卡。解决方法是在Windows网络设置里把VMware网卡禁用或者在CX-Programmer里指定物理网卡的IP地址。5.2 Sysmac Studio连接NJ/NX时的节点号与版本兼容Sysmac Studio连接NJ/NX系列相对简单新建工程后点击“连接目标”输入PLC的IP地址一般就能找到。但这里有几个版本兼容的坑Sysmac Studio版本太旧无法识别新版本固件的NJ/NX控制器。只能升级软件或在PLC设置里调整。我遇到过一次远程给客户做技术支持对方的Sysmac Studio版本是1.20PLC是NX1P2死活连不上后来让对方升级到1.30以上就好了。PLC固件和软件版本不匹配时在线时会提示“控制器版本不兼容”此时不要强行在线容易导致设定参数异常。同一台电脑连接多个PLC时要注意Sysmac Studio的“连接目标”列表里保存的是上一次的PLC信息如果局域网内有多个PLC且IP都是默认的容易连错。5.3 连接不上时的分层排查路线不管是CX-Programmer还是Sysmac Studio连不上PLC我总结了一套固定排查路线分享出来第一步物理层。网线是否插好PLC前面板的Link灯是否亮。如果Link灯不亮先换网线或换PLC网口。第二步网络层。在电脑上pingPLC的IP地址。能ping通说明二层三层没问题ping不通检查电脑IP是否和PLC在同一网段以及PLC的IP是不是设成了自动获取但没获取到地址。第三步FINS配置层。这是欧姆龙特有的。检查节点号是否等于IP末段检查上位机软件的节点号设置是否和电脑IP末段一致检查端口号是否为9600。第四步上位机软件配置层。检查选择的PLC型号、网络类型、驱动是否正确是否有防火墙拦截UDP 9600端口Windows防火墙经常拦截但一般会弹窗询问所以要在拦截弹窗弹出时选择允许。这套路线我在现场用了很多次绝大多数连接问题都能在这四步里定位。6. 最后搞明白的事通信的本质是三层对齐做了这么多项目后我最大的体会是欧姆龙PLC的通信其实不复杂只要抓住一个核心思想——三层对齐。所谓的“三层对齐”是指第一层物理层对齐。485的A/B极性、以太网的IP和网线这些都对了信号才能通。第二层协议参数层对齐。串口波特率、校验位、停止位以太网的端口号、FINS节点号这些要一一对应。任何一项不对通信就会失败或者时好时坏。第三层应用层地址对齐。FINS的DM地址、Modbus的协议地址和PLC实际内存地址之间的映射关系必须符合目标型号的手册规定。我见过很多人排查通信故障从头到尾只盯着协议帧格式看结果查了半天发现是485的A/B线接反了。反过来也有只查接线查了半天发现是Modbus从站地址配错了。所以后来我做任何通信项目都会先做一个最小化的通信测试把线接好、参数配好、读一个固定数据区确认通了之后再开始写业务逻辑。6.1 我的固定测试套路新建一个PLC程序在DM区写上一串递增数据D0 1 D1 2 D2 3 ... D9 10然后在上位机里用串口调试助手或Modbus Poll去读。读到的数据和预期一致说明链路通了后面直接开始业务开发读不到或读错按上面三层顺序去查。这套方法听起来简单但每次都能快速定位问题省出来的调试时间远超过写那十个数据的时间。还有一个小技巧是我踩过很多次坑后总结出来的上位机调试阶段尽量先用UDP而不是TCP。UDP无状态超时就是超时不会出现“连接建立了但假死”的情况。程序稳定之后再根据需求决定是否切换到TCP。6.2 常见故障速查表现象大概率原因排查动作串口通信完全无响应485 A/B接反、参数不一致换线极性核对波特率/校验位/停止位串口通信时好时坏缺终端电阻、干扰大、线缆过长加终端电阻缩短线缆检查屏蔽层接地Host Link能发不能收FCS校验错误或单元号不匹配核对FCS计算方式核对单元号Modbus-RTU数据偏移地址映射表没查用固定递增数据验证地址映射以太网Ping通但FINS通信不通FINS节点号与IP末段不一致检查DA1和SA1字段CX-Programmer连不上防火墙拦截、虚拟网卡干扰、节点号错误按四步排查路线逐层核对6.3 一次性把通信做对的核心习惯如果让我用一句话总结所有经验那就是不要把通信调试当成一次性的“碰运气”而要把每一层都当成可验证的、独立的对象。每次改动只改一个参数改动后立刻验证。比如先确认PLC侧配置正确再确认上位机能ping通再确认FINS节点号无误再确认读到的数据正确。一次改动多个参数一旦出问题你根本不知道是谁导致的。我后来做欧姆龙PLC项目第一步永远是先把通信链路调通、数据读出来然后才开始写梯形图逻辑。这个习惯让我少熬了很多个夜。通信通了后面的一切都好办通信不通写得再漂亮的程序也只是一个在PLC里运行的孤独程序而已。希望这篇关于欧姆龙PLC通信协议的梳理能帮你避开我踩过的坑。如果你正在做类似项目建议先把地址映射表和节点号规则打印出来贴在工位上相信我你迟早用得上。