PLC数据采集方案横评：从串口直采到边缘网关怎么选？

干工控的都知道，PLC数据采集这件事，看起来简单，做起来一坑接一坑。同样是要把几十台变频器、仪表的数据弄到上位机或者MES里去，有人直接拿串口线读数，有人在电脑上装一堆驱动，有人干脆买了工业网关。方案五花八门，成本从几千到几万，实时性从秒级到毫秒级，踩坑之后才明白，选错采集方案等于给自己埋雷。

这篇文章我把常见的PLC采集方案从头到尾捋一遍，从串口直采、以太网直采、OPC中间层，到边缘网关和组态软件自带采集，结合现场真实场景做一次横评。适合正在做设备数据采集、MES对接、远程运维，或者被老板一句话“把车间设备数据弄上来”支配的工程师，看完基本能知道自己的项目该选哪条路。

1. 先把“采集”这件事拆开看：数据到底在哪儿、怎么拿

1.1 你是不是也遇到过这样的现场

很多项目一开始并不是缺设备，而是数据“拿不上来”。生产车间里PLC品牌有西门子、三菱、欧姆龙，底下挂着一堆变频器、温控表、流量计，上层却有MES、SCADA、自己写的看板系统，可能还有一套云平台。每个系统要的数据不一样，刷新速度也不一样，最后全压在“怎么从PLC里面把数据读出来”这一个环节上。

最容易犯的错是上来就问“用什么软件能读西门子PLC”，其实这不是软件的问题，而是你根本没有搞清楚该从哪一层读数据。PLC采集不是一个固定动作，它分三种流量。

1.2 采集方案的本质是选“对话层级”

第一类是采集PLC内部的变量，比如D区数据、M继电器、DB块里的运行参数。这类数据是PLC自己算出来的，采集系统要“看懂”PLC的通信协议。

第二类是采集PLC底下挂的设备数据，典型就是一台上位PLC通过Modbus RTU挂着32台变频器，你真正关心的是每台变频器的电流、频率、温度。这种数据可以直接去读PLC的映射区，也可以绕过PLC直接和变频器对话，两条路走出来的方案完全不同。

第三类是反向控制，不只是读，还要往PLC里写数据，比如给启动信号、改设定值。这时候对通信协议的完整度、写入确认机制就有要求了，不是所有免费库都支持得那么完美。

想明白了这三类需求，再去看各种方案就清楚了。本质上每个方案都是在选“跟PLC对话的层级”：是走串口寄存器，还是走以太网协议，还是通过中间软件再转发一次。下面一个个拆。

2. 串口直采：老方案没死，小项目依然真香

2.1 编程口协议的“免费午餐”

串口直采是PLC采集最古老的方式，但远没被淘汰。三菱FX系列有个编程口，专门用来接GX Works系列软件，结果一堆第三方厂家发现这个口照样可以走协议通信，于是就有了基于FX编程口协议的采集方案。西门子S7-200的PPI协议也是同理。

我早年间做的一个小项目，车间里一台三菱FX3U带十几台温控表，上位机要实时显示温度曲线。当时没什么预算，我就直接用C#写串口通信，用三菱的编程口协议，一条指令能把连续地址的数据整块读回来。配合USB转串口线，成本几十块钱，跑了好几年都没出问题。

很多人一听到“协议”就觉得难，其实老一代PLC的编程口协议文档早就被研究透了。搜一下三菱FX通信协议格式，或者看看HslCommunication这种开源库的实现，就知道串口直采是真“平易近人”。

2.2 串口直采的三个硬伤

串口方案最大的坑是速度。9600波特率下，读一批寄存器要几十毫秒起步，如果现场有几十台设备要么轮询时间被拉得特别长，要么只能牺牲实时性。

第二个坑是物理距离。RS485理论上能跑1200米，但实际现场电磁干扰一上来，布线走得不讲究，通讯误码率会让你怀疑人生。而且串口只能一对一地占PLC的编程口，你在采集的时候别人就没法用电脑调试PLC了。

第三个坑是对PLC程序有隐性要求。三菱的RS指令就是典型的例子，很多人以为用RS指令就能随便和上位机通信，结果发现要自己在PLC里维护发送接收缓冲区、自己算校验码，程序写得稍微不严谨，数据就乱套了。

