1. 先把场景说清楚晶圆搬移上位机到底在解决什么问题1.1 半导体炉管设备里的“搬移”是什么我做这个项目的背景是半导体热处理类设备晶圆在工艺过程中需要进入炉体完成氧化、退火、外延等工序而炉体内的温区动辄上千度人不可能靠手去操作于是就有了“搬移系统”这个概念。标题里提到的“晶圆与石墨岛”在行业内其实对应两类物料一类是真正的硅晶圆直径从2英寸到8英寸甚至12英寸都有另一类是石墨岛也就是石墨托盘或石墨舟。石墨岛本身是承载晶圆的载体很多外延炉、碳化硅晶体生长设备里晶圆不是直接裸露在机械手上的而是放在石墨岛里一起转运这样既保护了晶圆也方便机械手抓取。一个典型的运行场景是这样的自动上料机构把载有晶圆的石墨岛送入装载台上位机系统接收到启动信号后协调机械手从装载位取料经过视觉定位或机械定位校准再送入炉口工位最后退出炉体并把料送回卸载位。整个过程看起来只是“取-放”两个动作但牵扯到多轴运动、真空拾取、位置校验、炉门联锁、MES数据回传等一整套逻辑任何一个环节卡住整批晶圆都可能报废。1.2 上位机 vs PLC控制边界怎么划分很多刚入行的朋友会有个疑问“运动控制和信号采集明明用PLC就能做为什么还要搞一套上位机”我的回答是PLC负责“实时控制”上位机负责“流程编排、状态监控、数据追溯和人机交互”。在这个项目里PLC和伺服/机械手直接打交道轴的运动速度、加速度、当前位置和报警全部由PLC实时处理这部分交给上位机做反而危险。但工艺流程是经常变的今天跑三温区工艺明天跑五段恒温工艺Recipe工艺配方怎么编辑、步骤顺序怎么调整、操作员权限怎么管理这些用PLC的触摸屏做起来非常痛苦。上位机的价值就是把“工艺流程”从PLC的梯形图里抽离出来变成操作员可编辑、可保存、可追溯的配置数据。另外现代半导体产线基本都要接MES或EAP系统上位机作为数据中继把设备状态、批次信息、工艺数据往上送。PLC走工业总线上位机走以太网和DB/TCP两边各管各的我再通过DB块做数据握手职责边界非常清晰。2. 技术选型C# WPF 为什么是当前合理的选择2.1 主流上位机方案横向对比做上位机不止C#一种路我实际评估过的方案包括方案优势劣势适用场景C# WinForms上手快、控件成熟UI美化差、复杂状态界面难维护简单IO监控、小型控制台项目C# WPF数据绑定强、UI灵活、MVVM清晰上手曲线稍陡、渲染性能需优化本类多工位状态机配方编辑的中型项目C Qt性能强、跨平台开发效率和界面迭代慢强实时毫秒级视觉或运动控制LabVIEW硬件驱动封装好流程化编程难维护、界面不够现代实验室仪器控制、快速原型Python PyQt/Tkinter开发快部署麻烦、工业实时性弱调试工具、数据分析辅助我在这个项目里选C# WPF不是因为别的方案不行而是因为系统的核心矛盾是“业务逻辑复杂、界面状态多、产线扩展快”这些正好是WPF的强项。拿界面状态来举例一台设备可能有装载台、缓存工位、机械手、炉口、冷却位等多个工位每个工位又有空闲、运行中、完成、报警、急停等状态窗口。WinForms做这种多状态界面通常要靠多个Label/TextBlock叠加加后台代码控制Visibility代码维护到后面自己都分不清哪个控件在哪个状态下亮。WPF的DataTrigger和Style可以让我把“状态到外观”的映射完全写在XAML里业务代码只管修改ViewModel属性就行。2.2 WPF 这套组合的技术底气光有界面灵活还不够工业上位机还要解决三个现实问题通讯、数据库、第三方组件集成。通讯西门子PLC可以用S7.netplus或Sharp7走S7协议也可以用OPC UA推荐C#的官方OPC UA库成熟度已经很高。三菱/基恩士PLC也有对应的C#库。机械手则一般走TCP/IP或串口ModbusC#对这些支持非常完善。数据库批次追溯、报警历史、Recipe数据通常用SQLite起步产线集成后换SQL Server或MySQL都很容易。EF Core或者Dapper都是顺手的事。第三方组件WPF生态里HandyControl、MaterialDesignInXaml等开源控件库已经很成熟。工业场景用的比较多的是HandyControl它对数据表格、弹窗、加载动画、通知都有现成封装比从零写控件省太多时间。另外我提一下Visual Studio .NET 8的现代工具链编译速度、内存占用和调试体验都比老Framework时代好很多。半导体设备的上位机很多跑在工控机Windows 10/11 IoT上部署.NET 8的框架依赖没问题单文件发布也方便。2.3 MVVM 与上位机场景的适配有人把MVVM单纯理解为“界面层不用写代码”其实在上位机场景里MVVM最核心的价值是“状态可预测、可测试、可复现”。我的做法是View层只负责绑定的呈现ViewModel层负责业务流程的编排Model/Service层负责PLC通讯、机械手指令、数据库读写。生产过程中“机械手正在取片”“炉门正在关闭”“真空拾取异常”“等待MES确认”这些状态就表现为ViewModel里的一个个枚举属性或集合属性界面的按钮亮灭、颜色切换、日志滚动全部由数据驱动。这样做还有个额外的好处我可以在完全不接硬件的情况下用一个模拟服务把PLC和机械手的行为虚拟化把整个状态机跑一遍提前发现流程漏洞。后面我会专门讲这个“半实物仿真”的做法对调试排错帮助极大。3. 系统架构与关键通讯链路设计3.1 分层架构UI、ViewModel、服务、驱动我最终采用的工程结构如下Solution ├─ App.UI // WPF项目Views, Styles, Converters ├─ App.ViewModels // ViewModel层设备状态、Recipe管理、任务调度 ├─ App.Services // 领域服务流程调度、报警管理、日志、数据库 ├─ App.Drivers // 驱动层PLC驱动、机械手驱动、MES通讯 └─ App.Models // 数据模型Recipe、Batch、Alarm、配置文件Drivers层是整个系统的地基。我在这层封装了IPlcDriver接口包含Connect、Disconnect、Read、Write、Heartbeat等操作这样无论是西门子S7-1200还是三菱FX5U上层都不用动。机械手同理封装成IRobotDriver提供MoveTo、PickFrom、PlaceTo、Reset等指令方法。Services层是业务核心里面跑一个ProcessScheduler服务负责按Recipe步骤队列逐条下发动作。队列执行完一个步骤后从PLC读取执行完成信号确认无误后再执行下一步。ViewModels层不直接碰Driver而是通过Service的事件回调获得状态变化。举例来说RobotViewModel订阅ProcessScheduler的每一步状态事件更新自己的CurrentStep、OverallProgress等属性界面上的进度条和状态灯就自动跟着走了。这种分层设计让“换一个PLC型号”只改Driver层让“换一套工艺流程”只改Services层让“重新画一套界面”只改UI层互不干扰。3.2 PLC 与机械手通讯怎么搭我用的是西门子S7-1500 PLC通讯方案一开始就选了OPC UA而不是直接用S7协议要知道西门子1500系列原生支持OPC UA服务器C#里用官方OPCFoundation.NetStandard库就能连上不需要额外授权和中间件。OPC UA最让我满意的是它自带“地址空间”的概念PLC里的DB变量可以按层级暴露成类似文件夹的结构比S7协议里裸的DB号偏移量直观得多。比如PLC → Equipment → RobotAxis → X_Position (Double) X_Status (Int16) Home_Complete (Boolean) ProcessChamber → Door_Opened (Boolean) Chamber_Temp (Float)另外OPC UA的Subscription机制也特别好用。上位机订阅一批变量后只有当PLC端变量变化值超过设定阈值时才会上报极大减少了网络压力和UI刷新开销。这个对WPF界面很友好我不用写一大堆定时轮询代码数据是以“事件”的形式推上来的。不过实际项目中我并没有完全放弃轮询的方式——针对一些重要信号比如急停、门锁我会额外开一个50ms周期的轮询线程去读并做“连续读两次同样状态才认为状态稳定”的去抖处理避免通讯延迟或偶发丢失导致误判。关键是轮询和订阅并非二选一重要信号用轮询兜底量大的过程数据用订阅推送这个组合策略在产线上验证很稳。机械手这块我用的是TCP/IP协议。机械手本身已经内置了运动控制功能我只需要按它的协议规范生成指令字符串发过去例如指令格式如下MOVE#ARM1#PICK#LOAD_POS#SPEED50#VACON每条指令发出后机械手会返回ACKACK里带有执行结果token。上位机收到ACK后再继续等待机械手“动作完成”回调信号。这里特别要注意的一点是不要以ACK当作动作结束ACK只是“我收到了指令”动作真正完成还要靠PLC端的位置反馈传感器或机械手的状态寄存器。我一开始就是以为收到ACK就万事大吉导致早产了一次动作切换后来修正为双状态确认ACK IoSignal才稳定下来。4. 搬移流程的状态机设计与核心代码结构4.1 从取片到入炉一个完整任务的拆解一个完整的“从装载台取晶圆并放入炉内”的任务拆解下来大约有十多个步骤。我在Scheduler里用状态机来管理而不是简单的if-else顺序因为任何一步都可能出现超时、报警、人工干预状态机能非常清晰地表达这些异常分支。核心状态枚举大致长这样public enum ProcessState { Idle, LoadPort_TakeReady, Robot_MoveToLoadPos, Robot_VacuumOn, Robot_ConfirmPicked, Robot_MoveToChamberPos, Chamber_DoorOpenReady, Robot_PlaceIntoChamber, Robot_VacuumOff, Robot_Retract, Chamber_DoorClose, ProcessStep_Complete, Alarm_Handling }每个状态都对应一个处理函数下面是简化版的状态流转逻辑public async Task RunProcessStepAsync(ProcessState currentState, CancellationToken token) { switch (currentState) { case ProcessState.LoadPort_TakeReady: // 询问PLC装载台是否就绪真空传感器是否正常 bool loadPortReady await _plc.ReadBoolAsync(DB_Material.Handshake.LoadPortReady, token); if (!loadPortReady) throw new ProcessException(装载台未就绪, ErrorCode.LoadPortNotReady); _context.CurrentState ProcessState.Robot_MoveToLoadPos; break; case ProcessState.Robot_MoveToLoadPos: // 下发机械手到取料位指令等待ACK IO信号双确认 await _robot.MoveToAsync(LOAD_POS, speed: 50, token); bool arrived await _plc.WaitForSignalAsync(DB_Material.Feedback.ArmAtLoadPos, timeout: 5000, token); if (!arrived) throw new ProcessException(机械手到达取料位超时, ErrorCode.RobotMoveTimeout); _context.CurrentState ProcessState.Robot_VacuumOn; break; // ... 其他步骤类似 } }你可能会问为什么不用并行任务或直接用事件循环因为半导体工艺设备的特点是“步骤严格串行、先后顺序绝对不可乱”状态机天然符合这个约束条件。而且出问题时我可以把当前状态直接显示到界面上操作员和售后一眼就能看出设备卡在哪个环节。4.2 超时、重试和安全互锁状态机里另一个不可或缺的东西是超时看门狗。机械手移动正常情况下5秒内完成我设置超时时间10秒炉门关闭3秒内完成超时8秒真空拾取感应器0.5秒内触发超时2秒。每个步骤都有独立超时阈值超时后自动进入Alarm流程并根据不同的报警码决定是停机等待人工还是可以重试两次。重试逻辑也不是简单的“报错了自动再来一次”我加了重试次数限制和逐步加重条件第一次失败记录报警日志UI弹窗通知等待2秒后重试第二次失败提示“疑似机械故障”进入暂停状态禁止自动重试同步记录动作执行时PLC关键位状态快照方便售后远程分析。安全互锁方面我给自己定了一个原则“上位机可以决定下一步做什么但决定不了执行机构能不能动”——具体的电机使能、炉门开锁、真空阀允许等危险动作永远由PLC硬件互锁条件决定。上位机只是向PLC发送“请求”如果PLC检测到门未关、气压不足、轴限位触发就会拒绝执行并返回错误码。这个算是半导体设备行业比较基础的原则但也是最容易被上位机开发人员忽视的。一旦忽视了万一门开着机械手就进去了轻则撞坏机构重则晶圆碎片污染整台设备。4.3 关键代码结构与写法完整的业务代码量很大这里我专门展示一下调度器的核心骨架这是整个上位机最能体现“实战”价值的代码设计public class ProcessScheduler : IDisposable { private readonly IPlcDriver _plc; private readonly IRobotDriver _robot; private readonly ILogger _logger; private readonly RecipeRepository _recipeRepo; private ProcessState _currentState; private CancellationTokenSource _cts; public event EventHandlerProcessState StateChanged; public event EventHandlerProcessError ProcessFailed; public async Task StartBatchAsync(int batchId) { _cts new CancellationTokenSource(); var recipe await _recipeRepo.GetByBatchIdAsync(batchId); try { // 1. 检查设备条件 await VerifyEquipmentReadyAsync(_cts.Token); // 2. 按Recipe步骤循环执行 foreach (var step in recipe.Steps) { _currentState step.StartState; StateChanged?.Invoke(this, _currentState); await ExecuteStepWithWatchdogAsync(step, _cts.Token); // 每步完成写追溯数据 await _traceRepo.SaveStepRecordAsync(batchId, step); } // 3. 整批结束 _currentState ProcessState.Idle; StateChanged?.Invoke(this, _currentState); } catch (OperationCanceledException) { _logger.Warn(批次被手动取消当前已执行步骤数: _executedStepCount); } catch (ProcessException ex) { _logger.Error(ex, 流程处理异常); ProcessFailed?.Invoke(this, new ProcessError(ex.ErrorCode, ex.Message)); await EnterAlarmStateAsync(ex); } } public void RequestPause() { _cts?.Cancel(); } }这里用CancellationToken贯穿整个流程好处是操作员随时可以“暂停”或“急停”不需要像老式WinForms代码那样靠一个全局bool标志变量去判断。而且CancellationToken能传递到PLC读取、机械手指令、数据库写入所有异步操作里紧急情况下它可以立刻中断阻塞中的调用。另外每次步骤完成我都立即写入追溯数据而不是攒到最后批量写。因为半导体行业对数据追查非常严格万一设备中途断电或者报警停机已完成的步骤记录必须已经在数据库里了否则批次的追溯链就断了。5. 调试和量产阶段踩过的坑5.1 C# 调用原生 DLL 的 Access Violation 问题这个坑我必须单独拿出来讲因为它真的很折磨人。项目里我用了某个视觉定位算法库厂商只提供了C动态库DLL需要P/Invoke调用。程序刚开始运行一切正常跑几十次也没问题但偶尔会直接抛出一个异常进程直接崩溃日志都来不及写。报错信息是Access Violation c0000005典型的非托管内存访问违规。排查过程我走了不少弯路一开始以为是多线程并发调用同一个DLL导致于是加锁、串行化调用问题依旧后来以为是Delegate在GC回收后导致回调地址失效于是改成静态方法、用GCHandle.Alloc固定委托依然会偶发崩溃再后来抓dump文件分析发现崩溃点在DLL内部的内存拷贝阶段初步怀疑是传入的byte数组缓冲区长度与DLL预期不符。最后定位到的根因是DLL内部的C代码按固定大小例如2048*2048*4字节写入输出缓冲区而我在C#端传入的byte数组是用图像实际分辨率的容量比如1024*1024*4字节来创建的。正常情况下DLL会限制写入大小但在某些异常图像尺寸下C端的保护逻辑没生效越界写到了C#托管堆之外的内存地址。规避方案总结下来有三条与接口方确认输出缓冲区的最大长度C#端一律按最大长度创建并在P/Invoke签名中用SizeParamIndex标明容量参数关键的非托管调用放到独立进程中执行用本地服务或后台进程包装即使崩溃也不影响主UI进程和PLC通讯在Debug模式下开启非托管代码调试把EnableNativeCodeDebugging打开配合WinDbg查看崩溃时的调用栈。后来我把那个视觉库的调用改成独立进程通信模式主程序和DLL之间走命名管道主进程稳如老狗。代价是进程间通信有几百微秒延迟但视觉定位本身不是高频调用这个延迟完全可接受。5.2 PLC 通讯闪断与重连的坑OPC UA虽然稳但在现场总线干扰强或工控机网卡休眠时偶发断连还是会出现的。我早期版本的代码里通讯断开后只是弹了个报警并没有自动重连结果有一次夜班操作员没注意到报警设备一直处于“假死”状态第二天良率报表一片飘红。我后来给PLC驱动加了一套“断线自动恢复”机制public async Task KeepAliveLoopAsync(CancellationToken token) { while (!token.IsCancellationRequested) { try { if (_session null || _session.State ! OpcUaSessionState.Active) { _logger.Warn(OPC UA 会话异常尝试重新建立连接...); await ConnectAsync(token); await _plc.WriteAsync(DB_Comm.ReconnectedCount, _reconnectCount, token); } } catch (Exception ex) { _logger.Error(ex, 重连会话失败10秒后再次尝试); } await Task.Delay(TimeSpan.FromSeconds(10), token); } }重连后要做两件事最容易被忽略一是重连后必须把上位机内部缓存的所有寄存器状态重新从PLC拉一遍二是以重连事件作为边界记录日志并通知操作员。如果不重新拉状态上位机里显示的可能还是断线前的旧状态等信号真正变化时无法判断是真的变化还是原本就变化了这对状态机决策来说很危险。5.3 WPF 跨线程访问 UI 与界面卡顿WPF界面开发中“跨线程访问UI”是新手必踩的坑。我项目里从OPC UA回调事件中直接更新界面绑定的属性结果报调用线程无法访问此对象因为另一个线程 owns 该对象后来规范做法是这样// 传统方式在事件回调里调度到UI线程 Application.Current.Dispatcher.Invoke(() { ViewModel.CurrentTemp temperature; }); // 更推荐的方式利用WPF的绑定自动同步特性 // 只要属性变化事件在UI线程触发绑定就能自动刷新 // 所以尽量在ViewModel中用AsyncRelayCommand包装流程操作我的经验是能不进UI线程就尽量不进。像温度曲线采集这种高频数据我在后台线程里先写入一个固定容量的ConcurrentQueue然后每200ms批量推一次到UI线程这样UI不会因为高频刷新而过载。同时在绑定大集合数据时用BlockingCollection 批量同步替代逐个添加ObservableCollection否则每加一条数据UI就刷一次操作会卡到你怀疑人生。另外我强烈建议用Binding的IsAsync属性处理低速属性比如从数据库加载的操作员列表、历史配方列表或者用Task.Run加载完再赋值不然界面启动加载配方时好几秒的白屏能劝退所有操作员。6. 界面和交互细节让操作员用得更顺手6.1 主操作界面的布局思路工业界面和互联网界面完全两个思路。互联网产品讲究“引导点击”工业界面讲究“一眼确认状态、最短路径操作、无法误触”。我的主界面分成四个区域左上部设备总览图。用Canvas或Grid画一个简化的设备俯视图各个工位用带DataTrigger的矩形/圆形表示运行中变绿、空闲变灰、报警变红、急停变闪烁操作员扫一眼就知道设备当前全局状态左下部实时报警列表。每次报警都带上升时间、确认状态、报警码、报警描述操作员可以根据报警码翻看设备手册或直接在界面上查看处理建议右上部当前批次执行信息。包括当前Recipe名称、当前步骤序号、总步骤数、已用时间、晶圆批次号右下部操作按钮区。包含“启动批次”“暂停”“复位”“单步执行”等操作按钮。按钮的可用性由ViewModel状态属性控制比如未报警时“复位”按钮禁用暂停时“暂停”按钮禁用从根源上防止误操作。操作员每次点击关键按钮界面都需要弹出“请输入操作员工号”的确认框并且记录到操作日志里。刚开始有些客户觉得麻烦但实际的经历证明了这一点有一次就是因为误碰触摸屏“启动”按钮机械手在没准备好时就开始动作虽然硬件互锁挡住了但还是产生了报警。有了确认框后误触概率大大降低。6.2 实时刷新和绑定性能注意事项有几个WPF性能问题我在这个项目里遇到并解决了值得记录高频集合刷新如果用ObservableCollectionT装实时数据比如炉温曲线点每次Add都会触发INotifyPropertyChangedUI线程压力巨大。我的方案是把采集线程攒一批点每200msBeginBatchUpdate批量更新一次而不是每秒几十次的逐点刷新。DataGrid行展开问题DataGrid如果需要显示“一个工序包含多个子步骤”的层级结构新手往往会用RowDetail或GroupStyle结果出现闪烁和滚动条跳动。我后来改用DataGridTemplateColumn嵌套ItemsControl的方式把子步骤用缩进列表显示在一格内既稳定又不丢层级关系。大图资源设备总览图如果是一张高分辨率PNG界面首次加载会卡。我用BitmapImage的DecodePixelWidth限制解码尺寸不直接加载原图显示速度提升十分明显。异步命令启动批次这种长耗时操作如果直接在Click事件里做界面会假死。我所有操作按钮都用AsyncRelayCommand包装配合IsRunning控制按钮的Loading状态。我顺便提一下WPF里“理想”的封装习惯不要在Window事件里直接写业务代码把按钮绑定到Command把双击操作封装成InputBinding。这样后续换界面皮肤或增加远程控制入口比如Web端或者IPC上位机时业务层完全不用动。6.3 操作权限、日志与远程协助半导体设备对权限区分要求很高。我用了角色模型操作员可以启停批次、查看报警、查看配方工艺工程师可以编辑Recipe、修改参数、手动单步操作设备管理员/售后可以修改PLC IP、校准传感器、清除历史记录。WPF这边我用HandyControl的PasswordBox做登录对话框登录成功后把当前用户角色注入到进程级单例UserContextViewModel命令里用CanExecute做权限控制。这样“按钮能不能点”的规则和业务逻辑剥离逻辑很干净。日志系统我采用“滚动文件 数据库双写”滚动文件NLog写文本日志按天滚动保留30天数据库关键事件启停、报警、Recipe修改、用户登录写入SQLite的EventLog表和RecipeChangeLog表。日志内容不是简单的字符串我会以结构化对象形式存储时间戳、操作员编号、设备工位、旧值、新值、操作类型。这样售后排查问题时直接SQL查询“一个月内Recipe修改记录”非常方便。7. 测试验收与交付心得7.1 半实物仿真的必要性和做法这个环节可能很多自行开发上位机的团队会忽略但我个人认为它甚至比写代码本身更能决定项目的成败。所谓“半实物仿真”就是在上位机还无法连接到真实PLC和机械手时用软件模拟一个PLC服务端按真实PLC的变量表、类型和时序行为来响应上位机的读写操作。我用OPC UA模拟服务器的方式实现在本地建一个模拟的UA服务器地址空间结构和真实PLC保持一致然后在后台用定时器自动修改某些变量比如模拟装载台就绪信号。这样做的直接收益非常大状态机代码可以在没有硬件的情况下跑通所有分支包括超时、报警、复位流程UI层开发至少提前两周启动界面调试不需要和机械调试抢时间机械和电气人员在现场总结时我可以在办公室并行测试上位机新版本的回归。我还用模拟器做了“压力测试”模拟机械手每次响应随机延迟1到5秒看调度器的超时处理是否会被误触发模拟PLC突然断连500ms看重连机制是否会自动恢复且不影响正在执行的步骤。这些都是真机上很难刻意复现的场景。7.2 验收指标与交付资料设备交付客户前的验收我和客户约定的指标大致是验收项指标备注连续运行稳定性168小时无宕机期间允许正常操作和换批单步执行成功率≥ 99.5%以500次连续动作为样本故障恢复时间≤ 30秒非硬件故障程序自动恢复报警响应准确性100% 呈报所有硬件报警必须在1秒内上抛到UI数据追溯完整性100% 批次可查每片晶圆对应完整工序记录交付资料这块除了常规的源代码、安装包、用户手册之外我强烈建议把“变量地址映射表”做成一个独立文档交付。这份文档是PLC DB变量与上位机变量名的对应关系后期无论是客户自己改PLC程序还是我们远程维护没有这份表基本寸步难行。我自己的一点交付体会这个项目从头到尾做了大半年最深的体会是上位机系统做得“能用”很容易做到“敢跑”很难。半导体的产线环境不是实验室设备一停就是几万块的损失所以上位机代码的健壮性比炫技重要一万倍。我现在回看这些代码很多地方写得不算漂亮但每一个超时判断、每一个重连策略、每一个权限控制背后都是实实在在踩过坑换来的。如果你也在做类似的上位机项目我的建议很简单先把状态机吃透再把通讯的重连机制做扎实最后再谈界面美化。层序对了项目大概率能稳。