1. 从标题拆需求WPF MES 上位机在产线里到底管什么做工厂软件这行十多年最深的体会就是车间的软件方案选型错了后面怎么写都别扭。早年在 WinForms 上写上位机界面粗糙、布局固定车间主任一句帮我把看板上的按钮挪到右边我就得改代码重新发版。后来全面转向 WPF 做 MES 产线执行系统前后交付了十几条产线的项目才慢慢摸出这套组合的正确打开方式。最近完整梳理了一遍手头的 WPF MES 上位机源码项目正好把需求拆解、技术选型、架构设计、核心实现和排障实录一次性讲清楚。标题探索 WPF MES 上位机源码产线执行系统看起来长拆开就三层意思WPF 是界面技术栈MES 是业务方向上位机源码是交付形态。说人话这是一套部署在产线工位电脑上的桌面软件负责把车间的人和设备拉进同一套执行流程——接收工单、防止物料用错、采集设备参数、记录质检结果、生成追溯数据。它一边跟 PLC、扫码枪、视觉相机打交道一边把生产数据汇总给上层 MES 服务端。网络上经常有人问生产制造企业一套足以的系统其实前提就是业务层和设备层分得清这套 WPF 方案恰好就是这种思路的典型落地。1.1 先定位角色上位机、MES、WPF 各自管哪一段很多刚入行的朋友把这三者混在一起实际分工非常明确。上位机贴着设备走的软件。PLC、扫码枪、仪器仪表这些硬件需要有人类能看的界面需要逻辑判断上位机就是干这个的。它优先保证实时性和稳定性。MES制造执行系统管流程的系统。工单从 ERP 下发到车间后MES 负责安排到哪条线、哪个工位告诉工人做什么工序记录每件产品的过站记录、质检结果、批次物料最后生成追溯档案。WPF只是实现上位机界面和服务端客户端的一种技术手段。它提供数据绑定、MVVM、丰富的控件模板特别适合做工艺看板、参数曲线、防错提示这些交互复杂的界面。放在一起理解就顺了工位电脑上的 WPF 程序是 MES 的一个现场客户端负责把设备数据变成业务数据。比如扫码枪读到物料条码上位机先做合法性校验通过后再把某工位、某时间、某物料、某设备参数写入 MES 服务端形成一条新的过站记录。1.2 为什么是 WPF对比 WinForms 和 Web 方案我用过 WinForms也评估过纯 Web 方案最后选择 WPF 不是情怀是实打实的场景需要。WinForms 的优势是上手快、学习成本低但它的界面和数据逻辑绑定太紧做一个界面可配置的通用工位程序非常吃力。早期项目里我为了做一个设备状态变化闪烁提醒得堆一堆 Timer 和控件事件十几个窗体下来代码就成一团乱麻。更重要的是 WinForms 对高 DPI 和触摸屏支持差现在产线工控机基本都是 1080P 以上屏幕WinForms 的控件在缩放后经常错位。纯 Web 方案呢B/S 架构在管理层报表、远程查看上很舒服但在设备交互这一层会很痛苦浏览器访问串口、USB 摄像头、本地 IO 卡都需要额外插件或网关车间断网时基本抓瞎。产线环境对稳定性的要求是断网可以程序不能崩本地桌面程序更适合这个场景。WPF 胜在三个点上。第一XAML 声明式界面让界面和逻辑分离我可以把整条产线的工位页面做成数据模板换一个型号就换一套显示配置不必重编译。第二数据绑定和 MVVM 让界面刷新天然跟随业务数据设备温度变了界面上那个数字自动变不用再去控件上找赋值。第三WPF 基于 DirectX 渲染动画、曲线、大屏看板这类高频刷新界面不卡。再加上 C# 生态里有 Modbus、S7、OPC UA 一大堆现成库和 PLC 通信这层省了很多事。1.3 源码项目该怎么看拿到一套 MES 源码先看什么标题里特意带源码两个字说明这类项目不少人是买来或开源下载来研究的。我评估一套 WPF MES 上位机源码顺序是固定的避免被花哨界面带偏。先看依赖注入和框架。如果项目里大量使用 Prism 或 CommunityToolkit.Mvvm说明作者在关注可维护性如果每个页面都在代码后面硬写业务逻辑直接 new 服务、new 数据库连接那这套源码大概率只能当参考做不了地基。再看设备通讯层是否抽象。产线最确定的事就是设备会变今天接三菱 PLC明天换基恩士扫码枪后天加台视觉相机。一套好的源码会把设备驱动抽象成统一接口上层业务不直接依赖具体型号。我看到过很多源码把西门子 PLC 通信逻辑直接写进界面按钮事件里这种项目换个设备就要改界面怎么敢拿上线。最后看数据访问层。工厂的数据库设计很考验功底工单表、批次表、过站记录表之间怎么关联高频采集的设备参数是不是单独的表追溯查询能不能 5 秒内出结果这些决定系统能不能经受住一天几万件产品的体量。2. 产线执行系统的架构设计与业务模块划分2.1 三层架构和数据流先画清楚再写代码做产线系统最忌讳上来就写界面。我的习惯是先定数据流一条产品从上线到下线所有数据怎么流动心里有谱了再动手。这套 WPF MES 上位机源码的典型架构分三层设备层PLC、传感器、扫码枪、视觉相机、称重仪表、机器人。它们负责感知和动作。工位层每台工控机上跑的 WPF 客户端也就是上位机。负责采集设备数据、显示操作指引、接收人工输入、校验防错规则、输出执行指令。服务层MES 服务端负责工单管理、物料台账、工艺路径、质量判定、追溯汇总、报表看板。数据库一般用 SQL Server 或 MySQL。数据流大致是这样的ERP 把生产计划下发到 MES 服务端服务端拆成工单并分配产线工位 WPF 客户端从服务端拉取当前工单和工艺要求工人扫描物料条码上位机校验物料是否匹配当前工单不匹配直接报警随后 PLC 按工艺参数执行动作上位机实时采集温度、压力、扭矩等参数超过上下限自动触发防错工人填写质检结果或调用视觉系统自动判定最后所有过站记录和参数快照写入服务端形成完整追溯链。这套流程里上位机其实是个翻译裁判的角色。它把设备的电信号翻译成业务数据又根据业务规则反向控制设备。所以上位机代码里最核心的不是界面是通讯和规则引擎。2.2 核心业务模块拆解一个工位系统要具备哪些能力下面这张表是做产线执行系统的通用模块清单标题里的一套足以就是指把这些模块完整覆盖。模块主要职责常见实现要点工单管理接收服务端工单、展示工序任务工单状态机待生产/生产中/暂停/完工上料防错校验物料条码与工单 BOM 是否匹配扫码枪解析、条码前缀规则配置工艺参数管理下发设备参数、监视实时值参数上下限、采集频率、报警策略数据采集从 PLC/仪表读取数据Modbus TCP、S7、OPC UA 多协议适配质量检验人工判定、视觉自动判定结果录入检验项模板、合格/不合格挂起追溯管理记录每件产品的全生命周期信息批次号、工位、时间、设备参数快照实时看板展示产线状态、节拍、不良率WPF 大屏绑定、定时刷新Andon 报警异常呼叫、停线响应声音提示、颜色闪烁、事件上报设备管理记录设备状态、维护计划OEE 统计、故障代码分类别小看防错模块这是工厂最愿意买单的功能。装配线拿错物料是最常见的批量质量事故而 WPF 在这里有个巨大的便利绑定和模板可以做到扫码枪一响界面自动弹出一个大红框显示错误原因和正确物料位置。我做过一条发动机装配线就是靠这个模块把错装率从每月 3 起降到 0那感觉跟打了一场胜仗一样。2.3 源码项目的典型目录结构和阅读顺序拿到一套源码后建议按下面的方式快速建立项目地图MES.HostComputer/ ├─ MES.Core/ // 领域模型、枚举、接口定义 ├─ MES.DeviceDriver/ // PLC、扫码枪、视觉等设备驱动 ├─ MES.Service/ // 工单、工艺、追溯、报表业务服务 ├─ MES.ViewModels/ // 视图模型层MVVM 的中间层 ├─ MES.Views/ // WPF 界面 XAML 文件 ├─ MES.Database/ // 建表脚本、EF Core 映射 ├─ MES.Common/ // 日志、配置、工具类 └─ MES.Host/ // 程序入口、依赖注入装配、启动项阅读顺序我建议是 MES.Core → MES.DeviceDriver → MES.Service → MES.ViewModels → MES.Views。Core 里定义了接口和数据模型理解它就知道系统的业务边界DeviceDriver 是硬件适配层看它如何把不同设备统一成同一个接口Service 是业务核心看工单流转、防错逻辑怎么落地最后再看界面因为好的 WPF 界面应该薄得像一层纸只是 ViewModel 的投影。这个结构本身也是我评估源码质量的标准。如果一套源码连项目分层都没有所有类堆在一个项目里那是为了卖源码而拼凑的演示项目不建议做二次开发的地基。3. 核心功能实操与关键技术实现3.1 设备通讯层的设计与实现设备通讯层是上位机的心脏。在 WPF 项目里通讯层的手段很多Modbus TCP 因为通用性强是我默认的首选接入方式西门子 PLC 用 S7 协议、基恩士/海康视觉走 TCP 自定义报文、称重仪表用串口。为了不让上层被具体协议绑架我习惯先定义通用的设备通道接口public interface IDeviceChannel { Taskbool ConnectAsync(CancellationToken ct); TaskDeviceReadResult ReadAsync(DevicePoint[] points); Taskbool WriteAsync(DevicePoint point, object value); event EventHandlerDeviceStateEventArgs StateChanged; }DevicePoint 是点位抽象表示一个可寻址的数据项带地址、数据类型、读写权限、上下限。比如1 号工位气缸压力就是一个 DevicePoint它的来源可能是 Modbus 的 4x0001 寄存器将来换设备改驱动映射就行上层业务不需要动。采集频率是这里最容易拍脑袋的地方。我的经验是分优先级安全类信号急停、光栅100ms工艺参数温度、压力500ms 到 1sOEE 统计类数据 5s 到 10s。全部统一 100ms 轮询既浪费带宽又让数据库压力增大划不来。断线重连必须做成状态机。真实车间里 PLC 重启、网线松动太常见了通讯层不能断了就报错拉倒。我做的重连逻辑是连续 3 次读取失败进入 Offline 状态界面显示黄色警示条后台每 5 秒尝试重连成功则自动恢复同时把断线时间、恢复时间、丢失的数据点数记进日志。这个日志在产线扯皮时有大用途。3.2 MVVM 架构和实时界面刷新落地WPF 项目不用 MVVM 等于浪费了这半个框架。我目前常用 CommunityToolkit.Mvvm源生成器能省掉大量模板代码属性定义非常清爽public partial class MonitorViewModel : ObservableObject { [ObservableProperty] private double currentTemperature; // 设备温度达到上限时自动触发的报警逻辑 partial void OnCurrentTemperatureChanged(double value) { IsOverTemp value Threshold; } }实时刷新是最容易翻车的技术点。采集服务是后台线程ViewModel 属性是 UI 线程的直接赋值必然跨线程异常或者界面卡死。我总结出来的可靠做法是后台采集线程把数据放进线程安全的缓冲区UI 侧开一个 200ms 到 500ms 的 DispatcherTimer 定时快照刷新。换句话说让界面以人眼能感知的频率刷新而不是跟设备频率死磕。这样处理有几个好处首先避免高频属性变更风暴导致界面掉帧其次让锁竞争降到最低最后是无论设备采集频率怎么改界面代码都不用动。实测下来30 个动态点位用 500ms 快照刷新CPU 占用率不到 5%在工控机上非常稳。如果确实需要控件级实时变化像进度条动画或曲线描点我会把数据聚合后再批量推给 ObservableCollection并且用 BeginInvoke 而不是 Invoke 触发 UI 更新减少死锁风险。记住一个原则跨线程操作 UI能异步就异步尽量别阻塞等待。3.3 数据持久化与追溯设计产线系统的数据有两个特点一是高频二是要可追溯。直接往业务表里灌采集数据是新手常见错误正确做法是分表存储。主表结构大致是这样WorkOrder工单编号、产品型号、数量、状态、计划时间。MaterialLot物料批次号、物料编码、供应商、入库时间。ProcessRecord产品序列号、工单编号、工位编号、工序号、过站时间、操作员。DeviceSnapshot工单编号、产品序列号、设备点名称、数值、采集时间。QualityResult产品序列号、检验项、判定结果、检验员、不良代码。设备参数快照这种高频数据必须单独放一张表并且用批量方式写入。一条装配线一天能产生几十万条参数记录逐条 INSERT 会让 SQL Server 连接池告急事务日志也会快速膨胀。我常用 SqlBulkCopy 或 EF Core 的批量扩展做整批写入配合主表按天归档查询速度才能始终保持在秒级。追溯查询是这个模块的验收标准。我的经验是任何追溯查询都应该能在 10 秒内定位到某成品用的哪批物料、在哪个工位由谁安装、设备当时参数是多少。要达到这个速度索引设计是核心——ProcessRecord 上建产品序列号索引DeviceSnapshot 上建工单号时间联合索引再配合数据库层做按天的分区表。3.4 部署、运行环境与离线兜底工位 PC 建议选无风扇工控机用固态硬盘跑 Windows 10 IoT LTSC 或 Windows 11 LTSC关闭自动更新避免半夜蓝屏。部署时把程序装成 Windows 服务 或开机自启保证断电重启后能自己回到工作状态。离线兜底是工厂场景特有的需求。车间网络再稳定也会有交换机故障的时候上位机不能一断网就停工。我的做法是本地 SQLite 缓存未上报的过站记录和参数网络恢复后按时间顺序补传同时标记离线补传字段避免 ERP 和 MES 对账时出现歧义。这条经验救过我很多次有个项目的 MES 服务端重启整整 8 小时产线靠离线模式一直在跑事后一次性补传没有任何数据丢失。4. 常见问题排查与性能优化实录4.1 高频问题速查按症状找原因我在十几个产线项目里反复踩过的坑整理成一张速查表基本覆盖 80% 的上位机故障。症状常见原因解决方案扫码后界面卡死几秒串口读取阻塞 UI 线程扫码枪读取改后台 Task用异步事件驱动界面假死、CPU 反而低Dispatcher.Invoke 发生死锁尽量用 BeginInvoke避免线程相互等待跑几小时内存翻倍事件订阅未解除、静态集合持有引用页面关闭时退订事件用弱事件模式高频参数刷新掉帧采集线程直接操作 UI 集合改为缓冲快照 定时批量刷新设备断电后程序不恢复没有断线重连状态机实现 Offline 状态自动重连多工位同时写库报死锁事务过长、锁粒度过大精简事务、按工单号分库分表某台电脑控件字体模糊未适配高 DPIapp.manifest 声明 PerMonitorV2图片用矢量追溯查询卡出天际参数表和业务表混在一张表里分表 索引 按天归档摄像头图像无法显示Web 项目里常见的权限限制桌面上则检查采集参数WPF 用 DirectShow 或第三方摄像头库验证分辨率匹配版本升级后现场状态不对配置文件没有版本兼容配置项做版本号升级时主动迁移4.2 关键性能基线和优化手段给一组实测数据供参考32 个工位的系统每工位 1 秒采集 8 个设备点位数据库峰值写入约每秒 256 条记录这套架构在普通 i5 工控机和 SQL Server 部署下毫无压力。真正需要优化的是瞬时峰值比如一批 200 件订单同时完工会产生 200 条 ProcessRecord 和 1600 条 DeviceSnapshot一次性入库会卡顿。解决办法是给写入队列设置缓冲每满 100 条或每 2 秒批量落库一次均匀化数据库负载。界面的性能优化我更看重资源释放。WPF 的 DataTemplate 和绑定在页面频繁切换时会累积内存。我会在 ViewModel 的 OnNavigatedFrom 里显式释放订阅长驻对象用 WeakReference。另外图片资源尽量用矢量绘制Path 图形少用高分辨率 PNG因为工位界面要长时间运行内存泄漏比功能缺失更难查。4.3 现场排障的三条独家经验第一所有工位程序必须带运行日志。我统一用 Serilog 把操作日志、通讯日志、异常堆栈写到本地文件按天滚动保留 30 天。车间设备出问题后和厂商对质时日志里的时间戳和数据快照就是最有用的证据。第二先在虚拟设备上测试再接真机。我会给通讯层写一个模拟器实现同样的 IDeviceChannel 接口模拟扫码、模拟温度波动、模拟断网。全部逻辑跑通后再接真实 PLC能省掉一半的现场调试时间。这个习惯是我被现场程序等设备折磨过一次后养成的。第三现场发版必须留回退通道。工控机的程序更新不能像开发机上那样直接覆盖我会保留上一版本目录更新时做冷备并写一个一键回退的批处理。如果新版本在车间大屏上显示异常5 分钟内能回到上一版保住产线不中断。5. 源码改造方向与个人心得5.1 这套源码拿回来怎么改成自己的拿到任何 WPF MES 上位机源码我建议先做三件事。第一把命名空间和项目名全部替换成自己的品牌前缀避免多个系统混在一起时程序集冲突。第二删除无关的演示数据和演示设备驱动只保留当前产线需要的部分。第三把配置外置数据库连接串、设备 IP、采集频率、防错规则全部放进 JSON 配置文件最好再做一层配置加密防止交付完现场被随意改坏。扩展方向上值得投入的是数据上报和云端对接。现在很多工厂要求产线数据上云做分析我给这套 WPF 上位机加过 MQTT 上报模块把每分钟的设备状态聚合推送到边缘网关再由网关转发到云端。上位机本身不需要承担大数据分析它只要把最有价值的数据有序送出去就够了。5.2 我的最终体会稳定压倒一切回顾这些年做 WPF MES 上位机的经历最大的教训是车间软件稳定永远排在功能前面。产线不会因为你的界面好看而提前完工但会因为一个通讯线程崩溃而停线一小时。所以写代码时多想想设备断电了怎么办服务端挂了怎么办工人在界面上乱点了怎么办把这些意外路径都用代码写明白交付后你会少接无数个半夜电话。如果让我给正在入手的同行一句建议那就是先把通讯层做实把接口定义稳再谈界面美化。WPF 的价值在于它能帮你把复杂的产线业务做得清楚直观但前提是你的地基——设备通讯、数据链路、离线兜底——立得住。把这篇文章里的模块一个个落地你手头那套源码就能真正变成产线上跑得稳、敢依赖的产线执行系统。