所以我现在的判断是：串口直采只适合设备少、点位少、实时性要求不高的小项目。一旦超过十台设备或者刷新周期需要小于1秒，果断往以太网方案走。

3. 以太网直采：最主流，但协议千万别搞混

3.1 西门子S7协议与Snap7库

现在新项目里我首选以太网直采，原因很简单：快、稳、不占编程口。以西门子为例，S7-1200/1500本身就带以太网口，走的是西门子私有的S7协议，而不是开放世界的Modbus TCP。虽然S7协议是私有协议，但已经被逆向得很透了。

这里必须重点提Snap7这个开源库。它是一个跨平台的S7通信库，支持Windows、Linux，甚至能跑在树莓派上。我经常跟他人在项目里这样配合：上位机是C#写的，直接引用Snap7，连接PLC、读DB块、写M区，几行代码搞定，稳定性和速度都不错。

using Snap7; var client = new S7Client(); int result = client.Connect("192.168.0.10", 0, 1); if (result == 0) { byte[] buffer = new byte[256]; client.DBRead(1, 0, 256, buffer); client.Disconnect(); }

很多人以为读DB块就是把整个数据区一次性搬过来，实际上Snap7里DBRead是“按字节读”，你要先知道DB块里的数据结构，把不同的变量偏移量大差不差记在心里。这里建议建一张点位表，把变量名、DB号、起始字节、数据类型全部列出来，后续程序好维护得多。

除了C#，Snap7还有Python、Node-RED的绑定。尤其在视觉系统对接PLC这种场景，Python脚本直接在工控机上跑，用Snap7把拍照结果写到PLC里，比走中间数据库轻量多了。

3.2 三菱MC协议与欧姆龙FINS

说完了西门子，再看日系PLC。三菱的主流以太网采集走的是MC协议，就是那个“QnA兼容3E帧”“4E帧”的MC协议。三菱FX5U、Q系列、L系列基本都支持，网口开启后，上位机发个二进制帧就能把D区、M区数据读回来。

这里有个容易搞混的点：三菱老款的FX3U不带以太网口，要用MC协议得加一块以太网模块（比如FX3U-ENET），或者退而求其次走串口。国产的汇川、信捷等一系列兼容三菱指令的PLC，也大多支持类MC协议的以太网通信，做法可以完全照搬。

欧姆龙走的是FINS协议。它的UDP版本不需要建立连接，直接把指令包发到PLC的IP端口上，速度快，但要求网络环境稳定，丢包了就要靠上层重试。FINS/TCP则像S7那样先建连接再通信。HslCommunication这个国产开源库对MC协议和FINS协议的封装都做得很完整，C#用户直接调用即可，省掉自己拼帧的功夫。

日系PLC的协议文档虽然不像西门子那样被各类博客反复分析，但好在有这些开源库兜底，上手速度并不慢。真正要警惕的是协议版本别搞错，比如三菱MC协议分帧格式A、帧格式B、QnA兼容3E，选错了连握手都过不了。

3.3 以太网连接模式：VM里连不上PLC的坑

以太网直采遇到最多的怪问题，反而发生在“开发调试阶段”。很多工程师喜欢在VMware里跑Windows开发环境和上位机，然后发现虚拟机和PLC怎么都Ping不通。这个问题几乎快成行业日经帖了。

问题根源是虚拟机的网络模式。VMware的NAT模式下，虚拟机是躲在宿主机后面“上外网”的，PLC往虚拟机的IP主动发数据包基本到不了。正确的做法是选“桥接模式”，让虚拟机直接和PLC处在同一个物理局域网里，虚拟机的IP也手动设成PLC同网段，例如PLC是192.168.0.10，虚拟机就设成192.168.0.88。

还有一个细节容易被忽视：桥接模式要选对物理网卡。笔记本如果同时插着有线网口和无线网卡，VMware默认可能桥接到无线网卡上，而PLC插的是有线网口，结果虚拟机和宿主机的Ping都通、但就是连不上PLC。把虚拟机里的“网络适配器”设置改为“桥接模式”，并且“复制物理网络连接状态”，指定到有线网卡，问题马上消失。

4. OPC Server中间层：跨品牌、多协议混采的“翻译官”

4.1 OPC DA与OPC UA的区别

