1. 从一台设备到一块大屏PLC数据实时采集到底在做什么车间里那台老冲床还在用人工抄表每次交接班都要拿本子记电流、记温度、记产量月底统计的时候对不上账老板拍桌子电工背锅。这种场景我见过太多次了。后来上了PLC数据实时采集情况就完全不一样了——设备每运行一个节拍数据自动往平台里灌手机端随时能看报表自动生成连设备突然停机都能第一时间收到推送。这套东西说白了就三件事把PLC里的数据读出来、把数据传出去、把数据存到平台里用起来。听起来简单但真动手做的时候坑一个接一个。不同品牌的PLC协议不一样西门子用S7协议三菱用MC协议汇川有自己的Modbus变种台达又是另一套。网络环境也千奇百怪有的车间连网线都没铺有的地方信号干扰严重数据丢包丢到怀疑人生。平台侧还要考虑数据怎么存、怎么查、怎么展示是上云还是本地部署用MQTT还是HTTP每一步都有讲究。这篇文章适合谁看如果你是自动化工程师想从写梯形图扩展到做数据采集如果你是物联网开发者接到工厂项目不知道从哪下手如果你是设备管理负责人想搞清楚这套系统到底值不值得上——那这篇内容应该能帮你省下不少试错的时间。我会从设备接入、数据传输、平台落地三个环节把整个流程拆开揉碎讲清楚包括协议选型、参数配置、网络调试、平台对接这些实操细节也会分享一些踩过的坑和偷懒的小技巧。2. 设备接入怎么把PLC里的数据掏出来2.1 先搞清楚你的PLC支持什么协议这是最基础也是最关键的一步。很多人上来就问“怎么采集西门子PLC的数据”但西门子有S7-200、S7-200 SMART、S7-1200、S7-1500不同型号支持的协议完全不一样。S7-200 SMART支持S7协议和Modbus TCPS7-1200/1500原生支持S7协议和OPC UA老款的S7-300需要加CP343-1以太网模块才能走网络。我一般会先做一张表把现场所有PLC的型号、通信口类型、支持的协议列清楚PLC品牌常见型号以太网口支持协议采集难度西门子S7-200 SMART有S7、Modbus TCP低西门子S7-1200有S7、OPC UA、Modbus TCP低西门子S7-300需加模块S7、Modbus TCP中三菱FX系列需加模块MC、Modbus TCP中三菱Q系列有MC、Modbus TCP低汇川H5U有Modbus TCP、OPC UA低台达DVP系列需加模块Modbus TCP、Modbus RTU中欧姆龙CJ/CP系列有Fins、Modbus TCP中注意有些PLC的以太网口只支持编程下载不支持同时做数据采集。比如某些老款三菱FX3U加装的以太网模块编程口和通信口是分时复用的采集的时候就不能在线监控程序。这个在方案设计阶段一定要确认清楚否则现场调试的时候会非常被动。2.2 没有网口怎么办串口转以太网方案车间里大量存在的是老设备PLC只有RS232或RS485串口没有以太网口。这种情况有两种处理方式第一种是加串口服务器。比如有人问“inproshop怎么设置plc端口号”其实就是串口服务器配置的问题。串口服务器把RS485转成以太网PLC侧还是走Modbus RTU协议但网络侧变成Modbus TCP。配置的时候要注意串口参数必须和PLC完全一致——波特率、数据位、停止位、校验位一个都不能错。我见过有人把波特率设成9600PLC那边是19200调了一下午死活读不到数据。第二种是换PLC或者加通信模块。如果设备比较新只是低配版没有网口可以加一块以太网模块。比如台达DVP系列可以加DVPEN01-SL模块三菱FX3U可以加FX3U-ENET-ADP。这种方式比串口服务器稳定但成本高一些而且需要改PLC程序。串口服务器的配置有个小技巧先不要接PLC用电脑的串口调试助手直接连串口服务器发Modbus RTU指令看能不能收到回复。确认串口服务器本身没问题了再接PLC。这样可以把问题范围缩小避免同时排查串口服务器和PLC两个环节。2.3 采集频率和点位规划采集频率不是越高越好。我见过一个项目客户要求每100毫秒采集一次结果PLC的通信负载太高程序扫描周期都被拉长了设备动作都变慢了。后来改成500毫秒完全够用。一般来说温度、压力这类模拟量1秒到5秒采集一次足够了产量计数、状态信号这类开关量可以500毫秒到1秒只有做振动分析、高速计数这种场景才需要100毫秒以内的采集周期。点位规划也很重要。不要一股脑把所有寄存器都读上来只读需要的。比如一个西门子S7-1200DB块里有200个变量但实际只需要20个那就只读这20个。读取的点位越多单次通信时间越长出错概率也越大。我通常会把点位分成几组高频组状态、报警1秒采集中频组温度、压力5秒采集低频组电度、累计产量30秒或1分钟采集。这样既能保证关键数据的实时性又不会给PLC和网络太大压力。3. 数据传输从车间到机房的那段路3.1 有线还是无线先看现场条件车间环境决定了传输方式的选择。如果设备集中在一个区域而且有桥架可以走线那有线以太网是最稳的。网线用超五类或六类屏蔽线水晶头做好一点别用那种几毛钱的便宜货车间里电磁干扰大劣质网线丢包率能到百分之几。如果设备分散或者跨车间、跨楼层拉网线成本太高那就考虑无线。工业WiFi是常见选择但要注意几点AP的覆盖范围要够车间里金属设备多信号衰减比办公室严重得多信道要错开2.4G频段只有1、6、11三个不重叠信道AP多了会互相干扰终端要支持漫游AGV小车这种移动设备切换AP的时候不能断线。还有一种是4G/5G路由器适合没有固定网络的场景比如临时施工工地、偏远泵站。但要注意流量费用和信号稳定性有些地下室、金属棚里面信号很差需要加外置天线。实操心得无线方案一定要做现场勘测。我试过在一个钢结构车间里AP装在墙上直线距离不到50米但中间隔了两层钢梁信号强度直接从-40dBm掉到-75dBm丢包严重。后来把AP改到车间顶部用定向天线对着设备区才解决问题。3.2 协议选择Modbus TCP、OPC UA还是MQTT从PLC读到数据之后往平台传的时候用啥协议这取决于平台侧支持什么以及你对实时性和可靠性的要求。Modbus TCP是最简单的很多PLC原生支持平台侧也容易解析。但它有几个问题没有加密安全性差没有发布订阅机制只能轮询数据格式简单复杂结构不好表达。适合小规模、内网环境。OPC UA是工业领域公认的标准西门子、汇川、倍福这些品牌都支持。它有完善的信息模型可以表达复杂的数据结构支持订阅模式数据变化时才上报减少网络流量。但配置相对复杂证书管理、端点配置这些对新手不太友好。MQTT是物联网领域最常用的协议轻量级、支持发布订阅、有QoS等级保证。PLC一般不能直接跑MQTT需要经过网关转换。网关从PLC读数据然后以MQTT协议发到平台。这种方式适合设备数量多、需要上云的场景。我一般会这样选内网小规模用Modbus TCP中大规模用OPC UA需要上云或者跨地域用MQTT。当然如果平台侧已经定了协议那就按平台的要求来。3.3 边缘网关的配置要点边缘网关是连接PLC和平台的中间设备负责协议转换、数据缓存、断线续传。配置网关的时候有几个关键点第一是采集点表的映射。PLC里的地址是类似DB1.DBD0、M100、D100这样的格式平台侧需要的是有意义的变量名比如“1号机主轴温度”。网关里要做地址映射把PLC地址和平台变量名对应起来。这个映射表要维护好设备多了很容易乱。第二是数据缓存策略。网络断了怎么办网关要能把数据先存本地等网络恢复了再补传。缓存大小要算一下假设每秒采集10个点位每个点位20字节断网1小时就是10×20×3600720KB留个10MB缓存空间足够了。第三是心跳和断线重连。网关要定期向平台发心跳平台发现心跳断了就告警。网关侧也要检测网络状态断了之后自动重连重连间隔可以设成5秒、10秒、30秒递增避免频繁重连把网络搞得更堵。{ gateway: { heartbeat_interval: 30, reconnect_interval: [5, 10, 30, 60], cache_size_mb: 50, cache_policy: fifo }, plc_connections: [ { name: line1_s7_1200, protocol: s7, ip: 192.168.1.10, rack: 0, slot: 1, poll_interval_ms: 1000, tags: [ {name: spindle_temp, address: DB1.DBD0, type: float}, {name: spindle_speed, address: DB1.DBD4, type: float}, {name: run_status, address: M100.0, type: bool} ] } ] }上面这个配置示例展示了网关的基本结构。poll_interval_ms是轮询间隔tags里定义了要采集的点位。实际配置的时候不同网关的格式可能不一样但核心要素就是这些。4. 平台落地数据存下来之后怎么用4.1 数据存储选型时序数据库还是关系数据库PLC采集上来的数据是典型的时间序列数据——每个时间点有一组值数据量随着时间线性增长。用MySQL存也不是不行但数据量大了之后查询会很慢。假设100台设备每台50个点位每秒采集一次一天就是100×50×864004.32亿条记录。MySQL单表存这么多数据查询基本就废了。时序数据库是更合适的选择。InfluxDB、TDengine、TimescaleDB这些都可以。它们针对时间序列做了优化写入速度快按时间范围查询效率高还支持数据压缩和自动过期删除。我一般会这样设计存储结构原始数据存时序数据库保留3到6个月聚合数据分钟级、小时级、日级存关系数据库长期保留。这样既能查历史趋势又不会让存储成本失控。存储类型适用数据保留周期典型数据库时序数据库原始采集数据3-6个月InfluxDB、TDengine关系数据库聚合统计、报警记录1-3年MySQL、PostgreSQL对象存储报表文件、备份按需MinIO、S3兼容存储4.2 数据清洗和异常处理PLC采集上来的数据不是直接就能用的。常见的问题有数据跳变传感器干扰导致某个值突然变成0或者满量程、数据重复网络重传导致同一条数据收到两次、数据缺失网络抖动导致某个时间点没采到。数据清洗的规则要根据实际场景来定。比如温度信号正常范围是0到200度如果收到一个-50或者500的值那肯定是异常直接丢弃或者用前一个有效值填充。产量计数是累计值正常情况下只会增加不会减少如果发现比上一个值小那可能是PLC重启了或者计数器溢出了需要特殊处理。注意数据清洗规则不要设得太激进。我见过一个项目把超过量程10%的值都过滤掉了结果设备真的超温报警的时候数据被过滤了平台没收到报警差点出大事。清洗规则要留有余量异常数据可以标记但不要轻易丢弃。4.3 平台侧的数据消费看板、报警、报表数据存下来之后最终是要给人看的。常见的消费方式有三种实时看板是最直观的。用Grafana、ECharts或者平台自带的组态工具把关键指标展示出来。看板设计有个原则一屏之内看到最重要的信息。不要把所有数据都堆上去操作工只关心当前产量、设备状态、有没有报警车间主任关心的是OEE、停机时间、能耗老板关心的是整体产能和趋势。不同角色看不同的看板。报警管理是刚需。温度超限、设备停机、通信中断这些都要能及时通知到人。报警规则要支持分级紧急报警设备故障、安全相关走短信和电话重要报警工艺参数超限走APP推送一般报警通信闪断走平台消息就行。报警还要有确认和关闭机制否则时间长了就没人看了。报表统计是月底最忙的时候。产量报表、能耗报表、故障统计报表这些最好能自动生成。报表模板提前做好数据从时序数据库和关系数据库里取定时任务每天凌晨跑一次生成PDF或者Excel自动发到指定邮箱。5. 常见问题与排查技巧实录5.1 通信不上从物理层开始查PLC数据采集最常见的问题就是通信不上。排查的时候要从底层往上层走第一步查物理层。网线插好了吗指示灯亮不亮串口服务器的TX/RX灯有没有闪这些最基础的东西往往最容易忽略。我遇到过好几次折腾半天发现是网线水晶头没压好。第二步查网络层。电脑能不能ping通PLC的IP如果ping不通检查IP地址是不是在同一网段子网掩码对不对有没有网关冲突。有些PLC默认IP是192.168.0.1和路由器地址冲突了改一下就好。第三步查协议层。用调试工具直接发协议指令看PLC回不回。西门子可以用S7协议调试工具三菱可以用MC协议调试工具。如果工具能读到数据说明PLC侧没问题那就是网关配置的问题。第四步查配置。机架号、槽号对不对S7-1200的机架是0槽是1S7-300的机架是0槽是2这个搞错了肯定读不到。寄存器地址对不对DB块号、起始地址、数据类型一个都不能错。5.2 数据时有时无网络抖动还是PLC负载高数据偶尔丢一两个点过一会儿又恢复了这种问题最烦人。可能的原因有几个网络抖动。无线网络尤其明显信号强度波动导致丢包。可以在网关侧看通信日志如果发现丢包和信号强度变化时间吻合那就是无线的问题。解决办法是加AP、调整天线方向、换信道。PLC扫描周期太长。PLC的程序扫描周期是几十毫秒如果通信请求正好赶上扫描周期切换可能会超时。这种情况可以适当增加通信超时时间比如从1秒改成3秒。网关性能不足。采集点位太多网关CPU跑满了处理不过来。看网关的CPU占用率如果长期超过70%就要考虑减少采集点位或者换性能更好的网关。IP地址冲突。车间里有人乱设IP和PLC的IP撞了导致通信时断时续。这种问题最难查可以在交换机上做端口镜像抓包分析。5.3 平台收不到数据从网关日志入手网关显示采集正常但平台就是没数据。先看网关的发送日志数据有没有发出去如果发出去了平台侧有没有收到平台侧的接收日志怎么说常见的问题有Topic不对。MQTT发布的时候Topic写错了平台订阅的是/plc/line1/data网关发的是/plc/line1/Data大小写不一样平台就收不到。认证失败。平台侧的用户名密码改了网关没更新连接被拒绝。QoS等级不匹配。网关用QoS 0发平台要求QoS 1消息可能丢失。排查的时候可以在平台侧开一个调试Topic订阅所有消息看看到底有没有数据进来。如果没有那就是网关到平台这段路有问题如果有那就是平台内部的处理逻辑有问题。5.4 常见问题速查表现象可能原因排查方法解决办法完全通信不上物理连接断开检查网线、指示灯重新插拔、换网线完全通信不上IP不在同一网段ping测试修改IP地址完全通信不上协议不匹配用调试工具测试确认PLC支持的协议数据时有时无无线信号弱查看信号强度加AP、调天线数据时有时无PLC负载高查看PLC扫描周期降低采集频率数据时有时无IP冲突抓包分析排查冲突设备平台收不到数据Topic错误对比发布订阅Topic修正Topic平台收不到数据认证失败查看网关连接日志更新认证信息数据跳变传感器干扰检查信号线屏蔽加磁环、换屏蔽线数据重复网络重传查看网关日志平台侧做去重6. 几个容易忽略的细节和实操建议6.1 时间同步问题PLC的时间往往不准有的甚至没有实时时钟。采集上来的数据如果带的是PLC时间那时间戳就是乱的。解决办法是在网关侧统一打时间戳用网关的系统时间。网关要配置NTP服务定期和标准时间源同步。这样所有数据的时间戳都是一致的查询和分析的时候不会乱。6.2 数据安全不能忽视车间网络和办公网络要隔离。PLC数据采集走独立的VLAN不要和办公网混在一起。网关到平台如果走公网要用加密通道。平台侧的访问要有权限控制操作工只能看自己车间的数据不能跨车间访问。6.3 先跑通一个点再批量复制不要一上来就搞几十台设备。先选一台PLC把采集、传输、平台展示整个链路跑通。确认没问题了再复制到其他设备。复制的时候注意每台设备的IP、点位地址、变量名都不一样要仔细核对。我见过有人直接复制配置文件结果所有设备的数据都写到同一个变量里了查了一天才发现。6.4 留好调试接口网关和平台都要留调试接口。网关侧留一个本地Web页面能看到实时采集值和通信状态。平台侧留一个调试页面能手动发指令、看原始报文。现场调试的时候这些接口能帮你快速定位问题。6.5 文档和备份配置好的网关配置文件要备份平台侧的组态也要备份。设备多了之后没有文档根本记不住哪台设备对应哪个IP、哪个点位对应哪个变量。我一般会维护一个Excel表格记录设备名称、IP、协议、点位地址、平台变量名每次改动都更新。这个习惯在后期维护的时候能省大量时间。7. 关于成本的一点实在话整套PLC数据采集系统成本主要花在三个地方网关硬件、平台软件、实施人工。网关硬件从几百块到几千块不等取决于采集点数和协议支持。平台软件如果是开源的基本不花钱但需要自己部署和维护商业平台按点位收费一年几千到几万都有。实施人工是大头现场调试、配置、培训一个中等规模的项目20台设备大概需要5到10人天。省钱的办法也有用开源软件Node-RED做数据流、InfluxDB做存储、Grafana做展示用二手网关注意固件版本要支持需要的协议自己写采集程序用Python的pymodbus、python-snap7这些库。但前提是你有技术能力否则省下的钱还不够填坑的。我个人建议如果是第一次做先买一个成熟的网关产品把流程跑通积累经验。等熟悉了之后再考虑用开源方案降低成本。毕竟时间也是钱折腾开源方案花的时间可能比省下的硬件钱更值钱。