做工业数据采集这些年我几乎每周都会被人问到同一个问题PLC里的温度、压力、电流、产量、报警这些数据到底怎样才能稳定地弄出来送到监控大屏、MES系统或者云平台上这个问题背后通常是设备已经装了很多年通信接口五花八门有的走串口有的走以太网有的干脆没有通信口只能靠老办法硬接。所谓25种方法不是让你全部用上而是一张“地图”。先看清楚自己手头的PLC是什么类型、现场网络是什么状态、数据最终要到哪里去再从这张图里选出最合适的几种组合。做这件事能解决什么问题它能把工业现场那些“看得见摸不着”的运行数据变成可以统计、可以追溯、可以指导生产的数字资产。适合三类人看一线设备维护和电气工程师、做MES/SCADA的信息化实施人员以及需要在项目里做技术选型的负责人。1. 先把25种方法放进一张地图1.1 一条主线数据从PLC到上位机链路加协议两件事PLC内部的数据本质是一堆内存地址里的值比如保持寄存器、数据块、输入映像区。数据采集干的事情就是把这些地址里的值“读走”。读走的过程只牵涉两件事物理链路串口、以太网、现场总线、无线决定了信号怎么传。通信协议Modbus、S7、MC、FINS这些决定了设备之间怎么“对话”。很多方案选错不是协议学得不够而是没分清自己缺的是链路还是协议。一台老设备只有RS485口你想走以太网那不是换协议能解决的得加串口服务器或工业网关。反过来PLC明明有以太网口上位机却只支持Modbus那需要做的是协议转换。先分清这条主线后面所有方法都不会乱。1.2 二十五种方法总览表按物理链路和应用层划分我把主流方案分成六类合计二十五种类别方法典型应用场景串口链路5种Modbus RTU轮询、私有串口协议解析、编程口直连、串口服务器中转、多串口卡并发老设备、仪表、变频器、小规模产线以太网链路6种Modbus TCP、S7comm、三菱MC协议、欧姆龙FINS、EtherNet/IP、PROFINET从站中大规模PLC、新建产线、多站点并发现场总线3种PROFIBUS DP、CANopen、DeviceNet/CC-Link老总线产线改造、不断原系统无线链路3种4G DTU、WiFi、LoRa/NB-IoT无布线点位、远程监控、环境监测网关与边缘3种协议转换网关、边缘计算网关、IoT平台网关多品牌混用、断网续传、云平台接入软件与其他5种OPC UA服务、时序数据库直写、板卡级硬接线、文件/FTP导出、OCR读屏同构信息化、极小点位、极端老设备为什么按“链路协议”分而不是按PLC品牌分因为同一种协议可以跨品牌使用。Modbus几乎被所有PLC支持或者通过扩展模块支持。按品牌去学越学越窄按链路和协议去学越用越宽。到后面你会形成条件反射看到一个项目的设备清单脑子里自动弹出对应链路和协议。1.3 选型第一原则不急着选技术先回答三个问题数据量多大几十个点还是几千个点对应轮询和订阅推送两种完全不同的思路。实时性多高秒级还是毫秒级决定是走周期轮询还是走事件上报。现场有没有网车间里有稳定网线就走以太网没布线就考虑无线或加网关。把这三个问题写在纸上再去对照那份地图范围通常能缩到两三种。我见过太多项目上来就讨论用哪家协议最后发现第一步连“数据要往哪送”都没定义清楚。2. 串口时代的五种基本功仍然是最保底的路径2.1 Modbus RTU轮询最通用、最值得吃透Modbus RTU是串口采集的绝对主力。物理层常见RS485A/B两线半双工手拉手菊花链最远理论上到1200米去掉终端电阻带32个从站没问题实际现场建议不超过20个。通信参数四个必须对齐波特率、数据位、停止位、校验方式常见9600bps、8数据位、无校验或偶校验。功能码只记四个就够日常用03读保持寄存器、04读输入寄存器、05写单个线圈、06写单个寄存器。批量读写用15和16。寄存器类型也要分清楚0x线圈、1x离散输入、3x输入寄存器、4x保持寄存器地址别混。轮询周期怎么估算以读50个保持寄存器为例请求报文8字节响应约103字节总线上约111字节。9600bps下每字节约1ms多往返加响应延迟一轮大约150ms到200ms。轮询10个从站一个完整周期约2秒这是很多人觉得“慢”的根源。想提速就把多个站的地址连续化一次多读而不是一个站一次读几个点。踩过的坑RS485一定要有终端电阻不是随便跳线长线和短线场景电阻位置不一样。32位浮点数占两个寄存器大小端和字序经常要试先用两个已知值验证ByteSwap和WordSwap。有些PLC的Modbus地址是从40001开始的有些从0开始映射表里不换算直接读读回来的数据全是乱的。从站设备无应答时超时不能设太短一般500ms起步否则重试会把总线打爆。2.2 私有串口协议和编程口直连没有Modbus时的两条活路很多仪表、变频器、温控器用的都是厂家私有协议。碰到这种设备第一选择是找厂家要“通信协议手册”第二选择是抓包分析。抓包工具用USB转RS485接在A/B线上被动监听即可。常见的校验算法有CRC16-Modbus、BCC异或、累加和LRC判断哪种校验可以拿报文里的校验字节反推。编程口直连是早期一些PLC型号的专属能力编程口内置了通信协议用专用编程电缆就能读数据不需要额外配置从站地址。它的优点是天然适配缺点是速度慢、同一时间只能一个客户端访问。适合调试阶段和小批量读点不适合长期大规模采集。2.3 串口服务器和多串口卡解决“上位机没有串口”和“并发不够”两个痛点现在工控机上基本都是USB口直接插RS232/485不多串口服务器就是把串口转成以太网旧软件不用改。选型看三点TCP Server还是TCP Client模式、支持几路串口、虚拟串口驱动稳不稳定。串口服务器后IP换了要重新映射很多现场掉线都是因为这个。多串口卡适合单台上位机带大量串口设备的场景PCIe接口的8口/16口RS485卡很常见。核心价值不是“多几个口”而是把原来必须串行轮询的总线切分成多条独立总线并行轮询总吞吐量翻倍提升。配卡时注意卡和工控机有没有兼容性纯国产工控机用某些进口卡会丢驱动。3. 以太网直连的六种主流手段新建项目的主战场3.1 Modbus TCP与S7comm最常用的两种以太网直连Modbus TCP本质上是Modbus RTU包了一层TCP/IP端口502MBAP头替代了CRC校验。注意一个TCP连接默认支持8个并发请求频繁打开关闭会让系统堆积TIME_WAIT连接导致端口耗尽。正确做法是长连接加按需读取别每秒建一次连接。S7comm是某德系品牌PLC的私有协议端口102。开源生态里有snap7这类库可以直接读S7-200 SMART、S7-300/400、S7-1200/1500的DB块、M区、I/Q。有两个坑很隐蔽一是TSAP参数本地TSAP通常0x0100或0x0101远程TSAP要看CPU组态配错就是“无法连接”二是PDU协商长度PLC默认PDU长度240字节一次读8KB的大DB块会失败正确做法是按PDU长度自动适配。3.2 三菱MC、欧姆龙FINS、EtherNet/IP、PROFINET从站四种不同思路的直连三菱MC协议主流是QnA兼容3E帧看注册的都是R2帧。这个我不展开大家自己查。关键是软元件编码D区、W区、R区、ZR区地址转换和字节序是重灾区用编程口测试正常改成以太网后数值突然翻倍多半是字节序问题。欧姆龙FINSUDP端口9600也有TCP版本。FINS帧头结构固定地址域含DA1/DA2读取CIO、WR、DM区。UDP天然适合按需读取但要注意UDP包超过MTU会被分片部分PLC对分片报文处理不好建议按单包1024字节以内读取。EtherNet/IP基于CIP协议TCP端口44818UDP端口2222。显式报文用于配置和点对点读写隐式报文用于周期IO刷新。配置时要找到Assembly实例号还要设置RPI请求包间隔多数默认100ms想要50ms也可以但PLC CPU负载会涨。PROFINET从站这个方法比较特殊。采集设备不是主动去读PLC而是把自己做成一个PROFINET IO设备让PLC当主站周期性扫描它。适合“不改变原系统”的场景IO设备通过GSD文件组态分配I/O地址PLC把采集数据当普通IO读写。优点是对原系统侵入最小缺点是硬件成本高组态相对复杂适合项目方对PLC程序完全锁死、不能改动的现场。主动读和被动收的思路差异值得体会前五种都是上位机主动发起请求最后一种是PLC主动往采集设备推数据。被动收数据实时性更好因为不需要轮询但前提是采集设备能融入原有的PROFINET网络。4. 老现场总线与无线方案两类“补丁型”采集思路4.1 PROFIBUS DP、CANopen、DeviceNet/CC-Link老总线的三种接法老产线很多是PROFIBUS DP网络想从里面拿数据常规做法是加一个DP从站模块或网关采集器作为从站挂到总线上主站PLC照样周期读写IO数据对原程序没有影响。波特率最高12M但现场多数设置为1.5M或500K配置时要从头到尾一致。CANopen在运动控制和分布式IO里很常见核心是对象字典OD和PDO/SDO。PDO是生产者消费者模式数据按周期自动推SDO是客户端服务器模式手动读写。采集CANopen设备最省事的是买带CANopen从站协议的网关把PDO数据映射到以太网或Modbus侧。注意总线终端电阻120欧必配不然数据偶发丢包查到你怀疑人生。DeviceNet和CC-Link在国内工控圈的存量少一些思路一样买对应协议的从站模块或桥接器挂到总线上设置节点地址和占用IO长度。这类方案的最大价值是“不断原系统”代价是硬件成本高、调试周期长。如果现场总线网络不是很大直接换成带多种总线接口的协议转换网关反而更省心。4.2 4G DTU、WiFi、LoRa/NB-IoT三种无线远程采集4G DTU适合没有布线的点位和厂外设备。选型注意支持串口和网口双向透传支持MQTT最好因为云平台基本都要MQTT。配置APN参数、心跳间隔、掉线重连机制流量估算按“点数×轮询周期×心跳包”算。现场最常见的坑是SIM卡欠费、APN不对、机房信号弱运维人员到现场才发现断了一周。WiFi适合车间内部无线改造传输速率高但工业现场金属结构多信号衰减快。不要指望一个AP覆盖整个车间要按AP规划信道启用漫游。实时性要求高的场景慎用WiFi工业AP的漫游切换会有几百毫秒中断PLC之间的实时交互会被打断。LoRa和NB-IoT走的是低功耗低速率路线。LoRa适合自己搭网关的园区内监测要考虑扩频因子、信道规划NB-IoT走运营商网络按连接计费适合环境传感器、设备离线监测。这两个方案实时性低只适合秒级或分钟级上报想拿PLC毫秒级数据无线方案基本都不合适。无线方案绕不开延迟和稳定性两个问题。做项目时一定先评估数据是“控制级”还是“监控级”控制级别碰无线监控级别放宽到几秒完全没问题。5. 网关和边缘计算把“难啃的协议”一网打尽5.1 协议转换网关把“NASA级别”的协议问题变成一个映射表协议转换网关是现场最实用的“集线器”一侧接各种PLC、仪表、变频器另一侧统一输出Modbus TCP或OPC UA。配置过程就像填表——在网页上建立从站地址映射表把不同品牌PLC的寄存器区间映射成统一点位表。为什么值得用上位机和PLC解耦。以后换PLC型号上位机不用改只要网关侧更新映射。选型要点支持多少种入口协议、点位容量多大、映射配置方不方便、支不支持断线缓存。几百个点位的项目用网关去打比用代码轮询更稳妥也更方便现场工程师维护。5.2 边缘计算网关从“采集”到“计算”一层更靠近现场的数字底座边缘计算网关在协议转换基础上多了计算能力本地规则引擎、报警判断、数据清洗、断点续传。最实用的是断点续传——车间网络抖动网关先在本地缓存数据网络恢复后自动补传MES那边不会出现半天数据缺口。很多PLC本身就能做报警逻辑但改PLC程序要去产线停机流程很重。把规则放到边缘网关工厂IT自己就能改阈值灵活性高很多。上行用MQTT接入云平台时注意Topic设计点位名统一用“车间_产线_设备_变量”的格式平台侧做数据模型会轻松很多。IoT平台网关是边缘计算网关的“瘦身版”只做数据转发采集、过滤、按平台物模型上报。选型时多问一句平台SDK是不是自己维护更新频繁的平台尽量别绑死私有SDK优先用MQTT通用协议。6. 软件层与其他五种非常规采集法6.1 OPC UA把数据变成“有语义的信息”而不仅仅是一串寄存器OPC UA是软件层采集的集大成者。它解决的不仅是“能不能连上”而是“建模是否统一”。每个节点可以带单位、工程范围、质量戳、报警信息比裸寄存器高级得多。跨平台、跨系统、带证书加密适合长期维护的项目。OPC DA是上一个时代的东西依赖COM/DCOM跨网络穿透差远程访问需要一堆额外配置能不用尽量不用。如果上位机系统还在用OPC DA建议尽快规划迁移到OPC UA。开源生态里有成熟的OPC UA服务端和客户端库自己封装协议栈的成本比想象中高得多直接用现成的库更划算。6.2 另类但有效的四招时序库直写、板卡硬接线、文件导入、OCR读屏时序数据库直写很多采集程序直接把点位写入时序数据库比如InfluxDB或TDengine保留原始时间戳。有个细节常被忽略PLC内存里的值没有时间戳时间戳是采集端打上去的所以采集端时钟必须做NTP同步否则数据上云后时间线是歪的。板卡级硬接线老设备没有任何通信口时加模拟量/数字量采集模块直接接线。可靠、通用但点位有限、布线成本高。适合那些“通信协议无解但现场有模拟量信号”的设备。文件导入PLC定时生成CSV通过FTP或SD卡拉取。适合实时性要求极低的场合比如每天一份产量表。坑是文件锁冲突读取时如果PLC正在写文件可能读到半行本地做一个文件完整性校验再解析。OCR读屏摄像头拍HMI屏幕再识别数字。这招在老旧设备没有接口、又不能让产线停机改造的场景里确实救过急但别指望太高的稳定性。光线变化、字体闪烁、屏幕刷新都会影响识别率至少要加图像预处理。只能当兜底方案不推荐作为长期数据源。7. 选型决策建议与故障排查实录7.1 用一张“决策链”把25种方法收敛到两三种第一步看链路资源现场有以太网布线优先走以太网直连或协议转换网关只有串口上串口服务器或Modbus RTU。第二步看协议PLC支持Modbus直接读有私有协议但文档齐全按文档开发没有文档抓包或上网关。第三步看实时性秒级监控轮询够用毫秒级联动走PROFINET从站或OPC UA订阅推送。第四步看点位规模不到100个点用简单轮询加缓存超过1000个点老老实实上OPC UA或边缘网关。第五步看维护能力现场工程师懂PLC不懂IT选协议转换网关配置一次后面不用管。这五步走完基本就锁定了方案。剩下的就是执行。7.2 常见问题速查表现象可能原因处理办法完全连不上PLCIP不在同一网段、端口被防火墙挡、PLC连接资源满逐段ping验证网络通断关闭防火墙做对比测试减少并发连接连接成功但数据全0寄存器地址映射错、功能码用错、数据类型不对用厂家自带工具读原始值和采集结果对照从根因开始查数值巨大或负数大小端/字序反32位浮点没做字节交换用两个已知值测试交换字节顺序和字数序数据时通时断网络抖动、RS485接线不良、心跳参数不合理打开通信日志看掉线时间点加缓存和自动重连轮询周期太长每轮读的点太多、串口按块读、从站数量多用批量读多寄存器把无关点位全部关掉必要时多串口并发7.3 我的几条实操心得第一永远先做最小验证。一条网线、一个串口工具先把几个点位读通再部署到全厂。跳过这步的几乎都在现场吃过亏。第二点位表设计比协议还重要。项目一开始就统一点位命名、单位、数据类型后续MES/SCADA开发能省一个月。第三别迷信全自动映射。很多网关的自动映射在复杂寄存器区会出错映射表生成后要人工抽查。第四安全意识别丢。不要把PLC端口直接映射到公网用网关中转、白名单加加密传输。另外所有点位表尽量放到Excel里统一维护然后用脚本批量生成组态文件和采集脚本现场增加点位时只改表不用改程序。这一点在项目后期维护中非常省力。做PLC数据采集这件事最大门槛往往不是协议本身而是“信息差”。知道有25条路可以走就不会在一条路上死磕。我个人这几年的体会是方案越简单越可靠能用一个稳定网关解决的问题就不要自己写一整套轮询程序。数据链条上的每一个环节都用成熟的、看得懂的技术比追求“高大上”的重要得多。 
长河君 · 2026/10/19 1:08:55 · 阅读 1.2k PLC数据采集的25种实用方法：从串口到边缘计算全解析
做工业数据采集这些年我几乎每周都会被人问到同一个问题PLC里的温度、压力、电流、产量、报警这些数据到底怎样才能稳定地弄出来送到监控大屏、MES系统或者云平台上这个问题背后通常是设备已经装了很多年通信接口五花八门有的走串口有的走以太网有的干脆没有通信口只能靠老办法硬接。所谓25种方法不是让你全部用上而是一张“地图”。先看清楚自己手头的PLC是什么类型、现场网络是什么状态、数据最终要到哪里去再从这张图里选出最合适的几种组合。做这件事能解决什么问题它能把工业现场那些“看得见摸不着”的运行数据变成可以统计、可以追溯、可以指导生产的数字资产。适合三类人看一线设备维护和电气工程师、做MES/SCADA的信息化实施人员以及需要在项目里做技术选型的负责人。1. 先把25种方法放进一张地图1.1 一条主线数据从PLC到上位机链路加协议两件事PLC内部的数据本质是一堆内存地址里的值比如保持寄存器、数据块、输入映像区。数据采集干的事情就是把这些地址里的值“读走”。读走的过程只牵涉两件事物理链路串口、以太网、现场总线、无线决定了信号怎么传。通信协议Modbus、S7、MC、FINS这些决定了设备之间怎么“对话”。很多方案选错不是协议学得不够而是没分清自己缺的是链路还是协议。一台老设备只有RS485口你想走以太网那不是换协议能解决的得加串口服务器或工业网关。反过来PLC明明有以太网口上位机却只支持Modbus那需要做的是协议转换。先分清这条主线后面所有方法都不会乱。1.2 二十五种方法总览表按物理链路和应用层划分我把主流方案分成六类合计二十五种类别方法典型应用场景串口链路5种Modbus RTU轮询、私有串口协议解析、编程口直连、串口服务器中转、多串口卡并发老设备、仪表、变频器、小规模产线以太网链路6种Modbus TCP、S7comm、三菱MC协议、欧姆龙FINS、EtherNet/IP、PROFINET从站中大规模PLC、新建产线、多站点并发现场总线3种PROFIBUS DP、CANopen、DeviceNet/CC-Link老总线产线改造、不断原系统无线链路3种4G DTU、WiFi、LoRa/NB-IoT无布线点位、远程监控、环境监测网关与边缘3种协议转换网关、边缘计算网关、IoT平台网关多品牌混用、断网续传、云平台接入软件与其他5种OPC UA服务、时序数据库直写、板卡级硬接线、文件/FTP导出、OCR读屏同构信息化、极小点位、极端老设备为什么按“链路协议”分而不是按PLC品牌分因为同一种协议可以跨品牌使用。Modbus几乎被所有PLC支持或者通过扩展模块支持。按品牌去学越学越窄按链路和协议去学越用越宽。到后面你会形成条件反射看到一个项目的设备清单脑子里自动弹出对应链路和协议。1.3 选型第一原则不急着选技术先回答三个问题数据量多大几十个点还是几千个点对应轮询和订阅推送两种完全不同的思路。实时性多高秒级还是毫秒级决定是走周期轮询还是走事件上报。现场有没有网车间里有稳定网线就走以太网没布线就考虑无线或加网关。把这三个问题写在纸上再去对照那份地图范围通常能缩到两三种。我见过太多项目上来就讨论用哪家协议最后发现第一步连“数据要往哪送”都没定义清楚。2. 串口时代的五种基本功仍然是最保底的路径2.1 Modbus RTU轮询最通用、最值得吃透Modbus RTU是串口采集的绝对主力。物理层常见RS485A/B两线半双工手拉手菊花链最远理论上到1200米去掉终端电阻带32个从站没问题实际现场建议不超过20个。通信参数四个必须对齐波特率、数据位、停止位、校验方式常见9600bps、8数据位、无校验或偶校验。功能码只记四个就够日常用03读保持寄存器、04读输入寄存器、05写单个线圈、06写单个寄存器。批量读写用15和16。寄存器类型也要分清楚0x线圈、1x离散输入、3x输入寄存器、4x保持寄存器地址别混。轮询周期怎么估算以读50个保持寄存器为例请求报文8字节响应约103字节总线上约111字节。9600bps下每字节约1ms多往返加响应延迟一轮大约150ms到200ms。轮询10个从站一个完整周期约2秒这是很多人觉得“慢”的根源。想提速就把多个站的地址连续化一次多读而不是一个站一次读几个点。踩过的坑RS485一定要有终端电阻不是随便跳线长线和短线场景电阻位置不一样。32位浮点数占两个寄存器大小端和字序经常要试先用两个已知值验证ByteSwap和WordSwap。有些PLC的Modbus地址是从40001开始的有些从0开始映射表里不换算直接读读回来的数据全是乱的。从站设备无应答时超时不能设太短一般500ms起步否则重试会把总线打爆。2.2 私有串口协议和编程口直连没有Modbus时的两条活路很多仪表、变频器、温控器用的都是厂家私有协议。碰到这种设备第一选择是找厂家要“通信协议手册”第二选择是抓包分析。抓包工具用USB转RS485接在A/B线上被动监听即可。常见的校验算法有CRC16-Modbus、BCC异或、累加和LRC判断哪种校验可以拿报文里的校验字节反推。编程口直连是早期一些PLC型号的专属能力编程口内置了通信协议用专用编程电缆就能读数据不需要额外配置从站地址。它的优点是天然适配缺点是速度慢、同一时间只能一个客户端访问。适合调试阶段和小批量读点不适合长期大规模采集。2.3 串口服务器和多串口卡解决“上位机没有串口”和“并发不够”两个痛点现在工控机上基本都是USB口直接插RS232/485不多串口服务器就是把串口转成以太网旧软件不用改。选型看三点TCP Server还是TCP Client模式、支持几路串口、虚拟串口驱动稳不稳定。串口服务器后IP换了要重新映射很多现场掉线都是因为这个。多串口卡适合单台上位机带大量串口设备的场景PCIe接口的8口/16口RS485卡很常见。核心价值不是“多几个口”而是把原来必须串行轮询的总线切分成多条独立总线并行轮询总吞吐量翻倍提升。配卡时注意卡和工控机有没有兼容性纯国产工控机用某些进口卡会丢驱动。3. 以太网直连的六种主流手段新建项目的主战场3.1 Modbus TCP与S7comm最常用的两种以太网直连Modbus TCP本质上是Modbus RTU包了一层TCP/IP端口502MBAP头替代了CRC校验。注意一个TCP连接默认支持8个并发请求频繁打开关闭会让系统堆积TIME_WAIT连接导致端口耗尽。正确做法是长连接加按需读取别每秒建一次连接。S7comm是某德系品牌PLC的私有协议端口102。开源生态里有snap7这类库可以直接读S7-200 SMART、S7-300/400、S7-1200/1500的DB块、M区、I/Q。有两个坑很隐蔽一是TSAP参数本地TSAP通常0x0100或0x0101远程TSAP要看CPU组态配错就是“无法连接”二是PDU协商长度PLC默认PDU长度240字节一次读8KB的大DB块会失败正确做法是按PDU长度自动适配。3.2 三菱MC、欧姆龙FINS、EtherNet/IP、PROFINET从站四种不同思路的直连三菱MC协议主流是QnA兼容3E帧看注册的都是R2帧。这个我不展开大家自己查。关键是软元件编码D区、W区、R区、ZR区地址转换和字节序是重灾区用编程口测试正常改成以太网后数值突然翻倍多半是字节序问题。欧姆龙FINSUDP端口9600也有TCP版本。FINS帧头结构固定地址域含DA1/DA2读取CIO、WR、DM区。UDP天然适合按需读取但要注意UDP包超过MTU会被分片部分PLC对分片报文处理不好建议按单包1024字节以内读取。EtherNet/IP基于CIP协议TCP端口44818UDP端口2222。显式报文用于配置和点对点读写隐式报文用于周期IO刷新。配置时要找到Assembly实例号还要设置RPI请求包间隔多数默认100ms想要50ms也可以但PLC CPU负载会涨。PROFINET从站这个方法比较特殊。采集设备不是主动去读PLC而是把自己做成一个PROFINET IO设备让PLC当主站周期性扫描它。适合“不改变原系统”的场景IO设备通过GSD文件组态分配I/O地址PLC把采集数据当普通IO读写。优点是对原系统侵入最小缺点是硬件成本高组态相对复杂适合项目方对PLC程序完全锁死、不能改动的现场。主动读和被动收的思路差异值得体会前五种都是上位机主动发起请求最后一种是PLC主动往采集设备推数据。被动收数据实时性更好因为不需要轮询但前提是采集设备能融入原有的PROFINET网络。4. 老现场总线与无线方案两类“补丁型”采集思路4.1 PROFIBUS DP、CANopen、DeviceNet/CC-Link老总线的三种接法老产线很多是PROFIBUS DP网络想从里面拿数据常规做法是加一个DP从站模块或网关采集器作为从站挂到总线上主站PLC照样周期读写IO数据对原程序没有影响。波特率最高12M但现场多数设置为1.5M或500K配置时要从头到尾一致。CANopen在运动控制和分布式IO里很常见核心是对象字典OD和PDO/SDO。PDO是生产者消费者模式数据按周期自动推SDO是客户端服务器模式手动读写。采集CANopen设备最省事的是买带CANopen从站协议的网关把PDO数据映射到以太网或Modbus侧。注意总线终端电阻120欧必配不然数据偶发丢包查到你怀疑人生。DeviceNet和CC-Link在国内工控圈的存量少一些思路一样买对应协议的从站模块或桥接器挂到总线上设置节点地址和占用IO长度。这类方案的最大价值是“不断原系统”代价是硬件成本高、调试周期长。如果现场总线网络不是很大直接换成带多种总线接口的协议转换网关反而更省心。4.2 4G DTU、WiFi、LoRa/NB-IoT三种无线远程采集4G DTU适合没有布线的点位和厂外设备。选型注意支持串口和网口双向透传支持MQTT最好因为云平台基本都要MQTT。配置APN参数、心跳间隔、掉线重连机制流量估算按“点数×轮询周期×心跳包”算。现场最常见的坑是SIM卡欠费、APN不对、机房信号弱运维人员到现场才发现断了一周。WiFi适合车间内部无线改造传输速率高但工业现场金属结构多信号衰减快。不要指望一个AP覆盖整个车间要按AP规划信道启用漫游。实时性要求高的场景慎用WiFi工业AP的漫游切换会有几百毫秒中断PLC之间的实时交互会被打断。LoRa和NB-IoT走的是低功耗低速率路线。LoRa适合自己搭网关的园区内监测要考虑扩频因子、信道规划NB-IoT走运营商网络按连接计费适合环境传感器、设备离线监测。这两个方案实时性低只适合秒级或分钟级上报想拿PLC毫秒级数据无线方案基本都不合适。无线方案绕不开延迟和稳定性两个问题。做项目时一定先评估数据是“控制级”还是“监控级”控制级别碰无线监控级别放宽到几秒完全没问题。5. 网关和边缘计算把“难啃的协议”一网打尽5.1 协议转换网关把“NASA级别”的协议问题变成一个映射表协议转换网关是现场最实用的“集线器”一侧接各种PLC、仪表、变频器另一侧统一输出Modbus TCP或OPC UA。配置过程就像填表——在网页上建立从站地址映射表把不同品牌PLC的寄存器区间映射成统一点位表。为什么值得用上位机和PLC解耦。以后换PLC型号上位机不用改只要网关侧更新映射。选型要点支持多少种入口协议、点位容量多大、映射配置方不方便、支不支持断线缓存。几百个点位的项目用网关去打比用代码轮询更稳妥也更方便现场工程师维护。5.2 边缘计算网关从“采集”到“计算”一层更靠近现场的数字底座边缘计算网关在协议转换基础上多了计算能力本地规则引擎、报警判断、数据清洗、断点续传。最实用的是断点续传——车间网络抖动网关先在本地缓存数据网络恢复后自动补传MES那边不会出现半天数据缺口。很多PLC本身就能做报警逻辑但改PLC程序要去产线停机流程很重。把规则放到边缘网关工厂IT自己就能改阈值灵活性高很多。上行用MQTT接入云平台时注意Topic设计点位名统一用“车间_产线_设备_变量”的格式平台侧做数据模型会轻松很多。IoT平台网关是边缘计算网关的“瘦身版”只做数据转发采集、过滤、按平台物模型上报。选型时多问一句平台SDK是不是自己维护更新频繁的平台尽量别绑死私有SDK优先用MQTT通用协议。6. 软件层与其他五种非常规采集法6.1 OPC UA把数据变成“有语义的信息”而不仅仅是一串寄存器OPC UA是软件层采集的集大成者。它解决的不仅是“能不能连上”而是“建模是否统一”。每个节点可以带单位、工程范围、质量戳、报警信息比裸寄存器高级得多。跨平台、跨系统、带证书加密适合长期维护的项目。OPC DA是上一个时代的东西依赖COM/DCOM跨网络穿透差远程访问需要一堆额外配置能不用尽量不用。如果上位机系统还在用OPC DA建议尽快规划迁移到OPC UA。开源生态里有成熟的OPC UA服务端和客户端库自己封装协议栈的成本比想象中高得多直接用现成的库更划算。6.2 另类但有效的四招时序库直写、板卡硬接线、文件导入、OCR读屏时序数据库直写很多采集程序直接把点位写入时序数据库比如InfluxDB或TDengine保留原始时间戳。有个细节常被忽略PLC内存里的值没有时间戳时间戳是采集端打上去的所以采集端时钟必须做NTP同步否则数据上云后时间线是歪的。板卡级硬接线老设备没有任何通信口时加模拟量/数字量采集模块直接接线。可靠、通用但点位有限、布线成本高。适合那些“通信协议无解但现场有模拟量信号”的设备。文件导入PLC定时生成CSV通过FTP或SD卡拉取。适合实时性要求极低的场合比如每天一份产量表。坑是文件锁冲突读取时如果PLC正在写文件可能读到半行本地做一个文件完整性校验再解析。OCR读屏摄像头拍HMI屏幕再识别数字。这招在老旧设备没有接口、又不能让产线停机改造的场景里确实救过急但别指望太高的稳定性。光线变化、字体闪烁、屏幕刷新都会影响识别率至少要加图像预处理。只能当兜底方案不推荐作为长期数据源。7. 选型决策建议与故障排查实录7.1 用一张“决策链”把25种方法收敛到两三种第一步看链路资源现场有以太网布线优先走以太网直连或协议转换网关只有串口上串口服务器或Modbus RTU。第二步看协议PLC支持Modbus直接读有私有协议但文档齐全按文档开发没有文档抓包或上网关。第三步看实时性秒级监控轮询够用毫秒级联动走PROFINET从站或OPC UA订阅推送。第四步看点位规模不到100个点用简单轮询加缓存超过1000个点老老实实上OPC UA或边缘网关。第五步看维护能力现场工程师懂PLC不懂IT选协议转换网关配置一次后面不用管。这五步走完基本就锁定了方案。剩下的就是执行。7.2 常见问题速查表现象可能原因处理办法完全连不上PLCIP不在同一网段、端口被防火墙挡、PLC连接资源满逐段ping验证网络通断关闭防火墙做对比测试减少并发连接连接成功但数据全0寄存器地址映射错、功能码用错、数据类型不对用厂家自带工具读原始值和采集结果对照从根因开始查数值巨大或负数大小端/字序反32位浮点没做字节交换用两个已知值测试交换字节顺序和字数序数据时通时断网络抖动、RS485接线不良、心跳参数不合理打开通信日志看掉线时间点加缓存和自动重连轮询周期太长每轮读的点太多、串口按块读、从站数量多用批量读多寄存器把无关点位全部关掉必要时多串口并发7.3 我的几条实操心得第一永远先做最小验证。一条网线、一个串口工具先把几个点位读通再部署到全厂。跳过这步的几乎都在现场吃过亏。第二点位表设计比协议还重要。项目一开始就统一点位命名、单位、数据类型后续MES/SCADA开发能省一个月。第三别迷信全自动映射。很多网关的自动映射在复杂寄存器区会出错映射表生成后要人工抽查。第四安全意识别丢。不要把PLC端口直接映射到公网用网关中转、白名单加加密传输。另外所有点位表尽量放到Excel里统一维护然后用脚本批量生成组态文件和采集脚本现场增加点位时只改表不用改程序。这一点在项目后期维护中非常省力。做PLC数据采集这件事最大门槛往往不是协议本身而是“信息差”。知道有25条路可以走就不会在一条路上死磕。我个人这几年的体会是方案越简单越可靠能用一个稳定网关解决的问题就不要自己写一整套轮询程序。数据链条上的每一个环节都用成熟的、看得懂的技术比追求“高大上”的重要得多。