如果说以太网直采是“自己跟PLC说方言”，那OPC Server就是请了一个“翻译官”。这个翻译官见过西门子、三菱、欧姆龙、AB、Modbus等等各种设备，你跟它说我要读哪台设备的哪个变量，它自己内部去跟PLC通信，然后把数据统一成OPC格式喂给你的上位机。

OPC DA是基于Windows的COM/DCOM技术的，很老，配置极其痛苦。DCOM安全设置稍微不对，远程客户端就访问不了，而Windows更新换个补丁也可能让DCOM突然罢工。反正如果有人跟你推荐新项目用OPC DA，建议直接否定。

要上就上OPC UA。这是跨平台的统一架构，不依赖Windows COM，可以走TCP、HTTPS，数据模型自带安全认证和加密。西门子有官方的SIMATIC NET OPC UA Server，也有S7-1500直接内置OPC UA Server的玩法，三菱、欧姆龙新系列的PLC也慢慢都支持OPC UA了。

不过OPC UA不是“即插即用”的协议，你得在PLC里把需要采集的变量“暴露”成OPC UA节点，或者通过UaExpert这类客户端去浏览Server的地址空间。第一次接触时可能会被命名空间、节点ID绕晕，但用熟之后确实是一劳永逸。

4.2 什么时候值得上OPC

我个人总结了一套判断标准，值得上OPC的场合无非三种。

第一种是现场品牌太杂。既有西门子又有三菱和欧姆龙，如果每个都自己写协议解析驱动，开发量直接爆炸。OPC Server把驱动统一在一个软件里，上位机只连Server一个点就够了。

第二种是系统层级多。MES访问SCADA、SCADA再访问OPC Server、OPC Server再去读PLC，这种分层架构在半导体、汽车、制药行业是标准做法。上位机不需要关心底下的PLC具体是什么牌子的，以后换品牌、换型号只动OPC Server的配置。

第三种是搞WinCC的时候。WinCC虽然不是非OPC不可，但WinCC 8.0的架构里，OPC UA关联PLC变量这事可以做得很顺手，变量管理、报警、历史存储全部走一套。

OPC方案的最大缺点是不便宜。西门子SIMATIC NET按“授权”卖，价格不低；Kepware按点位数量卖，点数一多预算蹭蹭涨。如果只是几台PLC的小项目，还是老老实实以太网直采吧。

5. 边缘网关/IoT盒子：远程采集和上云的正解

5.1 网关到底做了什么

现场数据要往云平台上送时，很多工程师的第一反应是“我在电脑上写个程序，转发到云不就行了”。这思路在实验环境没问题，放到工厂现场就跑不起来，因为工控机不是为了7×24小时转发数据设计的，断电断网没人管，程序崩溃没人重启。

工业边缘网关解决的就是这个“无人值守”问题。现在的边缘网关体积跟一个路由器差不多，DIN导轨一卡，供电一接，网线连PLC，它的内部固件里已经预制好了西门子S7、三菱MC、欧姆龙FINS、Modbus等各种协议驱动，你只要在网页配置界面里把PLC的IP、端口、要采集的寄存器填进去，它自己就会按设定的周期去读数据。

读上来的数据怎么用？一部分可以走MQTT协议直接上云，阿里云IoT、AWS IoT都能对接；一部分可以在网关里做本地逻辑，比如算个平均温度、做个越限报警再往上报；还有一部分可以写进网关的本地存储里，断网时缓存、恢复网络后续传。

5.2 选网关看哪几个参数

筛网关别只看“支持多少种协议”，我在项目里踩过的坑建议从这几个参数把关。

先看协议并发能力。有些网关说是支持Modbus，但同一个时刻只能同时采集一路总线，你挂32台变频器等于一台一台排队读，轮询周期直接奔着几十秒去。好的网关支持多路并发任务，比如Modbus RTU和Modbus TCP同时采集，或者把32台变频器分成多个任务并行轮询。

再看点位容量。网关采集点位上限是500还是5000，直接关系到你后期加设备要不要换硬件。很多厂商宣传“无限点”，但其实内存和CPU是有限的，点位一多采集周期被迫拉长，所以点位容量必须和刷新周期一起看。

最后看断点续传能力。网关断网后本地能缓存多少条数据？缓存满了是覆盖旧数据还是停止采集？这几个问题在项目验收时才暴露就晚了。

远程场景下我是强烈推荐边缘网关的，尤其是有“把车间数据同步到总公司云平台”这种需求的项目，用网关比用工控机靠谱太多。

