先说个我上个月遇到的事。朋友车间里30多台设备西门子S7-1200、三菱FX5U、欧姆龙CP1H、汇川H3U混着用老板要求把产量、报警、能耗全部汇总到一块大屏上。他上网搜了一圈看到组态软件、OPC UA、数据网关、自研采集这些词直接懵了问我到底该选哪个。我反问他三个问题数据采来做什么点位有多少要不要跨品牌他答不上来。这就是大多数做PLC采集项目的人卡壳的地方——方案满天飞但没人先帮你把需求捋清楚。这篇文章我把目前主流的PLC数据采集路线从头到尾横评一遍从硬件链路到软件方案从协议细节到选型逻辑都按我实际用过的真实体验来说。对正在做设备数据化改造、MES对接、远程运维的工程师和项目负责人应该能直接拿来当参考。1. 先回答三个问题采什么、多快、给谁用1.1 数据属性和刷新周期决定方案下限很多人选采集方案上来就问哪个协议快。其实第一个该问的是你采集的这些数据到底要给谁用多久刷新一次才算合格。我一般把采集需求分成三类。第一类是实时监控类。设备状态、当前报警、运行频率、主轴负载这些需要在几十到几百毫秒内刷出来。操作员盯着屏幕就该看到设备电机的启停、变频器的当前频率、报警有没有触发。这类需求对采集周期要求最高100毫秒到1秒是常见区间。搞过组态的人都知道WinCC里变量刷新时间设成100ms和1s画面流畅感完全不同但对PLC通信负载的影响也完全不同。第二类是报表统计类。产量计数、运行时长、能耗累计、班次合格率这类数据基本都是秒级、分钟级甚至小时级去取。设备一天干了几件活、用了多少度电延迟30秒知道和即时知道没有任何区别。这类型需求最容易做随便用个轮询式的数据采集就能满足没必要上多高端的方案。第三类是工艺追溯和关联分析类。比如注塑机的温度、压力、速度曲线需要同一时刻把十几个变量快照下来保存之后要能回放某个时间段的完整曲线。这类需求难的不是采集速度而是同步性——如果你用一个变量一个变量去读的方式读压力时温度已经变了拍出来的曲线是歪的。所以做这类项目得选支持批量读取、一次事务取多点的方案。搞清楚数据怎么用之后方案的筛选范围就小掉一大半。1.2 点位规模、品牌混用程度决定架构思路第二个要清楚的是规模。这里说的规模包括两块总点位数量以及设备品牌的分散程度。我遇到过很多以为点位不多的项目。客户说我就20台设备每台读30个点600个点而已。结果上系统的时候发现20台设备里西门子、三菱、欧姆龙各占三分之一还有两台是倍福每家的通讯协议都不一样。这时候你再想靠一套组态软件硬撑光是驱动配置和变量表整理就能把人磨疯。点位规模大概可以分三个档次。单台或少量同品牌设备几十个点以内。这种最简单的做法是触摸屏或者小型组态软件搞定显示和记录就够了不需要独立的采集服务。中等规模几十台设备几百到两三千个点位。这个区间弹性最大。品牌如果统一可以用一个组态软件或者OPC UA服务器串联所有PLC品牌如果很杂我的建议是上一台工业协议网关或者部署一个OPC UA服务器把各品牌的异构协议统一成一套接口往上走。大规模上百套设备、上万个点。这个规模基本不会用传统组态软件硬扛了基本都是边缘网关加工业物联网平台或者消息中间件加时序数据库的玩法。采集层要做成分布式的不再是单机程序去轮询所有PLC而是每个车间、每个区域各跑一个采集网关。品牌混用程度直接影响架构。只用一个品牌组态软件的驱动效率最高多品牌混用OPC UA和网关几乎是绕不开的路径。汇川、三菱、西门子、欧姆龙各自的通讯协议差别很大想靠一套驱动打天下不现实。至于像PLC和川崎机器人走总线通讯这类场景本质上已经不是单纯的采集问题而是设备互联。机器人控制柜一般有总线接口多数情况下你会通过现场总线比如PROFINET或EtherCAT把机器人的状态字和控制字映射到PLC里再从PLC那边一并采集。这也是为什么项目规划要把总线和采集一起考虑否则后期加设备互联会很痛苦。2. 硬件链路是地基串口、以太网、总线的边界在哪里2.1 RS-485串口采集老设备的主力但别迷信波特率串口采集在很多老旧产线改造里仍然是主力。西门子S7-200、三菱FX系列老款、欧姆龙CP1H串口版、很多变频器和仪表都靠RS-485往外吐数据。它的优点很多成本低、抗干扰能力比想象的好、离得远理论1200米、线缆要求也不高一对屏蔽双绞线就能干活。但RS-485有个最大的脾气半双工、主从轮询。也就是说一个通信链路上只能有一个主站发指令从站收到指令才回数据。你要是一条485总线挂了10台PLC采集周期就是10台设备的响应时间之和。举个实际例子。现场用Modbus RTU 9600波特率、8个数据位、1个停止位一条指令加响应的典型时间是10到15毫秒。如果每台设备一次轮询要读10个寄存器那每台就要发10条指令一条链路轮一圈下来就是10台×10条×12毫秒大概1.2秒。这时候你别说实时监控连1秒一刷都勉强。要想快一点可以把波特率提到38400甚至115200但波特率越高对线缆质量、接地和终端电阻越敏感距离也会缩短。很多现场在9600波特率下跑得很稳一提到115200就偶尔丢包最后只能降回来。所以做串口采集第一个要算的是轮询周期的账。寄存器读取得越少、波特率越高、链路节点越少周期越短。能合并读取的寄存器尽量合并比如用功能码03一次读连续地址段的10个寄存器比单独读10次省太多时间。还有个细节很多PLC的串口同时支持编程口和自由口通讯接采集时最好在PLC程序里专门做一个只读服务或者约束通信占用的寄存器区避免上位机写入指令和编程软件在线监控打架。我就碰到过工人在用GX Works2监控程序的时候上位机的Modbus写入正好撞上把PLC参数改了的事故后来全线规定采集通道只读要写参数走人机界面。2.2 以太网采集规划好网段、地址和访问权限现在主流PLC基本都自带以太网口S7-1200/1500、三菱FX5U/Q系列、欧姆龙NJ/NX系列、汇川H5U等等插上网线就能当采集通道。以太网的最大优势是速度快、可以多主站同时访问——一台PLC的数据可以同时被HMI、组态软件、MES系统各取所需互不干扰。而串口那条单车道一个主站占着别人就上不了。不过以太网采集有一堆看似不起眼、实际很坑的细节。各品牌协议和端口先要心里有数。我列一个常用的表格PLC品牌/型号常用采集协议默认端口备注西门子S7-1200/1500S7commS7协议102/TCP需在PLC侧开启PUT/GET访问权限西门子S7-1500较新固件OPC UA Server4840/TCP部分机型固件内置三菱FX5U/Q系列MC协议3E帧/4E帧3001/5001等需要正确拼装ASCII/二进制帧三菱FX系列老款Modbus RTU串口无需要FX3U-485ADP-MB等扩展欧姆龙CP1H/NJ/NXFINS协议9600/TCP也有HostLink串口方案汇川H3U/H5UModbus TCP502/TCP小型机以太网支持比较好倍福TwinCATADS协议48898也自带OPC UA Server这里最典型的坑是西门子S7-1200/1500。新固件的PLC默认不允许第三方程序通过S7协议访问必须在PLC程序属性里把允许来自远程对象的PUT/GET通信访问勾上或者通过DB块属性放开访问。我第一次用Snap7连客户的S7-1500IP通、网线好、防火墙关了就是连不上最后发现是访问权限没开。有些厂家的PLC程序加了访问密码保护第三方读取还需要登录凭据这让自研采集的工程量又加了一条。与此相关的是S7协议本身是基于102端口的明文传输没有加密。在工控内网用问题不大但如果PLC要跨网段或者暴露给外部系统就要考虑用OPC UA的证书加密或者通过边缘网关做安全隔离不要直接把102端口映射到外网。网段规划也要重视。很多工厂办公网和工控网混在一起采集设备最好和PLC在同一个二层网络或者通过可管理交换机做VLAN划分。如果必须在跨网段的三层网络上采集要确保路由可达还要注意工业防火墙放行对应端口。很多远程项目连不上PLC查到最后都是路由表或者防火墙策略的问题。2.3 用VMware跑仿真连接PLC的网络模式怎么选搜热词里经常看到TIA用VMware连PLC用什么网络连接模式这个确实困扰不少人。尤其现在很多工程师喜欢在虚拟机里装TIA Portal做仿真但虚拟机连不上PLCSIM或者真实的PLC。我的经验是如果虚拟机里的TIA要连接真实的PLC网卡用桥接模式最省心让虚拟机直接拿到和PLC同一个物理网段的IP相当于它就是一台独立的电脑。NAT模式在多数情况下连不上PLC因为NAT是站在宿主机背后的地址转换PLC发回来的数据包到不了虚拟机里那层逻辑网络。Host-Only模式就更不用试了那只是宿主机和虚拟机之间的私有网段和外部PLC不在一个世界。如果只是用PLCSIM做纯软件仿真不连真实硬件那就不需要纠结物理网卡了。TIA里PLCSIM自带虚拟以太网适配器仿真PLC的IP是它自己模拟出来的HMI仿真软件能直接发现它不需要VMware去桥接什么。很多人在这一步钻牛角尖折腾半天网卡其实用不着。还有个小细节VMware虚拟机里跑TIA最好给虚拟机分配双核以上的CPU和至少8GB内存否则编译和仿真都会让你等得怀疑人生。我就是因为虚拟机配置太低编译一个中型项目要五分钟后来干脆把整个虚拟机搬到一台16GB内存的电脑上。2.4 接线电气细节NPN和PNP选型采集不到信号的元凶硬件链路里最容易翻车、又一而再再而三被问的问题就是NPN和PNP。搜热词里plc输出晶体管区分npn和pnp和plc数字量输出点控制变频器开关量都是这一类问题。先说输入侧。采集设备信号时你面对的是接近开关、光电开关、按钮这类输入信号。NPN型输出的传感器导通时把信号线拉到0V属于低电平有效要让PLC的输入公共端接正极PNP型刚好相反导通时输出高电平公共端接负极。如果PLC的输入模块是源型输入你接了NPN传感器那么信号触发时输入点根本检测不到电平变化采集就全是0。项目里最典型的现象是传感器指示灯明明亮了点表里的DI状态却是0十有八九就是NPN/PNP和PLC输入端匹配搞反了。再讲输出侧。PLC数字量输出控制变频器的启停、方向端子也要看PLC输出晶体管是源型还是漏型变频器那边的DI公共端是正还是负。三菱FX系列晶体管输出一般是漏型输出输出点导通时电流从公共端流入、从输出点流出到0V所以接变频器时要注意变频器DI的公共端接法。接反了的表现就是程序里已经置1但变频器怎么都不启动。此外还有个容易忽略的点输入滤波。PLC的DI口一般都有输入滤波时间默认值可能是几毫秒到十几毫秒如果采集高速脉冲信号比如编码器、流量计的脉冲滤波时间太长会把脉冲吃掉。我在某项目里用PLC采集流量计脉冲程序写了高速计数器但就是计数不对最后发现DI默认滤波时间10ms改成0.2ms级别的数字滤波后立刻正常。这也是采集方案里很小但很致命的细节。3. 软件层面的三条路线组态、OPC UA、自研协议3.1 组态软件上手快但绑定和授权是硬伤如果你只是一台或者少数几台PLC配一个数据看板组态软件是最快的路线。西门子的WinCC、国产的组态王和力控装好驱动建变量表拖几个控件半天就能出一版画面。西门子全家桶用户用WinCC配合TIA Portal的集成体验确实顺滑变量同步、画面组态一气呵成。但组态软件的坑也很明确。第一是品牌绑定问题。WinCC对西门子的支持最好但对三菱、欧姆龙、汇川这些品牌的支持要么靠第三方驱动要么基本没有你要是混用品牌同一个组态软件里要同时维护好几套驱动每套驱动的变量命名规则还不一样变量表维护成本直线上升。第二是点数授权费用组态软件的授权通常按变量点数收费从几百到几千上万项目越大授权费越心疼。第三是稳定性我见过太多组态软件在工厂里长期运行后出现数据库连接异常、画面假死的问题做演示和短期监控没问题但要做全年无休的可靠采集前置采集服务更适合。我并不否定组态软件它在小规模、单机、有人盯的场合性价比很高。但如果你打算在这上面承载MES和长期数据积累建议把组态软件当呈现层把数据采集放到它背后独立的采集服务上。3.2 OPC UA跨品牌整合的正路跨品牌统一采集OPC UA是绝大多数项目的正解。OPC UA和老的OPC DA/HDA最大的区别是它是一个跨平台、面向服务的架构有内建的安全模型证书、加密、用户认证并且不只是Windows专用Linux、嵌入式设备都可以作为服务器或者客户端存在。现在新出的PLC很多原生支持OPC UA Server比如西门子S7-1500内部就带UA Server你不写一行代码就能把数据以OPC UA方式发布出去。S7-1200从固件4.4版本之后也加入了OPC UA支持部分型号三菱、欧姆龙、倍福也都有相应的UA能力。各品牌老型号设备要统一进OPC UA环境通常需要一台中间网关服务器。最常用的就是Kepware现在归PTC、Prosys OPC UA SDK这类软件把西门子、三菱、欧姆龙各家协议都封装成了统一的OPC UA接口你在上位机里只需要盯着一个UA端点读数据就行不用关心底层是什么品牌。跨网段、跨平台、权限管理都很方便。用OPC UA要注意的是证书配置和性能开销。第一次建立连接时客户端和服务器要互换证书很多工程师在这步被卡死问题通常出在客户端没把服务器证书加入信任列表或者服务器拒绝对未受信任的客户端开放。OPC UA的订阅机制性能好是好但它会对PLC增加通信负载订阅周期不要设得太极端100ms的订阅对普通PLC压力不大但对老PLC或者通信负载已经很重的设备建议放到250ms以上。3.3 原生协议直采性能最稳工程量最大如果你是一个喜欢掌控全局的工程师或者想省掉组态软件和OPC网关的授权费用原生协议直采是第三条路。所谓原生协议就是直接用PLC自己的通信协议去读写数据。西门子的S7协议有老牌的Snap7开源库支持C、C#、Python用起来很方便。三菱FX5U/Q系列用MC协议你可以自己拼TCP报文或者用现成的库。欧姆龙FINS协议网上的示例也不少。只要PLC侧开放权限网络通就能读写。这条路最大的优势是性能。不经过中间层没有协议转换开销采集周期可以很快。我用Python写过一个三菱MC协议采集程序对一台FX5U读取100个寄存器纯扫描周期能做到50ms左右。但这条路最大的成本是工程开发量。你不光要会拼报文还要自己处理断线重连、数据同步、历史存储、告警触发、异常恢复这一整套逻辑。我见过有团队自己写采集程序跑了三个月后内存泄漏、线程爆炸比用现成群件还难受。如果你是非上位机方向的人比如用STM32直接和PLC通信本质也是原生协议单片机里写Modbus主站或者MC协议解析。能不能做能做但不推荐拿来跑大规模数据采集单片机的资源有限断线重传、缓存管理做起来很痛苦。适合你的反而是用一块带以太网和协议转换功能的模块把PLC转成Modbus TCP让MCU通过标准Modbus去读工程量小很多。自研协议的代码示例我简单贴一个Snap7读西门子S7-1200的Python片段方便你感受一下这类方案的门槛import snap7 plc snap7.client.Client() plc.connect(192.168.0.1, 0, 1) # IP, Rack, Slot # 读取DB1中的前10个字节 data plc.db_read(1, 0, 10) print(data)代码确实很简洁但后续的上位机逻辑才是大头异常值校验、采集线程调度、掉线重连、数据按时间戳入库、防止重复采集……这些才是自研方案真正烧时间的地方。3.4 各品牌协议速查表我常被问到哪家PLC用哪种方式采集最方便。整理一个速查表以我实际接触过的品牌和型号为主帮助选型时直接对号入座PLC型号推荐采集方式需要的配置难度西门子S7-1200/1500以太网S7协议Snap7/上位机PLC开启GET/PUT访问DB块开放中西门子S7-1500较新固件OPC UA Server启用PLC端OPC UA服务器并配置证书低三菱FX3U老款串口Modbus RTU加FX3U-485ADP-MB扩展板设站号中三菱FX5U以太网MC协议3E帧自动获取IP或者设固定IP开放端口中三菱Q系列以太网MC协议模块参数里启用MC协议中欧姆龙CP1H老款HostLink或Modbus RTU串口切换PLC通信模式设单元号中欧姆龙NJ/NXFINS/TCP或EtherNet/IP配置IP地址开放FINS端口中汇川H3UModbus RTU串口/扩展设从站地址组态从站寄存器低汇川H5UModbus TCPPLC作为Modbus TCP服务器开放502端口低倍福TwinCATADS协议或OPC UATwinCAT AMS NetId配置中高表格没法写尽所有型号但思路是通的老设备优先串口Modbus新设备优先以太网原协议需要跨品牌统一时优先OPC UA。LabVIEW配合松下PLC做串口通信Unity引擎直接连西门子PLC做三维监控本质上都是在用原协议或者中间层遵循的也是同一套选型逻辑。4. 硬件网关和边缘采集器省心但别盲选4.1 协议网关让老设备说新语言协议网关是我做改造项目时很喜欢用的一类硬件。比如把Modbus RTU的仪表转成PROFINET把三菱FX的串口协议转成Modbus TCP或者把RS-485总线上的一堆串口设备一次性映射成以太网寄存器表一台小盒子就搞定了。它最大的价值是把异构协议统一在上位机端不需要关心的层次。你不需要在PC上装各种品牌驱动只要按照网关的寄存器映射表去读数据就行。网关内部把PLC或仪表的寄存器地址映射成自己的Modbus地址或OPC UA节点上位机看到的就是一张虚拟表。但网关的选型有几个坑要留心。首先是配置工具的兼容性很多老网关的配置软件只支持Windows 7甚至XP新电脑跑不起来还没干活就先折腾驱动环境。其次是网关死机工业现场总有电磁干扰和电源波动廉价网关跑久了容易假死一旦死了不会自动恢复必须断电重启。选网关一定要问清楚有没有硬件看门狗和断线自动重启功能别省这几百块钱。再就是映射表有容量限制别只看见支持Modbus TCP就下单先算一下你要从每台设备读多少个寄存器网关的映射表够不够用。前段时间帮朋友把一台三菱FX3U的老机器接入了上位机数据平台就是加了一个国产串口转以太网网关把FX3U的编程口协议转成Modbus TCP上位机只用读标准地址就能拿到D寄存器的数据省掉了跨品牌驱动的麻烦。对老设备做数字化改造这个思路很实用。4.2 远程场景上的边缘网关数据先落地再上云如果你的PLC分布在好几个厂区或者你压根不可能跑到现场去接线调试那就该看一下边缘数据采集网关。这跟前面的协议网关不一样它一般自带4G/5G或者是Wi-Fi模块还能本地存数据断网时先把数据缓存在本地网络恢复了再自动补传。边缘网关的实际架构可以理解成一台小的Linux工控机上面跑着采集程序对外支持Modbus TCP/RTU、S7协议、MC协议、FINS这些采集协议对上把数据以MQTT、Modbus TCP或者HTTPS上报到云平台。好处是数据不直接穿透到生产网对外只主动发起连接安全隔离性比PLC直连公网好很多。实际用下来我建议重视本地存储容量和离线续传逻辑。现场网络不稳定你4G信号偶尔丢几十秒如果网关没有本地缓存数据就断了有缓存的等信号恢复之后会把这段时间的数据补上来但前提是网关的时间同步要准否则补传数据的时间戳错乱统计会很难看。另一点是网关本身的资源开销有些便宜的边缘网关内存才128MB跑起采集程序和MQTT加密通信之后CPU动不动就满载选型时认准内存256MB以上、支持硬件加密的型号更稳妥。4.3 总线端子模块倍福EL6022这类设备的定位搜热词里倍福plc el6022也经常出现我多说一句。EL6022是倍福EtherCAT系统里的一个串口通信端子模块本质上是把EtherCAT总线扩展出两路RS-232/RS-485接口用来和PLC之外的串口设备通信。一看到采集有人会觉得这就是一个数据采集神器但它和独立协议网关的定位完全不同。EL6022只是在EtherCAT系统里提供了一个串口通道硬件层面帮你解决了接线问题但串口协议本身还需要你在TwinCAT里写程序去处理。你要在PLC逻辑里维护Modbus RTU报文、校验、重试这些事相当于自己实现一个Modbus主站。而如果只是想把一台Modbus RTU设备的数据读到PLC里更省事的做法是买一个现成的Modbus RTU转PROFINET或者转EtherCAT网关把设备挂在总线上PLC通过功能块直接读代码量少很多。EL6022适合的场景是你需要在TwinCAT平台里做比较灵活的串口通信开发比如对接非标协议设备、自定义报文格式而不是做标准Modbus设备采集。选型时看需求别把两者混为一谈。5. 横评的最终结论和选型建议5.1 综合对比表把上述方案放在一张表里对比结论会更直观方案开发成本部署难度采集性能稳定性扩展性适用规模组态软件低低中中差单机/少点数OPC UA服务器中中中高高强多品牌中大规模自研原生协议高中高取决于代码质量强对性能有极致要求的场景协议网关低低中中高中老设备改造边缘网关低中中高中高强远程/多站点5.2 按场景直接抄答案按我实际的项目经验常见的几个组合可以这样选。如果你只有一台PLC想本地看个数据、存段时间和简单报表直接上组态软件WinCC或者国产组态都行学习成本最低。如果你有十几台同品牌PLC要集中到一张大屏上有条件上WinCC且预算允许用WinCC全家桶体验最佳预算紧就用组态王力控这类国产软件或者用OPC UA服务器统一之后配一个免费的图形前端也行。如果多品牌混合、几十台设备、要做长期数据积累和MES对接优先考虑OPC UA服务器方案。中间加一台Kepware或者直接上支持多品牌协议的边缘网关数据统一走OPC UA往上层送。如果设备分散在不同厂区、没有专线、又要统一监控边缘网关加云平台是唯一现实的选择。PLC端加一台边缘采集器通过4G把人家的数据收上来。5.3 几则实测避坑记录最后分享几个我实际踩出来的坑希望对你有用。串口被编程软件抢占。某次做采集上位机每隔几秒读不到数据排查到最后发现是工人在用CX-Programmer在线监控同一台欧姆龙PLC编程软件把串口通信资源占用了。从那以后我都在项目开工会上明确采集通道的通信端口是专线编程调试要拔线或者走另一路。采集频率过高反噬PLC。有次把采集周期从500ms调到100ms结果PLC的扫描周期从5ms涨到25msModbus TCP响应时间也跟着恶化现场设备动作不平顺。把采集周期降回300ms并且开启批读取之后才恢复。记住采集频率和PLC的实时性是矛盾的实时性要求高的设备采集周期不能压得太狠。西门子S7协议权限问题排查链路。客户S7-1500连不上排查顺序是Ping通不通102端口通不通PLC属性里有没有允许PUT/GETDB块有没有开放非优化访问最后是PLC里有没有连接限制。很多人卡在第三步程序里就挺保守的一台全新S7-1200默认都不允许第三方读写。西门子通讯模块8180错误代码。西门子PLC通讯模块报8180错误多半是通信请求执行失败可能是机架号/槽号/连接机制配置不对也可能是远程PLC没有响应先检查连接参数和网络物理链路别急着怀疑模块坏了。项目中遇到过一次最后发现是IP地址里多打了一个0低级错误但排查了半天。DI滤波和信号抖动。采集开关量信号在临界点抖动会造成反复0/1跳变可以在PLC程序里做延时滤波或者在上位机做消抖判定别只看一瞬间的电平。其实PLC数据采集这件事走到最后拼的不是你会用哪个协议、哪款软件而是能不能把需求转化成架构再把架构落成一张张可以执行的设备清单和通信参数。方案本身没有绝对的好坏只有适合和不适合。我自己在这类项目里吃过不少亏也总结出一个习惯动手之前先花半天时间把点表捋清楚把设备品牌型号、通信协议、IP规划、点位明细这些基础信息整理成一张表格后面所有方案的选型都会顺畅很多。
PLC数据采集方案怎么选？组态软件、OPC UA、自研协议横评
先说个我上个月遇到的事。朋友车间里30多台设备西门子S7-1200、三菱FX5U、欧姆龙CP1H、汇川H3U混着用老板要求把产量、报警、能耗全部汇总到一块大屏上。他上网搜了一圈看到组态软件、OPC UA、数据网关、自研采集这些词直接懵了问我到底该选哪个。我反问他三个问题数据采来做什么点位有多少要不要跨品牌他答不上来。这就是大多数做PLC采集项目的人卡壳的地方——方案满天飞但没人先帮你把需求捋清楚。这篇文章我把目前主流的PLC数据采集路线从头到尾横评一遍从硬件链路到软件方案从协议细节到选型逻辑都按我实际用过的真实体验来说。对正在做设备数据化改造、MES对接、远程运维的工程师和项目负责人应该能直接拿来当参考。1. 先回答三个问题采什么、多快、给谁用1.1 数据属性和刷新周期决定方案下限很多人选采集方案上来就问哪个协议快。其实第一个该问的是你采集的这些数据到底要给谁用多久刷新一次才算合格。我一般把采集需求分成三类。第一类是实时监控类。设备状态、当前报警、运行频率、主轴负载这些需要在几十到几百毫秒内刷出来。操作员盯着屏幕就该看到设备电机的启停、变频器的当前频率、报警有没有触发。这类需求对采集周期要求最高100毫秒到1秒是常见区间。搞过组态的人都知道WinCC里变量刷新时间设成100ms和1s画面流畅感完全不同但对PLC通信负载的影响也完全不同。第二类是报表统计类。产量计数、运行时长、能耗累计、班次合格率这类数据基本都是秒级、分钟级甚至小时级去取。设备一天干了几件活、用了多少度电延迟30秒知道和即时知道没有任何区别。这类型需求最容易做随便用个轮询式的数据采集就能满足没必要上多高端的方案。第三类是工艺追溯和关联分析类。比如注塑机的温度、压力、速度曲线需要同一时刻把十几个变量快照下来保存之后要能回放某个时间段的完整曲线。这类需求难的不是采集速度而是同步性——如果你用一个变量一个变量去读的方式读压力时温度已经变了拍出来的曲线是歪的。所以做这类项目得选支持批量读取、一次事务取多点的方案。搞清楚数据怎么用之后方案的筛选范围就小掉一大半。1.2 点位规模、品牌混用程度决定架构思路第二个要清楚的是规模。这里说的规模包括两块总点位数量以及设备品牌的分散程度。我遇到过很多以为点位不多的项目。客户说我就20台设备每台读30个点600个点而已。结果上系统的时候发现20台设备里西门子、三菱、欧姆龙各占三分之一还有两台是倍福每家的通讯协议都不一样。这时候你再想靠一套组态软件硬撑光是驱动配置和变量表整理就能把人磨疯。点位规模大概可以分三个档次。单台或少量同品牌设备几十个点以内。这种最简单的做法是触摸屏或者小型组态软件搞定显示和记录就够了不需要独立的采集服务。中等规模几十台设备几百到两三千个点位。这个区间弹性最大。品牌如果统一可以用一个组态软件或者OPC UA服务器串联所有PLC品牌如果很杂我的建议是上一台工业协议网关或者部署一个OPC UA服务器把各品牌的异构协议统一成一套接口往上走。大规模上百套设备、上万个点。这个规模基本不会用传统组态软件硬扛了基本都是边缘网关加工业物联网平台或者消息中间件加时序数据库的玩法。采集层要做成分布式的不再是单机程序去轮询所有PLC而是每个车间、每个区域各跑一个采集网关。品牌混用程度直接影响架构。只用一个品牌组态软件的驱动效率最高多品牌混用OPC UA和网关几乎是绕不开的路径。汇川、三菱、西门子、欧姆龙各自的通讯协议差别很大想靠一套驱动打天下不现实。至于像PLC和川崎机器人走总线通讯这类场景本质上已经不是单纯的采集问题而是设备互联。机器人控制柜一般有总线接口多数情况下你会通过现场总线比如PROFINET或EtherCAT把机器人的状态字和控制字映射到PLC里再从PLC那边一并采集。这也是为什么项目规划要把总线和采集一起考虑否则后期加设备互联会很痛苦。2. 硬件链路是地基串口、以太网、总线的边界在哪里2.1 RS-485串口采集老设备的主力但别迷信波特率串口采集在很多老旧产线改造里仍然是主力。西门子S7-200、三菱FX系列老款、欧姆龙CP1H串口版、很多变频器和仪表都靠RS-485往外吐数据。它的优点很多成本低、抗干扰能力比想象的好、离得远理论1200米、线缆要求也不高一对屏蔽双绞线就能干活。但RS-485有个最大的脾气半双工、主从轮询。也就是说一个通信链路上只能有一个主站发指令从站收到指令才回数据。你要是一条485总线挂了10台PLC采集周期就是10台设备的响应时间之和。举个实际例子。现场用Modbus RTU 9600波特率、8个数据位、1个停止位一条指令加响应的典型时间是10到15毫秒。如果每台设备一次轮询要读10个寄存器那每台就要发10条指令一条链路轮一圈下来就是10台×10条×12毫秒大概1.2秒。这时候你别说实时监控连1秒一刷都勉强。要想快一点可以把波特率提到38400甚至115200但波特率越高对线缆质量、接地和终端电阻越敏感距离也会缩短。很多现场在9600波特率下跑得很稳一提到115200就偶尔丢包最后只能降回来。所以做串口采集第一个要算的是轮询周期的账。寄存器读取得越少、波特率越高、链路节点越少周期越短。能合并读取的寄存器尽量合并比如用功能码03一次读连续地址段的10个寄存器比单独读10次省太多时间。还有个细节很多PLC的串口同时支持编程口和自由口通讯接采集时最好在PLC程序里专门做一个只读服务或者约束通信占用的寄存器区避免上位机写入指令和编程软件在线监控打架。我就碰到过工人在用GX Works2监控程序的时候上位机的Modbus写入正好撞上把PLC参数改了的事故后来全线规定采集通道只读要写参数走人机界面。2.2 以太网采集规划好网段、地址和访问权限现在主流PLC基本都自带以太网口S7-1200/1500、三菱FX5U/Q系列、欧姆龙NJ/NX系列、汇川H5U等等插上网线就能当采集通道。以太网的最大优势是速度快、可以多主站同时访问——一台PLC的数据可以同时被HMI、组态软件、MES系统各取所需互不干扰。而串口那条单车道一个主站占着别人就上不了。不过以太网采集有一堆看似不起眼、实际很坑的细节。各品牌协议和端口先要心里有数。我列一个常用的表格PLC品牌/型号常用采集协议默认端口备注西门子S7-1200/1500S7commS7协议102/TCP需在PLC侧开启PUT/GET访问权限西门子S7-1500较新固件OPC UA Server4840/TCP部分机型固件内置三菱FX5U/Q系列MC协议3E帧/4E帧3001/5001等需要正确拼装ASCII/二进制帧三菱FX系列老款Modbus RTU串口无需要FX3U-485ADP-MB等扩展欧姆龙CP1H/NJ/NXFINS协议9600/TCP也有HostLink串口方案汇川H3U/H5UModbus TCP502/TCP小型机以太网支持比较好倍福TwinCATADS协议48898也自带OPC UA Server这里最典型的坑是西门子S7-1200/1500。新固件的PLC默认不允许第三方程序通过S7协议访问必须在PLC程序属性里把允许来自远程对象的PUT/GET通信访问勾上或者通过DB块属性放开访问。我第一次用Snap7连客户的S7-1500IP通、网线好、防火墙关了就是连不上最后发现是访问权限没开。有些厂家的PLC程序加了访问密码保护第三方读取还需要登录凭据这让自研采集的工程量又加了一条。与此相关的是S7协议本身是基于102端口的明文传输没有加密。在工控内网用问题不大但如果PLC要跨网段或者暴露给外部系统就要考虑用OPC UA的证书加密或者通过边缘网关做安全隔离不要直接把102端口映射到外网。网段规划也要重视。很多工厂办公网和工控网混在一起采集设备最好和PLC在同一个二层网络或者通过可管理交换机做VLAN划分。如果必须在跨网段的三层网络上采集要确保路由可达还要注意工业防火墙放行对应端口。很多远程项目连不上PLC查到最后都是路由表或者防火墙策略的问题。2.3 用VMware跑仿真连接PLC的网络模式怎么选搜热词里经常看到TIA用VMware连PLC用什么网络连接模式这个确实困扰不少人。尤其现在很多工程师喜欢在虚拟机里装TIA Portal做仿真但虚拟机连不上PLCSIM或者真实的PLC。我的经验是如果虚拟机里的TIA要连接真实的PLC网卡用桥接模式最省心让虚拟机直接拿到和PLC同一个物理网段的IP相当于它就是一台独立的电脑。NAT模式在多数情况下连不上PLC因为NAT是站在宿主机背后的地址转换PLC发回来的数据包到不了虚拟机里那层逻辑网络。Host-Only模式就更不用试了那只是宿主机和虚拟机之间的私有网段和外部PLC不在一个世界。如果只是用PLCSIM做纯软件仿真不连真实硬件那就不需要纠结物理网卡了。TIA里PLCSIM自带虚拟以太网适配器仿真PLC的IP是它自己模拟出来的HMI仿真软件能直接发现它不需要VMware去桥接什么。很多人在这一步钻牛角尖折腾半天网卡其实用不着。还有个小细节VMware虚拟机里跑TIA最好给虚拟机分配双核以上的CPU和至少8GB内存否则编译和仿真都会让你等得怀疑人生。我就是因为虚拟机配置太低编译一个中型项目要五分钟后来干脆把整个虚拟机搬到一台16GB内存的电脑上。2.4 接线电气细节NPN和PNP选型采集不到信号的元凶硬件链路里最容易翻车、又一而再再而三被问的问题就是NPN和PNP。搜热词里plc输出晶体管区分npn和pnp和plc数字量输出点控制变频器开关量都是这一类问题。先说输入侧。采集设备信号时你面对的是接近开关、光电开关、按钮这类输入信号。NPN型输出的传感器导通时把信号线拉到0V属于低电平有效要让PLC的输入公共端接正极PNP型刚好相反导通时输出高电平公共端接负极。如果PLC的输入模块是源型输入你接了NPN传感器那么信号触发时输入点根本检测不到电平变化采集就全是0。项目里最典型的现象是传感器指示灯明明亮了点表里的DI状态却是0十有八九就是NPN/PNP和PLC输入端匹配搞反了。再讲输出侧。PLC数字量输出控制变频器的启停、方向端子也要看PLC输出晶体管是源型还是漏型变频器那边的DI公共端是正还是负。三菱FX系列晶体管输出一般是漏型输出输出点导通时电流从公共端流入、从输出点流出到0V所以接变频器时要注意变频器DI的公共端接法。接反了的表现就是程序里已经置1但变频器怎么都不启动。此外还有个容易忽略的点输入滤波。PLC的DI口一般都有输入滤波时间默认值可能是几毫秒到十几毫秒如果采集高速脉冲信号比如编码器、流量计的脉冲滤波时间太长会把脉冲吃掉。我在某项目里用PLC采集流量计脉冲程序写了高速计数器但就是计数不对最后发现DI默认滤波时间10ms改成0.2ms级别的数字滤波后立刻正常。这也是采集方案里很小但很致命的细节。3. 软件层面的三条路线组态、OPC UA、自研协议3.1 组态软件上手快但绑定和授权是硬伤如果你只是一台或者少数几台PLC配一个数据看板组态软件是最快的路线。西门子的WinCC、国产的组态王和力控装好驱动建变量表拖几个控件半天就能出一版画面。西门子全家桶用户用WinCC配合TIA Portal的集成体验确实顺滑变量同步、画面组态一气呵成。但组态软件的坑也很明确。第一是品牌绑定问题。WinCC对西门子的支持最好但对三菱、欧姆龙、汇川这些品牌的支持要么靠第三方驱动要么基本没有你要是混用品牌同一个组态软件里要同时维护好几套驱动每套驱动的变量命名规则还不一样变量表维护成本直线上升。第二是点数授权费用组态软件的授权通常按变量点数收费从几百到几千上万项目越大授权费越心疼。第三是稳定性我见过太多组态软件在工厂里长期运行后出现数据库连接异常、画面假死的问题做演示和短期监控没问题但要做全年无休的可靠采集前置采集服务更适合。我并不否定组态软件它在小规模、单机、有人盯的场合性价比很高。但如果你打算在这上面承载MES和长期数据积累建议把组态软件当呈现层把数据采集放到它背后独立的采集服务上。3.2 OPC UA跨品牌整合的正路跨品牌统一采集OPC UA是绝大多数项目的正解。OPC UA和老的OPC DA/HDA最大的区别是它是一个跨平台、面向服务的架构有内建的安全模型证书、加密、用户认证并且不只是Windows专用Linux、嵌入式设备都可以作为服务器或者客户端存在。现在新出的PLC很多原生支持OPC UA Server比如西门子S7-1500内部就带UA Server你不写一行代码就能把数据以OPC UA方式发布出去。S7-1200从固件4.4版本之后也加入了OPC UA支持部分型号三菱、欧姆龙、倍福也都有相应的UA能力。各品牌老型号设备要统一进OPC UA环境通常需要一台中间网关服务器。最常用的就是Kepware现在归PTC、Prosys OPC UA SDK这类软件把西门子、三菱、欧姆龙各家协议都封装成了统一的OPC UA接口你在上位机里只需要盯着一个UA端点读数据就行不用关心底层是什么品牌。跨网段、跨平台、权限管理都很方便。用OPC UA要注意的是证书配置和性能开销。第一次建立连接时客户端和服务器要互换证书很多工程师在这步被卡死问题通常出在客户端没把服务器证书加入信任列表或者服务器拒绝对未受信任的客户端开放。OPC UA的订阅机制性能好是好但它会对PLC增加通信负载订阅周期不要设得太极端100ms的订阅对普通PLC压力不大但对老PLC或者通信负载已经很重的设备建议放到250ms以上。3.3 原生协议直采性能最稳工程量最大如果你是一个喜欢掌控全局的工程师或者想省掉组态软件和OPC网关的授权费用原生协议直采是第三条路。所谓原生协议就是直接用PLC自己的通信协议去读写数据。西门子的S7协议有老牌的Snap7开源库支持C、C#、Python用起来很方便。三菱FX5U/Q系列用MC协议你可以自己拼TCP报文或者用现成的库。欧姆龙FINS协议网上的示例也不少。只要PLC侧开放权限网络通就能读写。这条路最大的优势是性能。不经过中间层没有协议转换开销采集周期可以很快。我用Python写过一个三菱MC协议采集程序对一台FX5U读取100个寄存器纯扫描周期能做到50ms左右。但这条路最大的成本是工程开发量。你不光要会拼报文还要自己处理断线重连、数据同步、历史存储、告警触发、异常恢复这一整套逻辑。我见过有团队自己写采集程序跑了三个月后内存泄漏、线程爆炸比用现成群件还难受。如果你是非上位机方向的人比如用STM32直接和PLC通信本质也是原生协议单片机里写Modbus主站或者MC协议解析。能不能做能做但不推荐拿来跑大规模数据采集单片机的资源有限断线重传、缓存管理做起来很痛苦。适合你的反而是用一块带以太网和协议转换功能的模块把PLC转成Modbus TCP让MCU通过标准Modbus去读工程量小很多。自研协议的代码示例我简单贴一个Snap7读西门子S7-1200的Python片段方便你感受一下这类方案的门槛import snap7 plc snap7.client.Client() plc.connect(192.168.0.1, 0, 1) # IP, Rack, Slot # 读取DB1中的前10个字节 data plc.db_read(1, 0, 10) print(data)代码确实很简洁但后续的上位机逻辑才是大头异常值校验、采集线程调度、掉线重连、数据按时间戳入库、防止重复采集……这些才是自研方案真正烧时间的地方。3.4 各品牌协议速查表我常被问到哪家PLC用哪种方式采集最方便。整理一个速查表以我实际接触过的品牌和型号为主帮助选型时直接对号入座PLC型号推荐采集方式需要的配置难度西门子S7-1200/1500以太网S7协议Snap7/上位机PLC开启GET/PUT访问DB块开放中西门子S7-1500较新固件OPC UA Server启用PLC端OPC UA服务器并配置证书低三菱FX3U老款串口Modbus RTU加FX3U-485ADP-MB扩展板设站号中三菱FX5U以太网MC协议3E帧自动获取IP或者设固定IP开放端口中三菱Q系列以太网MC协议模块参数里启用MC协议中欧姆龙CP1H老款HostLink或Modbus RTU串口切换PLC通信模式设单元号中欧姆龙NJ/NXFINS/TCP或EtherNet/IP配置IP地址开放FINS端口中汇川H3UModbus RTU串口/扩展设从站地址组态从站寄存器低汇川H5UModbus TCPPLC作为Modbus TCP服务器开放502端口低倍福TwinCATADS协议或OPC UATwinCAT AMS NetId配置中高表格没法写尽所有型号但思路是通的老设备优先串口Modbus新设备优先以太网原协议需要跨品牌统一时优先OPC UA。LabVIEW配合松下PLC做串口通信Unity引擎直接连西门子PLC做三维监控本质上都是在用原协议或者中间层遵循的也是同一套选型逻辑。4. 硬件网关和边缘采集器省心但别盲选4.1 协议网关让老设备说新语言协议网关是我做改造项目时很喜欢用的一类硬件。比如把Modbus RTU的仪表转成PROFINET把三菱FX的串口协议转成Modbus TCP或者把RS-485总线上的一堆串口设备一次性映射成以太网寄存器表一台小盒子就搞定了。它最大的价值是把异构协议统一在上位机端不需要关心的层次。你不需要在PC上装各种品牌驱动只要按照网关的寄存器映射表去读数据就行。网关内部把PLC或仪表的寄存器地址映射成自己的Modbus地址或OPC UA节点上位机看到的就是一张虚拟表。但网关的选型有几个坑要留心。首先是配置工具的兼容性很多老网关的配置软件只支持Windows 7甚至XP新电脑跑不起来还没干活就先折腾驱动环境。其次是网关死机工业现场总有电磁干扰和电源波动廉价网关跑久了容易假死一旦死了不会自动恢复必须断电重启。选网关一定要问清楚有没有硬件看门狗和断线自动重启功能别省这几百块钱。再就是映射表有容量限制别只看见支持Modbus TCP就下单先算一下你要从每台设备读多少个寄存器网关的映射表够不够用。前段时间帮朋友把一台三菱FX3U的老机器接入了上位机数据平台就是加了一个国产串口转以太网网关把FX3U的编程口协议转成Modbus TCP上位机只用读标准地址就能拿到D寄存器的数据省掉了跨品牌驱动的麻烦。对老设备做数字化改造这个思路很实用。4.2 远程场景上的边缘网关数据先落地再上云如果你的PLC分布在好几个厂区或者你压根不可能跑到现场去接线调试那就该看一下边缘数据采集网关。这跟前面的协议网关不一样它一般自带4G/5G或者是Wi-Fi模块还能本地存数据断网时先把数据缓存在本地网络恢复了再自动补传。边缘网关的实际架构可以理解成一台小的Linux工控机上面跑着采集程序对外支持Modbus TCP/RTU、S7协议、MC协议、FINS这些采集协议对上把数据以MQTT、Modbus TCP或者HTTPS上报到云平台。好处是数据不直接穿透到生产网对外只主动发起连接安全隔离性比PLC直连公网好很多。实际用下来我建议重视本地存储容量和离线续传逻辑。现场网络不稳定你4G信号偶尔丢几十秒如果网关没有本地缓存数据就断了有缓存的等信号恢复之后会把这段时间的数据补上来但前提是网关的时间同步要准否则补传数据的时间戳错乱统计会很难看。另一点是网关本身的资源开销有些便宜的边缘网关内存才128MB跑起采集程序和MQTT加密通信之后CPU动不动就满载选型时认准内存256MB以上、支持硬件加密的型号更稳妥。4.3 总线端子模块倍福EL6022这类设备的定位搜热词里倍福plc el6022也经常出现我多说一句。EL6022是倍福EtherCAT系统里的一个串口通信端子模块本质上是把EtherCAT总线扩展出两路RS-232/RS-485接口用来和PLC之外的串口设备通信。一看到采集有人会觉得这就是一个数据采集神器但它和独立协议网关的定位完全不同。EL6022只是在EtherCAT系统里提供了一个串口通道硬件层面帮你解决了接线问题但串口协议本身还需要你在TwinCAT里写程序去处理。你要在PLC逻辑里维护Modbus RTU报文、校验、重试这些事相当于自己实现一个Modbus主站。而如果只是想把一台Modbus RTU设备的数据读到PLC里更省事的做法是买一个现成的Modbus RTU转PROFINET或者转EtherCAT网关把设备挂在总线上PLC通过功能块直接读代码量少很多。EL6022适合的场景是你需要在TwinCAT平台里做比较灵活的串口通信开发比如对接非标协议设备、自定义报文格式而不是做标准Modbus设备采集。选型时看需求别把两者混为一谈。5. 横评的最终结论和选型建议5.1 综合对比表把上述方案放在一张表里对比结论会更直观方案开发成本部署难度采集性能稳定性扩展性适用规模组态软件低低中中差单机/少点数OPC UA服务器中中中高高强多品牌中大规模自研原生协议高中高取决于代码质量强对性能有极致要求的场景协议网关低低中中高中老设备改造边缘网关低中中高中高强远程/多站点5.2 按场景直接抄答案按我实际的项目经验常见的几个组合可以这样选。如果你只有一台PLC想本地看个数据、存段时间和简单报表直接上组态软件WinCC或者国产组态都行学习成本最低。如果你有十几台同品牌PLC要集中到一张大屏上有条件上WinCC且预算允许用WinCC全家桶体验最佳预算紧就用组态王力控这类国产软件或者用OPC UA服务器统一之后配一个免费的图形前端也行。如果多品牌混合、几十台设备、要做长期数据积累和MES对接优先考虑OPC UA服务器方案。中间加一台Kepware或者直接上支持多品牌协议的边缘网关数据统一走OPC UA往上层送。如果设备分散在不同厂区、没有专线、又要统一监控边缘网关加云平台是唯一现实的选择。PLC端加一台边缘采集器通过4G把人家的数据收上来。5.3 几则实测避坑记录最后分享几个我实际踩出来的坑希望对你有用。串口被编程软件抢占。某次做采集上位机每隔几秒读不到数据排查到最后发现是工人在用CX-Programmer在线监控同一台欧姆龙PLC编程软件把串口通信资源占用了。从那以后我都在项目开工会上明确采集通道的通信端口是专线编程调试要拔线或者走另一路。采集频率过高反噬PLC。有次把采集周期从500ms调到100ms结果PLC的扫描周期从5ms涨到25msModbus TCP响应时间也跟着恶化现场设备动作不平顺。把采集周期降回300ms并且开启批读取之后才恢复。记住采集频率和PLC的实时性是矛盾的实时性要求高的设备采集周期不能压得太狠。西门子S7协议权限问题排查链路。客户S7-1500连不上排查顺序是Ping通不通102端口通不通PLC属性里有没有允许PUT/GETDB块有没有开放非优化访问最后是PLC里有没有连接限制。很多人卡在第三步程序里就挺保守的一台全新S7-1200默认都不允许第三方读写。西门子通讯模块8180错误代码。西门子PLC通讯模块报8180错误多半是通信请求执行失败可能是机架号/槽号/连接机制配置不对也可能是远程PLC没有响应先检查连接参数和网络物理链路别急着怀疑模块坏了。项目中遇到过一次最后发现是IP地址里多打了一个0低级错误但排查了半天。DI滤波和信号抖动。采集开关量信号在临界点抖动会造成反复0/1跳变可以在PLC程序里做延时滤波或者在上位机做消抖判定别只看一瞬间的电平。其实PLC数据采集这件事走到最后拼的不是你会用哪个协议、哪款软件而是能不能把需求转化成架构再把架构落成一张张可以执行的设备清单和通信参数。方案本身没有绝对的好坏只有适合和不适合。我自己在这类项目里吃过不少亏也总结出一个习惯动手之前先花半天时间把点表捋清楚把设备品牌型号、通信协议、IP规划、点位明细这些基础信息整理成一张表格后面所有方案的选型都会顺畅很多。
