开头PLC数据采集这件事但凡在工厂里呆过几年的工程师都知道看着简单做起来全是坑。PLC说白了就是一台专门干活的小电脑它自己跑梯形图、跑ST语言控制设备动得飞快但你想把它肚子里的数据——温度、压力、转速、产量、报警——拿到上位机、MES、数据库里来看来存来统计那就得正经想一套采集方案了。我这几年前前后后经手过西门子、三菱、欧姆龙、汇川、台达、信捷这些主流PLC的采集项目也踩过无数个坑虚拟机连不上PLC、485通讯数据乱跳、Modbus寄存器地址对不上、设备一多网关直接卡死……所以这篇文章不打算写那种“教科书式的方案列表”而是把我实际对比过的几种主流采集路线拿出来横评一遍说清楚每种方案能干什么、不能干什么、钱花在哪、坑埋在哪。如果你正准备做设备数据采集或者正在选型阶段被各种方案介绍搞得头晕这篇文章应该能帮你省下不少试错成本。无论你是刚入门的电气工程师还是带项目的技术负责人下面这些内容都是可以直接拿去用的经验。1. 先理清思路PLC采集方案的选型逻辑在铺开对比之前我觉得有必要先讲讲选型逻辑。很多人一上来就盯着“用哪个协议”“买什么网关”结果项目做到一半才发现连网络架构都没想清楚。做PLC数据采集本质上要回答三个问题数据从哪来、走什么路到哪去、到了之后怎么处理。先说数据从哪来。PLC内部的点位大概分几类数字量输入输出DI/DO、模拟量输入输出AI/AO、内部寄存器D区、M区、V区这些、以及经过运算后生成的中间变量。不同的数据类型采集方式和占用资源完全不一样。比如采集一个数字量输出点可能直接读地址就行但如果要采集变频器的实时电流又涉及变频器参数映射到PLC寄存器的过程这里面的映射关系得提前确认好。再看走什么路。这是选型的核心常见的路线有这几种通过PLC自身通讯口以太网、串口直接让上位机来读在PLC和上层系统之间加一个网关或者边缘计算设备在现场侧部署IO模块或者数采仪绕过PLC直接采集传感器信号最后是到了之后怎么处理。数据到了上位机之后是只做监控展示还是进历史数据库还是要做报警推送和数据分析这决定了你要不要上实时数据库、要不要做二次开发、通讯轮询频率设多少。我的建议是选方案之前先画一张简单的数据流图设备层、控制层、采集层、应用层逐层标清楚。很多项目做完之后发现通讯不稳定、数据对不上回头一查问题就出在某一个环节的选型思路上。先把这层逻辑理顺了后面选什么方案都不容易跑偏。2. 方案一上位机协议直采最灵活但也最容易翻车2.1 什么情况下选它上位机协议直采就是不用额外加硬件设备直接通过以太网或者串口让PC、工控机或者服务器去和PLC通讯。这个方案最大的优点是成本低、灵活度高想采哪些数据在程序里写写地址就行不用改现场接线。很多工厂早期做设备数据采集都是从这条路线起步的。只需要一台工控机、一根网线或者串口线再用C#、LabVIEW、Python这些工具写个通讯程序就能把PLC数据搬到上位机里。但其实这个方案有个隐含前提PLC得支持对应的通讯协议而且你的程序得能处理通讯异常、数据解析这些问题。否则一旦通讯受干扰或者PLC那边程序改动上位机这边就会莫名其妙地丢数据甚至崩掉。2.2 各品牌协议和常见坑点西门子200 Smart支持Modbus TCP和S7协议1200/1500支持S7协议300/400用Simatic Manager下载程序后可以通过S7或Profinet采集。实际项目中西门子S7协议用得最多因为效率比Modbus高一个报文能读多个数据块。三菱FX系列走串口或以太网三菱的MC协议有A兼容1E帧、3E帧等格式新一些的FX5U支持SLMP基本上是以太网直连为主。三菱协议的报文格式偏老但稳定。欧姆龙常见的是FINS协议走UDP/TCP都有地址结构有自己的规则初次上手需要花点时间。汇川、台达、信捷这些国产品牌大多支持Modbus TCP或者Modbus RTU协议透明资料也全反而实现起来容易。这里必须要提醒一句如果你用VMware虚拟机来跑采集程序网络模式一定要选对这个我在后面专门用一节来讲。2.3 直采方案的优劣势优点是硬件投入几乎为零逻辑完全可控代码怎么写完全取决于你自己的需求。缺点是每一台PLC都需要单独处理如果现场设备几百台协议五花八门维护量会非常大。所以我的经验是三五台设备的项目直采没问题超过二十台设备或者设备种类多要慎重。3. 方案二网关采集与边缘计算适合中等以上规模3.1 网关到底在解决什么问题直采方案最大的痛点是每台设备都要写一套通讯逻辑协议不同、地址不同、轮询策略不同。而上层系统往往只需要统一的接口不管是MQTT还是数据库还是HTTP API再把不同PLC的数据转换成标准格式这就是网关存在的意义。现在市面上做工业网关的厂商非常多像海为、巨控、映翰通、有人物联网这些都有对应产品选型的时候核心看几点支持多少种PLC协议、上行接口有哪些、寄存器映射方便不方便、稳定性如何。有一种便宜又实际的方案是用边缘计算网关本质上就是个Linux工业盒子在本地跑Node-RED或者Python脚本用Modbus TCP、S7等通讯库直接去采集PLC然后通过MQTT转发给云端或者本地服务器。这个方案灵活度高成本也低很适合中小规模场景。3.2 网关选型时容易忽略的东西第一是寄存器映射能力。很多网关号称支持某品牌PLC但实际配置起来发现地址映射做得不友好一个一个点位配置特别麻烦。我建议选型前先把网关的配置工具实际操作一遍确认它能不能批量导入点位表。第二是掉线缓存能力。现场网络总有不稳定的时候如果网关没有本地缓存功能数据丢了就丢了事后根本没法补。第三是带载能力。低端网关标称支持几十台设备实际轮询速度一上去就卡死。这个在验收前一定要做满载测试。3.3 什么规模适合上网关我个人感觉二三十台以上设备、且协议种类超过两种就值得考虑上网关方案了。因为这时候你写维护代码的时间成本已经超过网关本身的硬件成本。网关方案把协议差异挡在底层把统一的上行接口交给你后期扩展新设备只是加一个采集配置的事。当然网关也不是万能的遇到高端应用需要高速采集比如伺服轴状态同步、高速计数器数据网关的转发链路往往不满足要求这种还是得走实时总路线。4. 方案三虚拟化现场环境的VMware网络模式选择4.1 为什么专门写这一节不知道有多少工程师跟我一样开发调试的时候喜欢在笔记本上开个虚拟机装Windows Server或者Ubuntu把采集程序放在虚拟机里跑。但虚拟机连PLC经常遇到一个诡异的问题宿主机能ping通PLC虚拟机却怎么都连不上。问题基本都出在虚拟机的网络模式上。VMware常见的有三种模式桥接模式、NAT模式、仅主机模式。很多人默认装好虚拟机用的是NAT虚拟机能上外网但和PLC这种局域网内的工业设备通讯就是不通。4.2 三种模式实测对比桥接模式虚拟机直接占用物理网络的IP就像一台独立的电脑一样PLC可以和它直接通讯。这是连PLC最推荐的模式。NAT模式虚拟机和宿主机共享一个IP出口对外通讯靠地址转换。访问外网没问题但PLC设备的请求根本进不到虚拟机内部做工业通讯非常容易出问题。仅主机模式虚拟机和宿主机可以互通但和外部网络完全隔离只能用来做纯本机测试。我实际测试过西门子1200用S7协议、台达和汇川用Modbus TCP在桥接模式下都能正常通讯。有个细节桥接模式需要把虚拟机的IP地址设置到和PLC同一网段比如PLC是192.168.0.10虚拟机就要配192.168.0.x。如果PLC设置了网关限制只允许特定IP访问那虚拟机还要把MAC地址改成被允许的那台机器的否则一样连不上。4.3 踩坑记录有一次我调试一个现场项目的PLC采集程序宿主机防火墙忘了放行结果虚拟机的程序怎么都连不上PLC。排查了半天发现是Windows防火墙拦了通讯端口后来我把防火墙关了再试立马通了。还有一个经验如果现场网络环境比较复杂有多个VLAN或者跨网段路由桥接模式可能也不够用这时候可以考虑在宿主机上加一个虚拟网卡搞成双网卡桥接让虚拟机走专门的物理网卡连接PLC。这样网络隔离更干净通讯稳定性也好很多。5. 分方案横评对比表为了看得清楚我把自己这几年的实际使用感受整理成了一张对比表覆盖成本、实时性、可靠性、开发量、适用规模这五个维度对比维度上位机协议直采工业网关采集边缘计算网关IO模块旁路采集硬件成本最低中等中等较高实时性高毫秒级中看网关性能中高最高可靠性依赖上位机较高有缓存更好较高高开发量大每个PLC独立写小配置为主中需要写脚本小配置为主适用规模1-10台10-100台10-100台特殊场景典型场景单机数据展示、调试车间级设备监控云平台接入高温高振动环境IO模块旁路采集这个方案可能很多人不熟它是绕开PLC直接在传感器或者电柜里加独立的采集模块把信号直接拿到上层系统。适用的场景是老设备没有通讯口、或者PLC程序加密不允许外部读写、或者现场电磁干扰太大导致总线不稳定。我遇到过一个客户有一台老设备PLC型号停产了程序也加密了没法从PLC取数最后就是用IO模块采集关键信号点位解决的。当然这个方案成本相对高而且采集的是物理信号无法覆盖PLC内部计算得出的数据所以局限性也比较明显。6. 实操从零配置一个Modbus TCP采集示例6.1 硬件准备和接线这个例子我用台达PLC作为Modbus TCP从站用PC上的Python脚本作为主站去读数据是为了演示整个流程方便理解。先确认PLC型号支持Modbus TCP目前主流台达DVP系列和AS系列都支持但需要在PLC程序里启用Modbus TCP服务端功能。三菱FX5U、汇川H3U、信捷XC系列也都是支持的不同品牌配置入口不一样基本思路是一样的启用Modbus功能、分配端口号、规划寄存器地址。网线连接方面PC直接网口连接PLC或者通过交换机连同一个局域网这里注意不要插到路由器的WAN口。6.2 配置PLC从站台达PLC在WPLSoft或ISPSoft里找到通讯设置模块把Modbus TCP服务打开默认端口一般是502确认协议参数从站号、字节序等。这一步有一个关键点字节序。Modbus协议传过来的数据是高位在前还是低位在前不同PLC表现不一样。如果从站用两个字存一个32位浮点数上位机解析时必须按照PLC实际的字节序来否则读出来的数值会变成乱码。我排查过很多次最后都是字节序的问题。6.3 Python读数示例下面这段代码我经常用来做快速验证不用安装很大的库pymodbus就够from pymodbus.client import ModbusTcpClient client ModbusTcpClient(192.168.0.10, port502) if client.connect(): # 读保持寄存器从地址0开始连续读10个寄存器 result client.read_holding_registers(0, 10, slave1) if not result.isError(): print(寄存器值:, result.registers) else: print(读取失败:, result) client.close() else: print(连接失败检查IP和网线)需要注意这里的slave参数是Modbus从站号。有些PLC默认从站号不是1如果读不到数据先查从站号。字节序转换的示例比如读取两个寄存器组合成floatimport struct # 假设高位寄存器是regs[0]低位寄存器是regs[1] data (registers[0] 16) | registers[1] value struct.unpack(f, struct.pack(I, data))[0] print(浮点数:, value)6.4 C#跟西门子S7通讯的示例如果要对西门子1200/1500采集用S7协议效率更高。C#里可以用S7netplus库代码很简单using S7.Net; var plc new Plc(CpuType.S71200, 192.168.0.1, 0, 1); plc.Open(); // 读DB1的起始地址偏移量0长度4字节的浮点数 var value (float)plc.Read(DB1.DBD0); Console.WriteLine($DB1.DBD0 {value}); plc.Close();西门子的地址写法要记一下DB块用DB编号.DBD偏移量表示浮点数DBW表示字DBX表示位。刚开始接触的时候很容易把地址格式弄错。7. 常见问题与排查技巧采集方案上线以后最怕的就是通讯时好时坏、数据跳动、偶尔断线。下面这些是我自己很常遇到的几类问题整理成了一张速查表故障现象可能原因排查思路上位机连不上PLCIP不在同一网段先ping确认物理链路再查IP、子网掩码能ping通但连不上端口防火墙拦截了端口临时关闭防火墙测试或者放行502/102端口数据偶尔跳变寄存器地址重叠或字节序错误用Modbus Poll工具单独测试寄存器地址通讯断断续续网线质量差强电干扰换工业级屏蔽网线检查布线是否和动力电缆分开轮询变慢点位太多但程序是串行轮询改成多线程并发读取或调整轮询周期读到的浮点数和实际不符字节序/字序不对尝试高低位交换比较结果我还遇到过一种情况PLC侧某个程序写坏了通讯区导致上位机发过来的写请求把PLC内部数据搞乱了。这种问题排查起来很隐蔽后面我们的对策是在网关通讯配置里只开放需要读写的寄存器区间不给全地址权限。另一个很值得提的是“AI写代码”这个趋势。现在用AI工具辅助生成PLC通讯代码已经挺成熟了比如用自然语言描述“用Python读三菱FX5U的D100到D110”AI能直接给出可运行的代码框架。但我的建议是AI代码只能当参考上现场之前一定要自己把协议搞清楚尤其是地址类型、通讯超时和异常处理AI生成的代码在这些地方经常有坑。8. 一些该做和不该做的事写了这么多最后分享几条实打实的经验。第一做采集方案前把现场设备的型号、程序版本、通讯协议、IP规划都整理成文档这一步不能省。很多项目后期出问题就是前期资料不完整。第二不要一上来就追求采集全部点位。先选关键设备、关键参数跑通流程后再逐步扩展。这能让你更早发现通讯瓶颈和地址规划问题。第三有条件的话在采集程序里加上数据断线补传功能。最简单的处理是本地缓存最近几小时数据等通讯恢复后再批量上传。第四通讯测试一定要在实际工况下测试而不是调试完就完事。设备运行时和停机时的通讯负载完全不同很多问题都是在高负载下才暴露出来的。第五重视网络安全。现在很多工厂都在往数字化方向走PLC联网越来越多采集网关如果是Linux系统默认密码一定要改掉不用的端口尽量关闭这是底线。我在实际项目中还发现一个细节很多PLC的网口在长时间高并发访问时自身响应也会变慢。上位机端一定要做好超时重试机制不要无限制地等下去否则一个卡死会把整个采集线程拖垮。不管选哪种方案都要记住一点数据采集不是堆硬件也不只是写代码它是设备、网络、软件三者配合的结果。前期多花点时间把方案想清楚后面能省掉很多夜里的故障电话。