6. 组态软件自带采集：可视化、存储一步到位

6.1 WinCC等组态软件的采集逻辑

组态软件，也常被归为SCADA或HMI软件，WinCC、组态王、MCGS这类工具，在工业现场的定位是“人机界面”，但它的数据采集能力其实很容易被忽略。很多人只拿组态软件做画面，实际上它是自带完整采集引擎的。

以WinCC为例，它和西门子PLC通信可以走S7协议，也可以走SIMATIC NET、OPC UA，变量管理非常成熟。项目里如果本来就打算做画面和历史趋势，那顺便把数据存到SQL Server里，等于同时完成了“采集+存储+展示”三件事，省掉单独写采集程序的功夫。

MCGS更狠，它在触摸屏领域普及率极高，S7-200 Smart做从站配合MCGS组态画面是很多小项目的主流搭配。MCGS组态软件电脑版可以直接和Smart PLC通信，采集S7-200系列的数据，画面里做几个按钮、几个趋势曲线，几小时就能搞定一个小型监控系统。

6.2 一个项目该不该用组态软件来采

我的建议是，如果你本来就要做画面、做报警、做历史趋势，那组态软件就是顺理成章的选择。但如果你是拿组态软件当纯采集工具，只顾着把数据倒给MES，那不一定划算。

组态软件的问题在于太重。打开一个WinCC项目，光启动服务就要好几分钟，占用的资源也不少。而且它的数据存储格式通常是内置的数据库，要和MES系统做实时对接时，往往还得通过OPC或者开放数据库接口来二次开发。

还有Smart PLC做智能从站这个思路也该提一下。Smart系列虽然定位经济型，但当从站时可以支持多种数据交换方式，配上MCGS组态画面，小项目低成本方案可以做得非常顺。只是Smart的以太网口性能决定了它不适合高并发、高密度的数据采集，量一大就掉链子，这点要有心理准备。

7. 横评对照表与选型决策路径

7.1 六种方案横向对比

前面讲的五类方案（串口直采、以太网直采、OPC中间层、边缘网关、组态软件），加上“Modbus TCP直采”这种更泛化的以太网方案，我汇总成一张表。

这里要特别说一句：实时性“百毫秒级”对绝大多数工业数据足够了，真正的硬实时控制根本不应该走采集这条路，那是PLC的CPU直接干的事。有人非要在采集方案上抠“毫秒级”的实时性，方向就错了。

7.2 我总结的选型决策路径

实际项目里，我一般会按下面这条路径来选型，基本上几分钟就能把方案方向定下来。

第一步，问自己一个问题：读出来的数据要给谁？ 给HMI画面、MES、云平台、还是给自己写的上位机软件？不同的消费方决定用组态软件、OPC还是直采。

第二步，看PLC的阵营。 如果现场是“一个品牌独大”，优先以太网直采。西门子用Snap7或S7协议，三菱用MC协议，欧姆龙用FINS，Modbus设备用Modbus TCP，全是免费方案，性能还好。

第三步，看设备数量和数据密度。 设备少、点位少，随便怎么采都行；设备多、轮询周期要求高，就要算一下总帧耗时，存疑时优先选支持并发或多通道的网关，而不是靠单片机硬轮询。

第四步，看运维方式。 设备在现场、人在办公室，必须上云就选边缘网关；设备在现场、人在现场，上位机本地监控就选以太网直采或组态软件。

这套决策路径不复杂，但每次都能快速过滤掉一堆没必要的方案。拿不准时，先用最简单的方式把数据读通，再去讨论架构扩展，切忌一上来就搞一堆重型组件。

8. 实战翻车现场：轮询时长、资源占用与通讯超时

8.1 32台变频器Modbus轮询，周期到底怎么算

热搜里那个“西门子PLC与32个变频器Modbus通讯”的经典问题，我每次给计算过程，听得最多的一句话就是“原来轮询要这么久”。

以Modbus RTU、9600波特率、读每台变频器的3个保持寄存器（频率、电流、温度）为例算一笔账。一帧主站请求大约8字节，从站应答大约10字节，加上间隔和校验，一帧总计约20字节。9600波特率下每秒大约960字节，那么单台变频器一次完整读写的耗时约为40毫秒。32台全部轮一遍就是1280毫秒，约1.3秒。

