1. 为什么要在VM虚拟机上做欧姆龙PLC通讯1.1 搞清VM在通讯中的真实角色先说个我经常遇到的场景现场用了博途或者CX-Programmer这些老牌PLC软件但电脑系统太新软件装不上或者公司信息安全规定必须用虚拟机隔离环境再或者是调试团队人手不够需要在一台电脑上同时开好几个版本的编程软件。这时候VMware Workstation这类虚拟机就成了刚需。很多朋友一听到VM与欧姆龙PLC通讯就觉得是玄学其实虚拟机在通讯链路里扮演的角色非常简单——它就是一台普通的Windows上位机。PLC不关心对面是物理机还是虚拟机它只认IP地址、端口号和协议格式。所以你的虚拟机只要能正常访问物理网络FINS通讯这事儿就成了一半。但麻烦也恰恰出在这里。虚拟机的网络是虚拟出来的默认的NAT模式、仅主机模式甚至桥接模式没配对都会导致虚拟机里的上位机软件找不到PLC。我在实际项目里见过太多人卡在明明物理机能ping通PLC虚拟机里就是不行这个坎上最后折腾半天发现是VMware的网络适配器绑错了物理网卡。1.2 三种虚拟网络模式怎么取舍VMware Workstation默认提供三种网络模式桥接模式、NAT模式、仅主机模式。做PLC通讯时选型逻辑很简单记住一个结论能用桥接就用桥接别碰NAT仅主机模式直接放弃。网络模式虚拟机IP与物理网络关系PLC能否访问虚拟机是否推荐桥接模式与物理机在同一局域网类似另一台独立电脑能PLC可直接通讯强烈推荐NAT模式虚拟机在私有网段通过宿主机转发不能直接访问需端口映射不推荐仅主机模式虚拟机与宿主机组成隔离网络PLC无法访问不推荐为什么NAT模式不推荐因为NAT模式下虚拟机的流量要经过宿主机做地址转换等于在PLC和上位机之间插了一道翻译官。欧姆龙的FINS协议走UDP时是无连接的NAT的超时机制、地址映射刷新都可能让通讯断断续续你查半天都找不到原因。桥接模式就直白多了。虚拟机网卡直接桥接到物理网卡上相当于在交换机上多插了一台电脑IP地址设置成和PLC同一网段协议栈走的完全是标准的以太网通讯没有任何中间层干扰。选桥接模式时VMware设置里有个复制物理网络连接状态的选项建议勾上这个选项会让虚拟机在物理网络切换时快速拿到IP省去很多等待时间。还有个常见误区如果电脑有无线网卡和有线网卡VMware桥接时默认可能是自动这时候就必须手动指定桥接到哪个网卡。举个例子PLC接在网线口上但VMware把桥接绑定到了Wi-Fi那虚拟机怎么ping都ping不通PLC。这个坑我踩过不止一次后面排查章节会细说。2. FINS TCP/UDP协议的核心原理2.1 FINS协议到底是什么FINSFactory Interface Network Service是欧姆龙专有的工业以太网协议它跟西门子的S7COMM、三菱的MC Protocol属于同一层级的应用层协议。欧姆龙从早期的C200H系列开始就用这套协议体系一直延续到现在的NJ/NX系列兼容性做得相当好。FINS支持两种以太网传输方式FINS/UDP和FINS/TCP。核心区别就两条UDP方式无连接发完不管速度快但不保证到达。FINS指令直接作为UDP数据报内容发送目的端口默认9600。适合周期性高速读写比如HMI画面刷新、数据采集。TCP方式有连接要建立会话但FINS报文前必须加4字节长度前缀因为TCP是流式协议接收方要知道一帧数据的边界。目的端口同样是9600。适合数据可靠性要求高的场景比如配方下载。端口号都是9600但帧格式不同这是初学者最容易混淆的点。用生活化类比的话UDP是明信片写上收件人就扔邮筒了TCP是挂号信要先约定信封格式还要签收回执。还有一个单位要理解FINS协议里有个节点号Node Number的概念它在报文中用1个字节表示0~254。在以太网环境下FINS节点地址默认跟IP地址最后一段绑定比如192.168.1.10这个PLCFINS节点号通常是10十六进制0A。这个映射关系在现场配PLC时就要先确认好后面协议调试全靠它。2.2 FINS报文的10字节命令头FINS报文最核心的是前面的10字节命令头每个字段都有固定含义调协议时抓包看的就是这一段字节位置字段名含义典型值0ICF指令/响应标识0x80表示指令0x00表示响应1RSV保留字段0x002GCT网关允许重复次数0x023DNA目标网络号0x00本地网络4DA1目标节点号PLC的FINS节点号5DA2目标单元号0x00CPU内置以太网口6SNA源网络号0x007SA1源节点号上位机的FINS节点号8SA2源单元号0x009SID服务标识任意值用于匹配请求和响应命令头后面跟命令码和参数区。以最常用的读内存命令为例命令码是0x0101参数区是内存区代码DM区是0x82、起始地址2字节、读取数量2字节。一条完整的FINS/UDP读DM区D100的数据帧长度就是10字节头加7字节参数总共17字节。TCP方式就在这个17字节前面再加4字节长度值表示后面数据的字节数包含命令头即0x00000011。这地方我曾经见过有人把长度算错结果接收方一直解析不到完整帧通讯怎么也建立不起来。2.3 节点号和单元号千万别搞混现场调试时我经常被问到节点号设多少单元号是不是填1这里必须掰扯清楚。节点号Node Number在以太网中FINS协议用它来标识一台设备。默认情况下它跟IP最后一段匹配但可以手动改。比如PLC的IP是192.168.1.10节点号默认是10你把它改成20也没问题只要上位机报文的DA1跟上就行。很多老工程师习惯固定用IP末段做节点号就是为了减少记忆负担。单元号Unit Number这是用来区分PLC里不同通信端口的。CPU上自带以太网口时单元号默认0如果是单独的以太网单元模块比如CJ1W-EIP21单元号要看模块在机架上的位置拨码或者软件设置。通讯报文的DA2字段填的就是这个值。还有一个网络号的概念。单机直连时源和目标网络号都填0不需要改。如果组了多网段路由才需要配置网络号现场90%的场景都用不到知道有这回事就行。3. 实操配置全程详解从PLC到VM再到上位机3.1 PLC侧网络参数设置在做任何线上通讯之前先把PLC的网络参数配好。以欧姆龙CP1H系列为例用USB线连接PLC和电脑打开CX-Programmer新建工程选择对应CPU型号然后走下面几步在工程树里双击设置打开PLC设置界面切换到内置以太网端口选项卡CP1H带以太网口才有。设置IP地址为192.168.1.10子网掩码255.255.255.0默认网关留空即可。设置FINS节点号默认10与IP末段一致可以保持默认。确认UDP/TCP端口为9600不要随意改除非你对通讯链路有绝对把控。把设置传送到PLC断电重启使参数生效。CJ2、NJ/NX系列的设置方式大同小异只是界面入口不一样。NJ系列是在Sysmac Studio里配置但核心参数还是IP、掩码、节点号这三个。这里有个关键操作习惯在电脑端设置好PLC的IP后先不要急着连FINS先测试网络通不通。在VM虚拟机里ping一下192.168.1.10如果通了说明网络层没问题接着排查协议层。3.2 VM侧网络配置要点VMware里配置桥接网络没有你想的那么复杂但有几个关键点必须按顺序做第一步设置虚拟机网络适配器为桥接模式。关机状态下在虚拟机设置里找到网络适配器选择桥接模式勾选复制物理网络连接状态。如果宿主机有多个网卡点配置适配器只勾选PLC实际连接的那块物理网卡。第二步确认虚拟机里Windows的IP地址。开机进入Windows后打开网络适配器设置手动指定静态IP192.168.1.20子网掩码255.255.255.0。不要用DHCP工业现场最好固定IP否则哪天PLC通讯突然断了排查半天发现是虚拟机IP被路由器重新分配了太冤了。第三步检查Windows防火墙。这是虚拟机里最容易被忽视的问题。Windows防火墙默认会拦截外部的UDP/TCP入站连接你要么在防火墙入站规则里放行9600端口要么在调试阶段直接关闭防火墙仅限内网环境。我一般会新建一条入站规则允许TCP和UDP的9600端口这样既安全又省心。物理机上如果装了360、腾讯管家之类的第三方安全软件也要检查有没有拦截虚拟机进程的对外通讯这类问题不好排查因为系统防火墙放了也不行。3.3 CX-Programmer的FINS连接设置虚拟机网络准备好后打开CX-Programmer新建一个和PLC同型号的工程按照下面的方式设置连接菜单栏PLC - 更改PLC或者在线工作之前的设置入口。设备类型选择对应的PLC型号比如CP1H-XA40DR。网络类型选择Ethernet注意这里会弹出驱动选择有FINS/TCP和FINS/UDP两个选项。点击设置填写目标IP地址PLC的IP目标节点号填10源节点号可以随便填比如1单元号填0。点击测试等待连接结果。这里有个细节CX-Programmer的测试按钮实际会发送一条FINS指令去探测PLC如果网络通、协议对几秒钟内会返回成功。如果测试失败不要急着点确定先记录报错信息对照后面排查章节找原因。FINS/TCP和FINS/UDP用哪个单机直连、数据量不大的调试场景两者都行。我习惯用FINS/UDP因为UDP调试起来更简单不涉及连接状态管理如果通讯环境有丢包风险或数据量大用FINS/TCP更稳。3.4 第三方通讯工具和脚本验证除了CX-Programmer自带的通讯功能很多时候我们需要自己写软件或用第三方库和PLC通讯。这里用一个Python脚本做示例演示怎么发FINS/TCP帧读取DM区数据这对理解协议本质非常有帮助。import socket import struct def fins_tcp_read_dm(ip, port9600, dst_node10, src_node1, dm_address0, count1): # 10字节FINS命令头 fins_header bytes([ 0x80, # ICF命令帧 0x00, # RSV 0x02, # GCT 0x00, # DNA dst_node, # DA1 目标节点号 0x00, # DA2 目标单元号 0x00, # SNA src_node, # SA1 源节点号 0x00, # SA2 源单元号 0x01 # SID 服务ID ]) # 读内存命令0x0101DM区代码0x82起始地址2字节读取数量2字节 params bytes([0x01, 0x01, 0x82]) struct.pack(H, dm_address) struct.pack(H, count) fins_frame fins_header params # TCP要在FINS帧前面加4字节长度 frame_len struct.pack(I, len(fins_frame)) tcp_data frame_len fins_frame sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(3) sock.connect((ip, port)) sock.send(tcp_data) # 接收响应前4字节是长度后面是FINS帧 resp_len struct.unpack(I, sock.recv(4))[0] resp b while len(resp) resp_len: chunk sock.recv(resp_len - len(resp)) if not chunk: break resp chunk sock.close() if resp[0] 0x00: # 响应帧ICF为0x00 # 命令码后第一个字是完成码0x0000表示成功 if resp[11:13] b\x00\x00: values struct.unpack( H * count, resp[13:13 count * 2]) return values return None if __name__ __main__: result fins_tcp_read_dm(192.168.1.10, dm_address100, count1) print(D100 value:, result)这个脚本虽然短但把FINS/TCP的关键帧格式全部体现出来了。调协议时遇到响应异常可以打印resp看完成码比如0101表示内存区代码错误、0105表示目标节点不存在、1101表示命令格式错误对照欧姆龙手册就能快速定位。4. 常见问题与排查技巧实录4.1 网络层排查ping不通怎么办VM里ping不同PLC90%是网络层问题按顺序排查第一步确认物理机能不能ping通PLC。如果物理机都ping不通那问题在PLC侧或者网线、交换机跟虚拟机没关系。PLC和工作站之间的网线要用交叉线还是直通线现代交换机和网卡都支持自动翻转用直通线就行但在老设备上要确认。第二步确认虚拟机网络适配器设置。打开VMware的编辑 - 虚拟网络编辑器查看桥接模式绑定了哪块物理网卡。如果绑定的是无线网卡而PLC接在有线网口上必须手动改为有线网卡。第三步确认虚拟机的IP是不是在PLC同一网段。打开Windows的命令行运行ipconfig如果显示的是192.168.1.20/24PLC是192.168.1.10/24那网段一致。如果是169.254.x.x说明自动获取IP失败马上改静态IP。第四步确认虚拟网络驱动正常。热词里提到的vmnet1有感叹号虚拟机没有网络适配器基本都是VMware的网络驱动重新安装或修复了要做的不是去设备管理器折腾而是在VMware里重新安装VMware Tools它自带网络驱动。实在不行用管理员权限运行VMware安装包选择修复会把虚拟网卡驱动重装一遍。4.2 协议层排查通了但连不上ping通了但CX-Programmer报错或者自己发FINS指令得不到正确响应这时候看协议层。报错无法连接目标节点首先检查PLC侧的FINS节点号是否和报文里的DA1一致。很多PLC在修改IP后节点号没有跟着变或者你上位机填的源节点号跟PLC表里的不同。更常见的是PLC的以太网单元号填错了参数里DA2填了1但实际PLC内置端口单元号是0。报错通讯超时看看走的是FINS/TCP还是FINS/UDP。TCP方式需要先建立连接如果PLC侧防火墙或路由器阻塞了TCP握手客户端会一直卡在连接阶段。UDP方式没有连接过程但要注意UDP是无应答的如果PLC没有回复检查一下上位机防火墙是否拦截了PLC发回的UDP包。一个很经典的操作上的坑有人在CX-Programmer里设了PLC的IP但没有传送到PLC内部保存PLC一重启就恢复成出厂IP了。改完IP后务必在CX-Programmer里执行传送到PLC并重启PLC。而且要注意PLC的TCP/IP设置和FINS设置是两套参数可能存在同一个界面里别只改了IP就以为完事了。4.3 VM相关坑位速查表把调试中遇到的高频问题整理成表格方便直接对照现象可能原因解决方案虚拟机没有网络适配器VMware Tools未安装或驱动异常重装VMware Tools或修复VMware安装VMnet1/VMnet8网卡有感叹号虚拟网络驱动冲突在虚拟网络编辑器中重置或重装VMware网络驱动桥接模式ping不通桥接绑定了错误的物理网卡手动指定桥接到PLC所在网卡虚拟机自动获取到169.254.x.xDHCP服务异常直接设静态IP别依赖自动获取ping通但FINS连不上防火墙拦截9600端口入站规则放行TCP/UDP 9600PLC重启后IP恢复设置没有传送到PLC在线下设置传送到PLC并断电重启还有一个小众但很恶心的坑VMware在挂起Suspend后恢复虚拟机的网卡可能会出现假死状态表现为虚拟机里有网卡图标但实际收发数据包全是0。解决方法是关闭虚拟机后再开机或者禁用/启用虚拟网卡别用挂起恢复来做长时间在线调试。个人经验谈从我做欧姆龙项目这么多年的体会来看VM虚拟机通讯调试最大的敌人不是协议本身而是不确定性。FINS协议是公开且稳定的坑往往出在网络拓扑、防火墙、虚拟网卡驱动这些外围因素上。所以我的调试顺序永远是固定的先物理机直连确认PLC没问题再开虚拟机桥接最后才动协议层。每一步都确认清楚了再往下走能省一半的排查时间。最后再分享一个小技巧在VMware里装好欧姆龙软件后建议做一个快照把所有驱动、IP设置、防火墙规则都配好之后拍个快照。以后任何一台电脑需要做PLC调试直接克隆这个虚拟机省去重新配置的半小时。工业调试现场时间就是金钱这种能复用的基础设施越早搭建越划算。
1. 为什么要在VM虚拟机上做欧姆龙PLC通讯1.1 搞清VM在通讯中的真实角色先说个我经常遇到的场景现场用了博途或者CX-Programmer这些老牌PLC软件但电脑系统太新软件装不上或者公司信息安全规定必须用虚拟机隔离环境再或者是调试团队人手不够需要在一台电脑上同时开好几个版本的编程软件。这时候VMware Workstation这类虚拟机就成了刚需。很多朋友一听到VM与欧姆龙PLC通讯就觉得是玄学其实虚拟机在通讯链路里扮演的角色非常简单——它就是一台普通的Windows上位机。PLC不关心对面是物理机还是虚拟机它只认IP地址、端口号和协议格式。所以你的虚拟机只要能正常访问物理网络FINS通讯这事儿就成了一半。但麻烦也恰恰出在这里。虚拟机的网络是虚拟出来的默认的NAT模式、仅主机模式甚至桥接模式没配对都会导致虚拟机里的上位机软件找不到PLC。我在实际项目里见过太多人卡在明明物理机能ping通PLC虚拟机里就是不行这个坎上最后折腾半天发现是VMware的网络适配器绑错了物理网卡。1.2 三种虚拟网络模式怎么取舍VMware Workstation默认提供三种网络模式桥接模式、NAT模式、仅主机模式。做PLC通讯时选型逻辑很简单记住一个结论能用桥接就用桥接别碰NAT仅主机模式直接放弃。网络模式虚拟机IP与物理网络关系PLC能否访问虚拟机是否推荐桥接模式与物理机在同一局域网类似另一台独立电脑能PLC可直接通讯强烈推荐NAT模式虚拟机在私有网段通过宿主机转发不能直接访问需端口映射不推荐仅主机模式虚拟机与宿主机组成隔离网络PLC无法访问不推荐为什么NAT模式不推荐因为NAT模式下虚拟机的流量要经过宿主机做地址转换等于在PLC和上位机之间插了一道翻译官。欧姆龙的FINS协议走UDP时是无连接的NAT的超时机制、地址映射刷新都可能让通讯断断续续你查半天都找不到原因。桥接模式就直白多了。虚拟机网卡直接桥接到物理网卡上相当于在交换机上多插了一台电脑IP地址设置成和PLC同一网段协议栈走的完全是标准的以太网通讯没有任何中间层干扰。选桥接模式时VMware设置里有个复制物理网络连接状态的选项建议勾上这个选项会让虚拟机在物理网络切换时快速拿到IP省去很多等待时间。还有个常见误区如果电脑有无线网卡和有线网卡VMware桥接时默认可能是自动这时候就必须手动指定桥接到哪个网卡。举个例子PLC接在网线口上但VMware把桥接绑定到了Wi-Fi那虚拟机怎么ping都ping不通PLC。这个坑我踩过不止一次后面排查章节会细说。2. FINS TCP/UDP协议的核心原理2.1 FINS协议到底是什么FINSFactory Interface Network Service是欧姆龙专有的工业以太网协议它跟西门子的S7COMM、三菱的MC Protocol属于同一层级的应用层协议。欧姆龙从早期的C200H系列开始就用这套协议体系一直延续到现在的NJ/NX系列兼容性做得相当好。FINS支持两种以太网传输方式FINS/UDP和FINS/TCP。核心区别就两条UDP方式无连接发完不管速度快但不保证到达。FINS指令直接作为UDP数据报内容发送目的端口默认9600。适合周期性高速读写比如HMI画面刷新、数据采集。TCP方式有连接要建立会话但FINS报文前必须加4字节长度前缀因为TCP是流式协议接收方要知道一帧数据的边界。目的端口同样是9600。适合数据可靠性要求高的场景比如配方下载。端口号都是9600但帧格式不同这是初学者最容易混淆的点。用生活化类比的话UDP是明信片写上收件人就扔邮筒了TCP是挂号信要先约定信封格式还要签收回执。还有一个单位要理解FINS协议里有个节点号Node Number的概念它在报文中用1个字节表示0~254。在以太网环境下FINS节点地址默认跟IP地址最后一段绑定比如192.168.1.10这个PLCFINS节点号通常是10十六进制0A。这个映射关系在现场配PLC时就要先确认好后面协议调试全靠它。2.2 FINS报文的10字节命令头FINS报文最核心的是前面的10字节命令头每个字段都有固定含义调协议时抓包看的就是这一段字节位置字段名含义典型值0ICF指令/响应标识0x80表示指令0x00表示响应1RSV保留字段0x002GCT网关允许重复次数0x023DNA目标网络号0x00本地网络4DA1目标节点号PLC的FINS节点号5DA2目标单元号0x00CPU内置以太网口6SNA源网络号0x007SA1源节点号上位机的FINS节点号8SA2源单元号0x009SID服务标识任意值用于匹配请求和响应命令头后面跟命令码和参数区。以最常用的读内存命令为例命令码是0x0101参数区是内存区代码DM区是0x82、起始地址2字节、读取数量2字节。一条完整的FINS/UDP读DM区D100的数据帧长度就是10字节头加7字节参数总共17字节。TCP方式就在这个17字节前面再加4字节长度值表示后面数据的字节数包含命令头即0x00000011。这地方我曾经见过有人把长度算错结果接收方一直解析不到完整帧通讯怎么也建立不起来。2.3 节点号和单元号千万别搞混现场调试时我经常被问到节点号设多少单元号是不是填1这里必须掰扯清楚。节点号Node Number在以太网中FINS协议用它来标识一台设备。默认情况下它跟IP最后一段匹配但可以手动改。比如PLC的IP是192.168.1.10节点号默认是10你把它改成20也没问题只要上位机报文的DA1跟上就行。很多老工程师习惯固定用IP末段做节点号就是为了减少记忆负担。单元号Unit Number这是用来区分PLC里不同通信端口的。CPU上自带以太网口时单元号默认0如果是单独的以太网单元模块比如CJ1W-EIP21单元号要看模块在机架上的位置拨码或者软件设置。通讯报文的DA2字段填的就是这个值。还有一个网络号的概念。单机直连时源和目标网络号都填0不需要改。如果组了多网段路由才需要配置网络号现场90%的场景都用不到知道有这回事就行。3. 实操配置全程详解从PLC到VM再到上位机3.1 PLC侧网络参数设置在做任何线上通讯之前先把PLC的网络参数配好。以欧姆龙CP1H系列为例用USB线连接PLC和电脑打开CX-Programmer新建工程选择对应CPU型号然后走下面几步在工程树里双击设置打开PLC设置界面切换到内置以太网端口选项卡CP1H带以太网口才有。设置IP地址为192.168.1.10子网掩码255.255.255.0默认网关留空即可。设置FINS节点号默认10与IP末段一致可以保持默认。确认UDP/TCP端口为9600不要随意改除非你对通讯链路有绝对把控。把设置传送到PLC断电重启使参数生效。CJ2、NJ/NX系列的设置方式大同小异只是界面入口不一样。NJ系列是在Sysmac Studio里配置但核心参数还是IP、掩码、节点号这三个。这里有个关键操作习惯在电脑端设置好PLC的IP后先不要急着连FINS先测试网络通不通。在VM虚拟机里ping一下192.168.1.10如果通了说明网络层没问题接着排查协议层。3.2 VM侧网络配置要点VMware里配置桥接网络没有你想的那么复杂但有几个关键点必须按顺序做第一步设置虚拟机网络适配器为桥接模式。关机状态下在虚拟机设置里找到网络适配器选择桥接模式勾选复制物理网络连接状态。如果宿主机有多个网卡点配置适配器只勾选PLC实际连接的那块物理网卡。第二步确认虚拟机里Windows的IP地址。开机进入Windows后打开网络适配器设置手动指定静态IP192.168.1.20子网掩码255.255.255.0。不要用DHCP工业现场最好固定IP否则哪天PLC通讯突然断了排查半天发现是虚拟机IP被路由器重新分配了太冤了。第三步检查Windows防火墙。这是虚拟机里最容易被忽视的问题。Windows防火墙默认会拦截外部的UDP/TCP入站连接你要么在防火墙入站规则里放行9600端口要么在调试阶段直接关闭防火墙仅限内网环境。我一般会新建一条入站规则允许TCP和UDP的9600端口这样既安全又省心。物理机上如果装了360、腾讯管家之类的第三方安全软件也要检查有没有拦截虚拟机进程的对外通讯这类问题不好排查因为系统防火墙放了也不行。3.3 CX-Programmer的FINS连接设置虚拟机网络准备好后打开CX-Programmer新建一个和PLC同型号的工程按照下面的方式设置连接菜单栏PLC - 更改PLC或者在线工作之前的设置入口。设备类型选择对应的PLC型号比如CP1H-XA40DR。网络类型选择Ethernet注意这里会弹出驱动选择有FINS/TCP和FINS/UDP两个选项。点击设置填写目标IP地址PLC的IP目标节点号填10源节点号可以随便填比如1单元号填0。点击测试等待连接结果。这里有个细节CX-Programmer的测试按钮实际会发送一条FINS指令去探测PLC如果网络通、协议对几秒钟内会返回成功。如果测试失败不要急着点确定先记录报错信息对照后面排查章节找原因。FINS/TCP和FINS/UDP用哪个单机直连、数据量不大的调试场景两者都行。我习惯用FINS/UDP因为UDP调试起来更简单不涉及连接状态管理如果通讯环境有丢包风险或数据量大用FINS/TCP更稳。3.4 第三方通讯工具和脚本验证除了CX-Programmer自带的通讯功能很多时候我们需要自己写软件或用第三方库和PLC通讯。这里用一个Python脚本做示例演示怎么发FINS/TCP帧读取DM区数据这对理解协议本质非常有帮助。import socket import struct def fins_tcp_read_dm(ip, port9600, dst_node10, src_node1, dm_address0, count1): # 10字节FINS命令头 fins_header bytes([ 0x80, # ICF命令帧 0x00, # RSV 0x02, # GCT 0x00, # DNA dst_node, # DA1 目标节点号 0x00, # DA2 目标单元号 0x00, # SNA src_node, # SA1 源节点号 0x00, # SA2 源单元号 0x01 # SID 服务ID ]) # 读内存命令0x0101DM区代码0x82起始地址2字节读取数量2字节 params bytes([0x01, 0x01, 0x82]) struct.pack(H, dm_address) struct.pack(H, count) fins_frame fins_header params # TCP要在FINS帧前面加4字节长度 frame_len struct.pack(I, len(fins_frame)) tcp_data frame_len fins_frame sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(3) sock.connect((ip, port)) sock.send(tcp_data) # 接收响应前4字节是长度后面是FINS帧 resp_len struct.unpack(I, sock.recv(4))[0] resp b while len(resp) resp_len: chunk sock.recv(resp_len - len(resp)) if not chunk: break resp chunk sock.close() if resp[0] 0x00: # 响应帧ICF为0x00 # 命令码后第一个字是完成码0x0000表示成功 if resp[11:13] b\x00\x00: values struct.unpack( H * count, resp[13:13 count * 2]) return values return None if __name__ __main__: result fins_tcp_read_dm(192.168.1.10, dm_address100, count1) print(D100 value:, result)这个脚本虽然短但把FINS/TCP的关键帧格式全部体现出来了。调协议时遇到响应异常可以打印resp看完成码比如0101表示内存区代码错误、0105表示目标节点不存在、1101表示命令格式错误对照欧姆龙手册就能快速定位。4. 常见问题与排查技巧实录4.1 网络层排查ping不通怎么办VM里ping不同PLC90%是网络层问题按顺序排查第一步确认物理机能不能ping通PLC。如果物理机都ping不通那问题在PLC侧或者网线、交换机跟虚拟机没关系。PLC和工作站之间的网线要用交叉线还是直通线现代交换机和网卡都支持自动翻转用直通线就行但在老设备上要确认。第二步确认虚拟机网络适配器设置。打开VMware的编辑 - 虚拟网络编辑器查看桥接模式绑定了哪块物理网卡。如果绑定的是无线网卡而PLC接在有线网口上必须手动改为有线网卡。第三步确认虚拟机的IP是不是在PLC同一网段。打开Windows的命令行运行ipconfig如果显示的是192.168.1.20/24PLC是192.168.1.10/24那网段一致。如果是169.254.x.x说明自动获取IP失败马上改静态IP。第四步确认虚拟网络驱动正常。热词里提到的vmnet1有感叹号虚拟机没有网络适配器基本都是VMware的网络驱动重新安装或修复了要做的不是去设备管理器折腾而是在VMware里重新安装VMware Tools它自带网络驱动。实在不行用管理员权限运行VMware安装包选择修复会把虚拟网卡驱动重装一遍。4.2 协议层排查通了但连不上ping通了但CX-Programmer报错或者自己发FINS指令得不到正确响应这时候看协议层。报错无法连接目标节点首先检查PLC侧的FINS节点号是否和报文里的DA1一致。很多PLC在修改IP后节点号没有跟着变或者你上位机填的源节点号跟PLC表里的不同。更常见的是PLC的以太网单元号填错了参数里DA2填了1但实际PLC内置端口单元号是0。报错通讯超时看看走的是FINS/TCP还是FINS/UDP。TCP方式需要先建立连接如果PLC侧防火墙或路由器阻塞了TCP握手客户端会一直卡在连接阶段。UDP方式没有连接过程但要注意UDP是无应答的如果PLC没有回复检查一下上位机防火墙是否拦截了PLC发回的UDP包。一个很经典的操作上的坑有人在CX-Programmer里设了PLC的IP但没有传送到PLC内部保存PLC一重启就恢复成出厂IP了。改完IP后务必在CX-Programmer里执行传送到PLC并重启PLC。而且要注意PLC的TCP/IP设置和FINS设置是两套参数可能存在同一个界面里别只改了IP就以为完事了。4.3 VM相关坑位速查表把调试中遇到的高频问题整理成表格方便直接对照现象可能原因解决方案虚拟机没有网络适配器VMware Tools未安装或驱动异常重装VMware Tools或修复VMware安装VMnet1/VMnet8网卡有感叹号虚拟网络驱动冲突在虚拟网络编辑器中重置或重装VMware网络驱动桥接模式ping不通桥接绑定了错误的物理网卡手动指定桥接到PLC所在网卡虚拟机自动获取到169.254.x.xDHCP服务异常直接设静态IP别依赖自动获取ping通但FINS连不上防火墙拦截9600端口入站规则放行TCP/UDP 9600PLC重启后IP恢复设置没有传送到PLC在线下设置传送到PLC并断电重启还有一个小众但很恶心的坑VMware在挂起Suspend后恢复虚拟机的网卡可能会出现假死状态表现为虚拟机里有网卡图标但实际收发数据包全是0。解决方法是关闭虚拟机后再开机或者禁用/启用虚拟网卡别用挂起恢复来做长时间在线调试。个人经验谈从我做欧姆龙项目这么多年的体会来看VM虚拟机通讯调试最大的敌人不是协议本身而是不确定性。FINS协议是公开且稳定的坑往往出在网络拓扑、防火墙、虚拟网卡驱动这些外围因素上。所以我的调试顺序永远是固定的先物理机直连确认PLC没问题再开虚拟机桥接最后才动协议层。每一步都确认清楚了再往下走能省一半的排查时间。最后再分享一个小技巧在VMware里装好欧姆龙软件后建议做一个快照把所有驱动、IP设置、防火墙规则都配好之后拍个快照。以后任何一台电脑需要做PLC调试直接克隆这个虚拟机省去重新配置的半小时。工业调试现场时间就是金钱这种能复用的基础设施越早搭建越划算。
