这几年跑工厂项目几乎每个制造企业都在提智慧工厂。老板要数据透明化车间要看板展示产量、设备状态、良率。折腾过Web大屏也用过工控组态软件最后真正稳定、好维护的方案往往是C# WPF写的一套桌面端电子看板。这篇文章就从一个实际可运行的C# WPF大数据电子看板源码出发聊聊怎么从需求梳理、架构设计到代码实现把工厂里的海量数据实时搬到屏幕上做成一个让车间主任愿意天天盯着的数据平台。不管你是刚接触C#上位机开发的新手还是已经在做MES、SCADA系统的老手只要需要把设备数据、产量数据、质量数据以看板形式呈现这篇文章里的架构思路和踩坑经验都能直接拿来用。文末还会分享一些源码二次开发的技巧帮你省掉几个月的摸索时间。1. 项目需求拆解与方案选型1.1 智慧工厂电子看板到底要解决什么问题电子看板不是简单地做个漂亮界面它的核心是把工厂里分散、异构、实时变化的数据汇聚到一块屏幕上让人一眼就能看出当前生产状态。这里的关键词是“一眼”所以在需求阶段就要区分哪些数据需要秒级刷新哪些数据只需要分钟级汇总。以我接触过的机加车间为例看板上通常要显示当前产线的实时产量、目标产量、达成率每台设备的状态运行、待机、报警、停机设备OEE、良品率、返工率关键工艺参数温度、压力、转速的趋势曲线今日班次、当前时间、倒班倒计时异常报警信息与处理状态这些数据来源可能完全不同。产量数据来自数据库设备状态来自PLC或OPC Server报警数据来自MES接口。设计看板的第一步就是要梳理清楚每条数据从哪来、多久来一次、实时性要求多高。如果一开始不把数据源理清后面做出来的看板只会是个花架子。1.2 为什么选C# WPF而不是Web/其他框架每次谈方案总有人问为什么不直接用Web大屏ECharts确实漂亮浏览器也方便。但真在车间环境下试过就明白Web页面要面对浏览器内存回收不稳定、跨域接口繁琐、离线场景无法使用等一堆问题。车间里的工控机配置普遍不高很多还是Windows 7系统浏览器版本老旧跑复杂动画直接卡死。C# WPF的优势在于桌面应用可以直接访问本机资源连接PLC、OPC、串口、USB摄像头都没障碍WPF绑定了强大的数据绑定和模板机制适合动态看板界面可以利用.NET原生多线程能力和高级UI虚拟化处理大数据量刷新比Web更可控部署简单一台工控机装好.NET环境就能跑离线也能用如果你已经有现成的Web服务或移动端需求可以考虑用WPF做数据采集端Web做展示端。但对于单一车间级的电子看板WPF桌面方案落地最快维护成本也最低。WinForms虽然更轻量但界面美观度和数据绑定能力远不如WPF做看板这种视觉要求高的场景还是WPF更合适。1.3 大数据展示的技术路线选择电子看板上的“大数据”跟互联网大数据不完全一样核心挑战是高频更新和大量点位同时刷新。比如一台设备每秒产生10个数据点车间100台设备每秒就是1000个点再加上历史曲线查询普通控件根本扛不住。我当时的选型思路是实时曲线优先使用轻量级自绘控件或高性能图表库比如ScottPlot或OxyPlot避免使用体积臃肿的商业图表控件数据表格使用DataGrid并开启虚拟化模式绑定大量数据时不会卡界面状态灯/跑马灯用WPF的Shape和动画实现减少图片资源占用数据刷新使用System.Reactive或简单的Timer 异步委托避免阻塞UI线程如果你的数据量到了几万点以上建议引入内存数据库或实时计算库比如FluentFTP SQLite做历史存储加一层缓存来削峰填谷。看板展示层只关心最近一份快照历史分析交给后台服务。这个分层思想是整套架构的核心。2. 源码核心架构与关键技术点2.1 MVVM模式如何落地一套能二次开发的WPF看板源码MVVM模式是跑不掉的。MVVM不是给老板看的是给自己和后来维护的人看的。没有MVVMMainWindow.xaml.cs能写出几千行加一个功能就牵一发动全身。我常用的分层方式代码结构大致是Models存放数据实体比如DeviceStatus, ProductionRecord, AlarmInfoViewModels对应每个看板区域的业务逻辑比如DeviceStatusViewModel, ProductionViewModelViewsXAML界面通过Binding和ViewModel通信Services数据采集、数据库访问、日志记录等公共服务Helpers通用转换器、命令、附加属性ViewModel层负责暴露属性给界面。比如设备状态我在DeviceStatusViewModel里定义ObservableCollection 界面直接绑定到ItemsControl每一个设备就是一个Card模板。关键点在于通知属性变更。属性多了以后手动写PropertyChanged特别繁琐。我的习惯是引入CommunityToolkit.Mvvm用[ObservableProperty]特性自动生成通知代码。比如public partial class ProductionViewModel : ObservableObject { [ObservableProperty] private int currentYield; [ObservableProperty] private int targetYield; public double AchievementRate TargetYield 0 ? 0 : (double)CurrentYield / TargetYield * 100; }这里要注意计算属性AchievementRate不会随源属性自动更新需要在源属性变化时调用OnPropertyChanged(nameof(AchievementRate))。如果嫌麻烦可以直接用partial方法监听partial void OnCurrentYieldChanged(int value) { OnPropertyChanged(nameof(AchievementRate)); }这是源码里比较容易被忽略的细节但恰恰是MVVM写得好不好的分水岭。2.2 数据采集与接入层设计看板的数据接入是整个项目最枯燥也最容易出问题的地方。我做的这套源码设计了统一的数据源接口IDataSource支持三种典型来源数据库轮询配置SqlConnection定时执行SQL查询拉取产量、质量数据OPC DA/UA客户端通过OPC协议读取设备实时数据适用于西门子、罗克韦尔等PLC场景MQTT订阅接收物联网网关上报的数据适合分布式采集场景为每个数据源写独立的服务类比如OpcDataSource、SqlDataSource、MqttDataSource都实现IDataSourcepublic interface IDataSource { void Connect(); void Disconnect(); DataPacket Read(); event EventHandlerDataPacket DataReceived; }DataPacket是个通用容器包含点位名称、值、时间戳、质量戳。这样上层界面不关心数据到底来自PLC还是数据库只管绑定DataPacket即可。实际项目中连接西门PLC最常用的还是OPC。建议直接用OPC UA方式比OPC DA更安全跨平台性也更好。如果PLC老版本不支持UA可以先用Kepware等网关做转换。写OPCUA客户端时用open62541的.NET封装或Opc.Ua.Core库注意订阅模式要设置在100ms~1000ms之间太频繁会加重PLC负载。2.3 大数据量实时刷新的性能优化这是整套源码里的技术重头戏。很多人的看板做出来能跑但数据一多就卡原因往往出在两点频繁重建UI元素或者跨线程操作集合。先说ObservableCollection的问题。当数据点特别多时不要逐个Add或Update否则UI会疯狂触发CollectionChanged事件。我的做法是批量刷新private readonly object _lockObj new object(); private ListDeviceStatus _batchBuffer new ListDeviceStatus(); public void UpdateDeviceStatus(ListDeviceStatus statusList) { lock (_lockObj) { _batchBuffer.Clear(); _batchBuffer.AddRange(statusList); } Application.Current.Dispatcher.Invoke(() { DeviceStatusCollection.Clear(); foreach (var item in _batchBuffer) { DeviceStatusCollection.Add(item); } }, DispatcherPriority.Background); }不要在Timer回调里直接操作UI集合一定要Invoke到UI线程但要注意使用Background优先级避免刷新操作抢占渲染线程导致看板动画掉帧。其次要充分利用WPF的UI虚拟化。看板里的产量列表如果很长用ListBox或DataGrid时要设置VirtualizingPanel.IsVirtualizingTrue和VirtualizationModeRecycling。如果不设置几千行数据一次性生成可视树内存直接飙上去。图表控件的性能优化也重要。实时曲线如果每秒刷新一次不停AddPoint然后重绘CPU占用会很高。建议只保留最近N个点比如500个点超出后循环覆盖。或者使用滚动窗口只更新当前可见区间。2.4 可视化图表与看板布局实现看板界面设计有几个原则重要数据放中间、大字号显示、状态变化用颜色区分。布局用Grid分区域每个区域对应一个ViewModel。我的XAML结构通常长这样Grid Grid.RowDefinitions RowDefinition HeightAuto/ RowDefinition Height*/ RowDefinition Height1.2*/ /Grid.RowDefinitions Grid.ColumnDefinitions ColumnDefinition Width2*/ ColumnDefinition Width3*/ /Grid.ColumnDefinitions !-- 顶部产量卡 -- Border Grid.Row0 Grid.Column0 Style{StaticResource CardStyle} StackPanel TextBlock Text今日产量 / TextBlock Text{Binding CurrentYield} FontSize48 FontWeightBold/ /StackPanel /Border !-- 曲线区域 -- Border Grid.Row1 Grid.Column1 Style{StaticResource CardStyle} oxy:PlotView Model{Binding TrendModel} / /Border /Grid给每个Border用统一的CardStyle设置背景、圆角、阴影看板看起来才整齐。状态灯可以用Ellipse控件绑定设备状态值通过触发器切换颜色。比如设备状态为“报警”时红灯闪烁可以用Style.Triggers加DoubleAnimation实现闪烁效果。但要注意动画资源占用不要每个设备都单独建动画把刷屏数量控制在50个以内否则动画线程会撑爆CPU。3. 从零搭建电子看板的关键步骤3.1 环境准备与项目初始化开发环境建议直接用Visual Studio 2022安装.NET 6/8 SDK根据目标工控机系统选择。如果现场机器还在用Win7就选.NET Framework 4.7.2这是WPF最稳的版本。如果可以用Win10/11直接用.NET 6以上版本性能提升明显部署时还能用单文件发布。创建项目时我一般分三个工程Dashboard.Core类库放Models, Services, HelpersDashboard.AppWPF主程序放Views, ViewModelsDashboard.Tests单元测试项目主要测试数据计算逻辑和刷新策略分工程的好处是后期可以把数据采集部分单独摘出来做成Windows服务看板只做展示层。这个架构升级路径非常顺。NuGet包建议安装CommunityToolkit.MvvmMVVM工具包OxyPlot.Wpf图表Opc.Ua.Core / Opc.UaFxOPC通讯MQTTnetMQTT客户端Dapper数据库访问安装完先跑一次空模板确保环境没问题。3.2 数据源连接与数据模型定义先把数据模型定义好。这部分不建议图省事实体字段要与现场数据源对应。比如设备状态类public class DeviceStatus { public int DeviceId { get; set; } public string DeviceName { get; set; } public string Status { get; set; } // Running, Idle, Alarm, Offline public double CurrentSpeed { get; set; } public double Temperature { get; set; } public DateTime UpdateTime { get; set; } }数据源连接方面如果走数据库用Dapper写一个简单仓储public class ProductionRepository { private readonly string _connString; public ProductionRepository(string connString) { _connString connString; } public async TaskListProductionRecord GetTodayRecords(DateTime shiftStart) { using var conn new SqlConnection(_connString); var sql SELECT * FROM ProductionRecords WHERE RecordTime shiftStart ORDER BY RecordTime; return (await conn.QueryAsyncProductionRecord(sql, new { shiftStart })).ToList(); } }注意看板查询SQL不要写那些涉及敏感词的东西就是普通的业务查询。另外一定要优化索引避免大表全扫。产量表如果一天几十万行按分钟归档查询区间要做索引覆盖否则每次刷新SQL都要好几秒。3.3 看板界面开发与绑定界面开发时先用假数据把布局跑通再接真实数据。这是我反复强调的习惯。假数据可以写在ViewModel的构造函数里比如public ProductionViewModel() { // 测试数据 currentYield 326; targetYield 500; }这样开发界面不用一直连数据库。等界面调好再把构造函数里的假数据注释掉改成调用服务加载数据。绑定的时候所有属性名都要拼写正确否则运行时不报错界面就是空白。建议打开Output窗口看到Binding错误就立刻处理。我自己因为拼错单词排查过整整一个下午后来干脆给项目加了StyleCop强制检查拼写规则。如果界面里要做定时刷新建议用一个全局刷新调度器统一管理各个ViewModel的刷新周期public class RefreshScheduler { private readonly Dictionarystring, Timer _timers new(); public void AddJob(string name, TimeSpan interval, Action action) { var timer new Timer(_ { action(); }, null, TimeSpan.Zero, interval); _timers[name] timer; } }注意action里面一定要自己处理线程切换把数据更新Invoke到UI线程。这部分的线程模型搞清楚了整个看板就稳定了。3.4 部署与运行注意事项部署WPF看板到车间工控机最简单的方式就是发布成自包含单文件。dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFiletrue这样生成的exe直接拷贝过去就能跑不用装.NET运行时。但要注意单文件首次启动略慢因为要解压运行时到内存。如果工控机配置低还是用传统的目录发布更稳。部署时还要注意工控机分辨率可能不是标准1080P看板窗口要支持缩放长时间运行需要关注内存占用建议定时重启或使用自愈任务看板工控机必须关闭系统休眠和自动更新否则会出现白屏数据库连接串不要写死放到配置文件里方便维护4. 常见问题与排查技巧实录4.1 界面卡顿与内存泄漏界面卡顿最常见的原因是DataGrid或ListBox没有开启虚拟化以及频繁创建Brush和动画。排查时先用任务管理器看CPU和内存如果内存逐步上涨多半是有绑定事件泄漏或Timer没有释放。我踩过的坑是在ViewModel里订阅了数据源的DataReceived事件但没有实现IDisposable释放事件订阅。结果看板跑一天后内存从200M涨到2G。解决办法是在ViewModel的Cleanup方法里统一退订事件并让所有ViewModel实现IDisposable。还有一个隐蔽问题是WPF的Image控件如果频繁加载图片容易卡顿。看板里的公司Logo、设备图片能少就少能用矢量就用矢量。4.2 数据刷新的冲突与线程问题如果同时有多个Timer在刷新同一批数据会偶发“调用线程无法访问此对象”异常。这是因为数据集在后台线程被修改UI线程绑定读取时冲突。解决办法有两个所有集合更新都通过Dispatcher.Invoke切换线程完全避免跨线程访问或者在后台线程维护一份不绑定的数据缓存UI线程用自己的UI时钟去读取缓存快照我比较推荐后者因为后台线程不用频繁切换UI上下文吞吐量高。比如每100ms用后台线程把最新数据写入一个Volatile字段UI线程每300ms读取一次并更新绑定。这样UI和数据采集频率解耦看板更流畅。实际测试中用Volatile缓冲方案200个点位每200ms刷新一次CPU占用能控制在8%以内。直接跨线程Invoke的方案同样点位至少15%起步。4.3 源码二次开发技巧与建议拿到一套电子看板源码不要急着改界面先把数据流转链路读通数据源 - Service - ViewModel - View。只要这条链路清晰加新功能就只是复制-粘贴-改名的事。二次开发中最常遇到的问题就是界面要加一块新看板区域。我的建议是新建对应区域的UserControl而不是往现成的Grid里塞控件新建独立ViewModel不把逻辑堆在MainViewModel里在右侧导航或TabControl中挂载新区域如果新区域需要新的数据源扩展IDataSource实现即可另外源码里一定要留好日志。哪怕简单到只写文本日志也能省下大量调试时间。我自己习惯用NLog分成Debug和Error两个级别看板发布后只输出Error日志避免日志文件暴涨。5. 从电子看板到智慧工厂数据平台的扩展思路很多项目做完了单机看板老板又会提需求数据能不能汇总到服务器能不能手机上查看这时候之前分层设计的好处就体现了。可以把数据采集服务DeviceDataService从看板程序里拆出去单独跑成一个Windows服务或托管在IIS里它负责把采集到的数据写入消息队列比如RabbitMQ或Kafka如果数据规模很大。看板端只订阅消息队列里的数据不再是直接连PLC这样看板崩溃不影响数据采集。再往后可以引入时序数据库保存历史数据用Web API供移动端查询。WPF看板变成整个智慧工厂数据平台的展示层之一。整个升级不需要推翻重写只要调整数据接入层和服务边界。还有一点值得扩展的是预测性维护。在采集数据的同时记录设备电流、震动、温度等信号利用简单阈值或机器学习模型预测设备故障。看板上再增加一个“设备健康度”模块这会让你的看板不仅是展示工具更是车间管理的辅助决策工具。最后说点实在的说实话电子看板的技术难度不算高真正难的是对工厂业务的理解和对细节的把控。早些年我吃过亏看到底稿没理清就去写代码结果看板做出来没人用因为数据不对。后来我养成了一个习惯开工前先在车间盯两天产线访谈一下班组长问他们每天最关心哪三个数字。这三个数字就是看板的核心。源码本身是死的但基于源码的改造能力是活的。学着把数据接入层抽象好把ViewModel逻辑写干净遇到任何新需求都不会慌。希望这篇文章里的思路能给你省点时间少走点弯路。如果你正好在折腾C# WPF看板欢迎按这个框架试一遍再回来对比一下踩坑数量我相信你会回来谢我。