听起来还行？如果把波特率降到4800，周期翻倍到2.6秒；如果每台变频器要读10个寄存器，帧长增加，周期还要进一步拉长；如果你还想顺便写设定值，每个写操作又得多一帧多出几十毫秒。

所以结论是：一条Modbus RTU总线挂32台变频器做“控制”是可行的，但做“数据采集且要求秒级刷新”就要优化了。优化手段无非这么几个：提高波特率到19200或38400、把32台变频器分到两条或多条总线上、利用Modbus功能码一次读多个寄存器、精简采集变量数量。实际项目里我更喜欢把32台变频器分成2条总线，每条16台，轮询周期就能稳稳压进1秒以内。

8.2 连接建立时间和通讯超时设置

还有人对“创建连接PLC需要多长时间”有疑问，比如用Snap7的Connect方法，明明PLC就在同一个交换机上，为什么有时候连接要等好几秒。

这个问题的关键在通讯超时设置。Snap7的ConnectTimeout默认值偏保守，局域网环境可以大胆调到2000毫秒，甚至800毫秒。千万不要用默认超时去连一个不存在的IP，否则程序会挂在Connect这步傻等。我就是因为没设超时，调试时误以为PLC坏了，折腾了半个小时发现只是IP填错了。

同样的道理适用于所有采集方案。Modbus TCP客户端、OPC UA客户端的连接超时、读写超时必须显式设置。一轮轮询里有一两台设备掉线，如果超时设置不合理，会把整个轮询周期拖垮。我的习惯是：设备掉线时，单次通讯超时最多300到500毫秒，连续失败三次再报故障，既不影响其他设备的轮询，也不至于错失瞬时的通讯恢复。

8.3 博图里怎么查PLC资源使用情况

采集工作开始前，先看看PLC自己的资源余量，这个习惯能帮你省掉不少通讯故障排查时间。在博途（TIA Portal）里，最简单的做法是右键项目里的PLC，选择“编译”，编译完成后在信息窗口里能看到整数区、位区、DB块容量的使用情况。

如果编译时勾选了“生成与S7-1200/S7-1500有关的程序块信息”这类选项，还能看到每个DB块的大小、最大块尺寸、加载内存和保持性内存的占用率。现场遇到过DB块和通讯资源分配不合理导致的“偶发连不上”，查下来就是PLC的网络资源被占满了，上位机新连接握手都排不上队。

更直观的办法是让PLC别闲着，开一个HTTP Web Server或者OPC UA Server，在浏览器里直接看在线诊断页面。S7-1500内置的Web服务器里能看到通信资源、连接池信息。虽然日常采集不太会顶爆资源，但通信资源一旦耗尽，现象就和“网络坏了”一模一样，排查时别只盯着交换机，也要看看PLC这边的连接数。

8.4 通讯协议与采集代码之间的“隐性耦合”

还有一个很多人忽略的坑在代码层面。无论你用Snap7、HslCommunication，还是自己拼协议帧，一定要把“通讯层”和“业务层”分开。通讯层只负责读数据、写数据、管理连接状态，业务层只负责算设备状态、存数据库、触发报警。

我接手过一套代码，把通讯指令和界面刷新逻辑写在一起，一个串口查询函数里既有拼接报文又有绘制曲线，结果就是通讯稍微卡顿，界面直接卡死。重构后把采集放到独立线程或者独立服务里，数据丢到内存队列，界面只管订阅队列，稳定得多了。

这套“解耦”思路，无论用哪种采集方案都适用。串口直采可以在后台线程死循环轮询，Snap7可以用S7Client的异步事件或者定时器触发，边缘网关更彻底，数据采集根本不在你的上位机里。采集与业务解耦，是让整套系统“从能用到好用”的关键一步。

做PLC采集这几年，我最大的感受是方案本身没有绝对的好坏，只有跟场景匹配不匹配。我自己现在的默认选择是：先看是否必须上云，是就选边缘网关；否则优先用Snap7或者HslCommunication这类开源库做以太网直采，开发快、成本低、性能足；只有现场品牌太杂、层级太多时才上OPC UA，组态软件只作为展示层。另外说一句，现在AI辅助生成PLC程序和采集代码越来越常见，但生成出来的代码一定要有人盯着把关，尤其是通信超时、异常重连这些逻辑，机器不太理解现场的“玄学故障”。能把数据稳定采上来，比把代码写得花哨重要得多。