AI前线去年做一条自动化包装线的上位机改造，甲方点名要“C# WPF + 西门子PLC + 实时报警大屏”，当时我第一反应是用WinForms糊一版就能跑，结果发现报警列表的刷新逻辑、PLC断线重连、界面线程调度这些事远没有想象中简单。后来趁着一个新项目机会，直接用MVVMLight把整套东西重写了一遍，这里把完整的落地思路和踩坑记录整理出来，覆盖从S7通讯选型到报警状态机设计，再到DataGrid性能处理的全部过程。
这套内容不是单纯介绍某个控件或某条API。它能解决的问题很明确：在WPF上位机项目里，如何稳定地从西门子PLC采集报警点，如何把报警的产生、恢复、确认做成“事件流”而不是“死表格”，以及如何用MVVMLight把通讯层、业务层和界面层拆干净。如果你正在做上位机开发、维护一套老旧的设备监控程序，或者面试前想系统捋一遍这条技术路线，本文应该能帮你省不少时间。
1. 先聊选型：WPF加MVVMLight，这套组合在图什么
1.1 组态软件和自研上位机的分界线
很多做设备的朋友上来就会问：设备监控不是有WinCC、组态王、InTouch这些组态软件吗，为什么还要专门写一套上位机？
我的看法是，组态软件的优势和劣势都写在它的定位上：画面搭建快、驱动多、适合标准工艺画面，但一旦业务逻辑超出“显示变量+弹窗报警”的范畴，定制成本会迅速失控。比如设备要和MES交换工单，要和SQL Server记录质量追溯数据，要对接视觉相机、读码器或者机械臂，还要在界面里做复杂的参数配方管理——这些场景里，组态软件的脚本环境和控件生态反而成了瓶颈。
而C#在这条赛道上有一个很现实的优势：招人容易。国内工控圈子熟悉C#的人远比熟悉组态脚本的人多，出了问题给一段调用栈，工程师能顺着逻辑Debug下去。WinForms和WPF性能足够，和数据库、WebService、Modbus、S7等通信库都有大量现成方案，代码的版本管理和多人协作也比组态工程文件来得成熟。
如果是单机设备、点位少、画面固定的项目，我很建议直接用组态软件，快速交付才是关键。但只要项目里出现“业务逻辑比重超过画面展示”“协议种类超过两种”“后续要持续迭代算法或界面”的苗头，自研上位机基本就是正确答案。
1.2 WPF相比WinForms的优势在哪里
WinForms能写上位机吗？当然能，而且我早期大部分项目都是WinForms写的。但当我要做一个“实时报警列表”时，WinForms的短板会非常明显。
报警列表不是简单的TextBox输出，它的需求通常长这样：不同等级的报警要显示不同颜色；产生和恢复要有不同的图标；已确认和未确认的要能区分；还要在列表里嵌入“确认”按钮。WinForms做这些UI状态切换时，大多依赖在后台代码里逐控件操作，一个页面塞几百行事件代码是常事。WPF则提供了数据绑定、数据模板、样式和触发器，界面的“状态”可以直接绑定到ViewModel的属性上，后台逻辑不需要关心某个单元格究竟画成什么颜色。
举个例子，报警等级这一列想按“严重/一般/提示”显示不同底色，在WPF里只需给属性加一个枚举，再用一个Converter把枚举转换成Brush，完全不用在代码里写if分支去设置控件颜色。类似这种绑定的表达力，是WinForms很难给你的；WinForms并非不能实现，但后期改需求时，拖动控件的开发体验会让人非常痛苦。
WPF还有一个对工控项目相当重要的隐性优势：它是保留渲染线程和逻辑线程分离的架构。界面卡顿不会直接拖垮后台的数据采集循环，只要你不主动用Dispatcher把重活全塞给UI线程，界面上短暂的刷新压力通常不会让整个程序假死。这点在高频报警刷新场景里特别关键。
1.3 MVVMLight在今天的角色和适用圈
MVVMLight是一个很轻量的MVVM框架，NuGet包只有几十KB，核心能力就是ViewModelBase、RelayCommand、SimpleIoc和Messenger。比起Prism的模块化、导航、区域管理那一整套，MVVMLight更像一把顺手的小刀，适合中小型WPF项目。
先说清楚它的现状：作者Laurent Bugnion对项目的功能迭代基本已经停下来了，新项目如果从零开始，我一般会建议评估CommunityToolkit.Mvvm或者Prism。但如果你接手的是一套已经用MVVMLight跑了两三年的设备程序，或者团队里没人愿意为了IOC容器和导航框架折腾半天，那MVVMLight在工控上位机这个场景里依旧完全够用，不用为了炫技而重构。
用MVVMLight做上位机最大的收益在于它逼着你把代码分成View、ViewModel、Model三层。以前用WinForms写通讯，PLC数据直接写在窗口类里；用MVVMLight之后，PLC的读写在Service层，界面上的“开始采集”“停止采集”“确认报警”都变成Command，界面状态全部通过绑定驱动。这时候程序像不像一个大型单页应用已经不重要，重要的是代码可测了、可维护了，出问题能顺着数据流排查。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 与西门子PLC通讯：协议库选型和连接层封装
2.1 前置条件：PLC侧的软硬件准备
和西门子PLC通讯通常走以太网的S7协议。物理上很简单，一台电脑、一根网线、PLC的以太网口接同一网段就行，但软件层面有一个极其容易忽略的坑：S7-1200/1500若要通过外部上位机直接访问数据块，必须在TIA博途里把CPU属性的“防护与安全”设置为允许通讯，同时确认“允许从远程伙伴进行PUT/GET通讯访问”是勾上的。
这个勾选被很多人漏掉。你代码写得再对，连接也可能超时，报错还往往是“连接被拒绝”或者无明确原因。第一次调S7-1500时我就是在这个设置上卡了一个下午，后来发现CPU默认禁止外部PUT/GET，代码倒是无辜的。
另外，S7-1500的DB块默认开启了“优化的块访问”。如果保持这个默认设置，传统S7协议通过绝对地址比如DB1.DBD24去读数据，往往是读不出来的，甚至返回一堆全零或者报“对象不存在”。解决方法是把要用到的那个DB块的“优化的块访问”属性取消勾选，或者改用基于