1. 晶圆与石墨岛搬移这个上位机到底在做什么1.1 半导体工序里的“搬移”远没有想象中简单先把这个项目的前提讲清楚。半导体产线里晶圆从毛坯到成品要经历几十道工序搬移是贯穿全程的高频动作。很多时候外界以为搬移就是机械臂把晶圆从A点拿到B点但实际远不是这样。晶圆很薄、很脆、对洁净度和表面污染极度敏感单手拿取方式、接触材质、吸力大小、运动速度、停留位置稍有偏差轻则划伤重则碎片。石墨岛也就是行业内俗称的石墨舟、石墨治具是承载晶圆进入高温炉、外延炉等设备的载体本身也要求在特定温度区间内进行搬移而且石墨材质易掉粉、易脆断搬运动作必须极其克制。我当时做的这套系统就是用C#和WPF开发一套上位机负责控制整台半导体设备的晶圆与石墨岛搬移流程。设备本体不算复杂上料台、取放机械手、视觉对位模块、几个缓存工位以及一台负责执行动作的运动控制器。但真正跑起来之后才发现问题全部集中在上位机这一层——它要协调所有硬件、解析所有反馈、处理所有异常还要把每一次搬移动作的数据完整记录下来。1.2 上位机在整台设备里的位置这台设备的控制架构大概是三层上层是MES或人工下发指令中间是上位机下层是PLC、运动控制卡、真空电磁阀、气缸传感器、视觉相机等执行设备。上位机在这里相当于大脑和翻译官接收MES的任务单解析成一步步机械动作指令发给运动控制卡等待动作完成后读取传感器和视觉结果判断是否到位再把执行结果汇总上报MES。很多做小程序、Web后台的朋友第一次接触工控时容易犯一个错误以为上位机就是简单的“串口发指令显示状态”。真实项目里上位机要处理的是一整套状态流转。以晶圆上料搬移为例完整流程是这样的操作员扫码绑定晶圆批次上位机从MES获取工艺配方机械手从上料盒取出一片晶圆先经过预对准或视觉拍照确认位置和角度视觉系统计算出晶圆在机械手上的实际偏移量上位机把补偿值写入运动控制卡机械手移动到石墨岛的工艺槽位下降到指定高度破真空放片真空检测确认晶圆已放好机械手退回原点然后读取下一步指令。任何一个环节状态判断失败比如真空值不达标、视觉对位超差、气缸未到位上位机都要立刻进暂停或报警流程绝不能带病运行。这套逻辑一旦想清楚后续写代码才不会被零散的串口消息带偏。1.3 石墨岛搬移流程里最揪心的几个细节石墨岛的搬移和晶圆搬移还不一样。石墨岛通常是整个承载结构一次搬移的重量、体积都更大。我在现场总结出三个必须优先解决的问题一是槽位映射关系。石墨岛上有几十个槽位每个槽位对应一个横向或纵向坐标配方里定义的是槽位号实际执行时上位机要换算成机械坐标。如果配方中槽位间距和实际硬件有偏差后处理的视觉确认就非常关键。二是石墨岛的冷却状态。刚从高温炉出来的石墨岛表面温度可能超过几百度机械手还没靠近时红外传感器温度高企上位机界面必须实时显示温度状态并锁死搬移动作直到温度降到工艺允许范围。三是防呆校验。石墨岛方向放反、槽位被占用、晶圆重叠这类低级错误在传统人工产线上可能只是小麻烦在自动化产线上会导致直接碎片。所以我在每个关键动作前面都加了三层校验传感器在位检测、视觉/T槽号识别、动作互锁条件判断。2. 技术选型复盘C# WPF 在工控场景里的取舍2.1 为什么不是LabVIEW、WinForms或Qt做上位机之前团队内部其实争论过一轮。LabVIEW在测试测量领域很强但做复杂业务流程、对接MES数据库、写自定义算法时程序员不太愿意碰Qt跨平台能力强、界面性能好但C开发效率摆在那里招人成本和沟通成本不低WinForms开发速度快可界面一旦复杂起来控件布局、数据绑定、自定义视觉效果都很痛苦。最后敲定C# WPF最核心的原因有三点C#开发效率高尤其是在异步通信、并发处理、日志、数据库访问这些工控上位机天天要用的场景语法层面的支持非常舒服设备厂商的SDK绝大多数提供C/C#接口比如运动控制卡、相机、扫码枪、IO模块用C#调SDK往往是最短的路径WPF的XAML界面描述能力确实强生产现场需要清晰展示设备状态、报警、配方、实时曲线用WPF能做得又快又专业。这里说句实在话上位机项目的难点从来不在语言本身而在“能否快速集成各种硬件SDK、能否稳定处理异常”。C#在这条路上比我预想中顺很多。2.2 基于设备SDK生态的选型逻辑工控设备的SDK生态很关键。运动控制卡大多提供DLL动态库里面是一堆C接口比如初始化、回零、绝对运动、读取IO状态。用C#封装这类DLL是常规操作核心是写好DllImport声明把不安全的指针参数转换成安全类型。举个例子某款运动控制卡的绝对移动函数可能长这样[DllImport(MotionCard.dll, CallingConvention CallingConvention.StdCall)] public static extern int AMC_AbsMove(int axis, double position, double velocity, double accel);用的时候只需要包装一层public async Task MoveAxisAsync(int axis, double targetPos, double velocity, double accel) { int result AMC_AbsMove(axis, targetPos, velocity, accel); if (result ! 0) { throw new MotionException($轴{axis}移动作失败错误码{result}); } }我当时的经验是所有的SDK调用最终都封装成异步Task接口不让UI线程直接卡在SDK调用上。后面接视觉、接MES时这套封装模式直接复用省了很多事。2.3 WPF带来的红利和实时性陷阱WPF的数据绑定和MVVM模式用在工控上位机上确实舒服。但舒服不等于可以为所欲为。很多第一次用WPF写上位机的人最容易踩一个坑把设备状态集合直接绑定到List上后台线程频繁更新数据结果界面要么卡死要么刷新错乱。这里的基本功是后台线程与UI线程之间的交互必须通过Dispatcher或者使用支持跨线程通知的集合比如ObservableCollection。但ObservableCollection频繁增删也有性能问题设备状态变化频率高的时候我一般不会直接绑集合而是在后台维护一个状态快照用定时器以200毫秒到500毫秒的间隔刷新一次UI。这样既保证实时性又不会让WPF的布局引擎被大量通知打垮。另外WPF的实时曲线用第三方控件也需要注意刷新频率。我用过的方案是把曲线数据放到环形缓冲里绘图控件只读固定长度的最新数据实测下来千点级别的曲线50毫秒刷新一帧完全没问题。2.4 环境和依赖.NET版本与关键库项目我选的是.NET Framework 4.7.2因为部分设备SDK只提供了.NET Framework版本的运行库用.NET 6/8时通过兼容模式也能跑但要做额外的兼容性测试。如果是从零开始的新项目且设备SDK比较新我建议直接用.NET 6以上部署更轻、性能更好、跨平台的可能性也留着。常用库方面我推荐这几类MVVM框架社区Toolkit.Mvvm轻量且官方维护UI控件库HandyControl工控界面常用的按钮、卡片、抽屉、通知都能覆盖日志NLog或Serilog一定要带滚动文件和大小限制数据库SQLite或本地缓存产线环境一般没有条件给你挂一套完整的数据库服务。3. 核心模块拆解通信、运动、视觉、状态机怎么揉在一起3.1 通信层与下位机交互的落地细节上位机和运动控制器之间我这边用的是TCP/IP。TCP在工控里很常见但有一个经典问题粘包和半包。设备发过来的数据长度不固定接收缓冲区里可能一次来了多条报文也可能一条报文分两次到达。我是在接收线程里维护一个缓冲区每次先找报文头校验位帧长够了就截取一个完整报文解析解析完继续找下一条private readonly byte[] _buffer new byte[8192]; private int _bufferLength; private void OnDataReceived(byte[] data, int size) { Array.Copy(data, 0, _buffer, _bufferLength, size); _bufferLength size; int offset 0; while (_bufferLength - offset HeaderLength) { if (_buffer[offset] ! 0xAA || _buffer[offset 1] ! 0x55) { offset; continue; } int frameLength (_buffer[offset 2] 8) | _buffer[offset 3]; if (_bufferLength - offset HeaderLength frameLength) { break; } byte[] frame new byte[frameLength]; Array.Copy(_buffer, offset HeaderLength, frame, 0, frameLength); ProcessFrame(frame); offset HeaderLength frameLength; } _bufferLength - offset; Array.Copy(_buffer, offset, _buffer, 0, _bufferLength); }这个解析逻辑看起来简单但稳定性非常关键。实际产线上设备主控偶尔会复位上位机必须做断线重连和心跳检测。心跳我采用2秒一次的标准指令超过10秒没有回复就判定通信异常进入停机报警流程。这个时间不能太短现场总线负载高的时候偶发延迟是正常的。3.2 运动控制指令封装轴、IO与异常恢复搬移设备的运动控制轴一般不多常见配置是X轴代表水平横移Z轴代表升降再加一个旋转轴做晶圆角度修正另外可能有几路气缸辅助定位。每个轴都要做正负限位、原点信号、Home动作、使能状态管理我在代码里用一个Axis类把每个轴的状态封装起来。搬移过程里的运动不是简单的绝对定位。晶圆取放要求末端速度曲线平滑突然启动或急停会导致晶圆在吸嘴上滑动。运动控制卡一般支持梯形或S形加减速在配方里给每个运动阶段配置速度、加速度、减速度。比如提升动作可以快一点但放片动作最后5毫米要低速缓降。IO互锁也是重点。放片之前必须确认对应槽位没有晶圆遮挡真空开启后必须读到真空度达到保持阈值。这类条件的判断我是放到一个动作方法里逐步执行每一步都等反馈超时任何一步不满足就抛异常进报警。3.3 视觉对位与坐标补偿的计算逻辑视觉模块在这套设备里负责两件事一是确认机械手上晶圆的位置角度二是确认石墨岛槽位号及当前槽位状态。晶圆被吸起时位置不会每次完全一致可能偏移零点几毫米角度偏移零点几度如果不补偿直接放片靠近槽位时就会擦碰划伤。视觉系统给上位机返回的是像素坐标系里的偏差值比如晶圆中心坐标和角度。上位机要做的是把像素偏差换算成机械坐标系里的补偿量。最简单的方案是两点标定在机械手可移动的某个位置放下一个标定片让视觉识别出特征点像素坐标控制机械手移动到一个已知机械坐标再识别一次得到像素坐标和机械坐标的映射关系最小二乘拟合出一个仿射变换矩阵。拿到矩阵后视觉返回的每个像素坐标点都能转成机械补偿量。角度补偿还要处理旋转中心问题机械手旋转轴的旋转中心与晶圆实际中心不完全重合时必须按旋转中心的机械坐标做角度换算。公式大概是X Xc (X - Xc) * cosθ - (Y - Yc) * sinθ Y Yc (X - Xc) * sinθ (Y - Yc) * cosθ其中(Xc, Yc)是旋转中心机械坐标θ是视觉识别的角度偏差(X, Y)是视觉系统给出的晶圆中心计算出(X, Y)才是补偿后的实际放片坐标。这套逻辑调试的时候看不出来一旦设备跑高速生产效果立竿见影。3.4 状态机与界面刷新的设计搬移流程不是一段顺序代码跑到底中间充满分支和异常。我的做法是把整台设备定义成一个主工作状态机包括空闲、取片、视觉对位、搬运、放片、回零、报警、暂停这些状态。任何外部输入比如扫码、按钮、MES指令都通过状态机进行状态转移。上位机界面我分成了四大区域顶部是设备运行状态和报警灯中间左边是工位布局图中间右边是当前任务和配方信息底部是实时日志和关键坐标。视觉相机的实时画面放在独立窗口方便现场调试。界面更新全部走状态机的OnPropertyChanged和消息推送避免业务代码里到处撒Dispatcher后期维护会非常头疼。3.5 配方与库位管理配方是半导体设备绕不开的东西。不同批次晶圆的尺寸、厚度、工艺温度不同搬移参数也不一样。我把配方拆成两层基础配方定义每类晶圆和石墨岛的动作参数工艺配方定义当前批次用的基础配方编号和MES下发的批次号。库位管理则是记录石墨岛上每个槽位的状态空闲、有片、扶正失败、禁用等。现场操作员可能手动放取晶圆上位机必须能实时同步库位状态否则自动搬移时很容易发生放片叠片事故。我实现的方式是在每次动作完成后都强制刷新库位表而不是只在程序启动时读取一次。4. 现场踩坑实录这些问题只在半导体设备上才会遇到4.1 界面卡顿不是WPF慢是线程用错了项目上线第一周就遇到一个典型问题设备连续跑半小时后触摸屏点击反应明显迟钝。查下来不是内存泄漏而是日志显示控件绑定的ObservableCollection里堆积了大量数据UI线程每次收到集合变更通知都要重新计算布局和渲染。解决办法是把日志显示改成虚拟化列表同时限制最大显示行数超过1000行自动裁剪。设备状态绑定的数据不再逐个通知而是500毫秒一次统一推送快照。改完以后连续运行几天界面流畅度都没问题。这里给一个很实际的建议工控上位机里的所有UI刷新都考虑“最终一致性”不需要追求每次状态变化都立刻反映到界面只要保证操作员看到的画面延迟在可接受范围内稳定性远大于花哨的实时性。4.2 TCP粘包拆包与超时重试前面写过拆包逻辑但真正在现场遇到的问题比预想更多。某次设备主控偶尔会连续发送两条相同指令导致上位机执行了两次放片动作虽然真空检测拦住了第二次但已经很危险。排查下来是主控程序在通信繁忙时重发了数据帧而上位机没有做帧序号去重。从那之后我在每个协议包里增加了自增的报文序号上位机记录最近处理过的序号重复序号直接丢弃。同时把动作执行与通信解析解耦通信层只负责把完整指令放进队列动作执行模块从队列中逐个取指令并判断当前状态是否允许执行而不是收到什么就立刻做什么。4.3 晶圆在吸嘴上“微小滑动”引发的坐标漂移设备跑了一段时间后偶尔出现放片位置偏差变大但视觉系统每次对位看起来都正常。后来在机台旁边盯了一上午才发现问题吸嘴使用久了表面硅胶圈老化晶圆被吸起后受加速运动影响发生微小滑动视觉拍照时看起来还在中心实际放片时已经偏了。这类问题视觉系统解决不了只能从硬件上找原因。排查手段是让机械手做一次高速往复运动后静止再拍照对比晶圆中心是否变化。如果漂移超过阈值说明吸嘴密封或真空保持有问题需要更换吸嘴或加大真空压力。这也让我意识到上位机里要对每次放片后的真空检测数据做趋势记录提前发现硬件劣化。4.4 石墨岛余温带来的热胀变形石墨岛从高温工艺腔室出来后温度即便降到允许操作的范围内也依然存在局部残余热量。石墨和硅材料的热膨胀系数不同导致石墨岛槽位间距和标准值有偏差视觉如果只识别石墨岛边缘确认出来的槽位中心位置在实际高温状态下可能偏出允许范围。处理方式是把视觉识别和温度补偿结合起来上位机从温度传感器读取石墨岛当前温度段查询该温度段对应的热膨胀补偿表在视觉识别出的基础坐标上叠加补偿值。补偿表不需要很密温度每50摄氏度取一组标定值线性插值即可。这个细节如果不做靠机械硬压定位迟早会出事。4.5 光源反光对视觉识别的影响晶圆表面本身是光洁的特别是经过抛光工序的晶圆在环形光源下会出现反射亮斑影响视觉定位精度。当时视觉工程师反复调了曝光时间和光源亮度效果都不稳定。后来改成了低角度环形光源加偏振片反射噪声才被压下去。上位机和视觉之间也要约定好通信握手视觉开始拍照前上位机保证机械手静止并等待稳定时间视觉返回结果后上位机在超时时间内没有收到有效结果就进入报警而不是一直傻等。这套机制保证了异常场景下设备不会长时间停在半空。4.6 设备互锁与安全规范不能被忽略的工控底线半导体设备的产线安全不是一句空话。我在软件层面做了几层互锁轴运动前检查所有IO状态、气压值、真空值进入清洗工位前确认门禁安全光幕未被遮挡报警状态下所有运动使能自动断开关键操作必须二次确认并有操作权限记录。同时参考了半导体行业通用工控安全规范里关于访问控制和审计日志的要求上位机里每个关键动作都记录操作员账号、时间、动作参数和结果做到全程可追溯。这些安全设计看起来增加工作量但一次现场事故的代价足以抵消所有安全投入。特别是当操作员或维修工程师临时干涉设备时如果没有互锁和日志异常几乎无法复现和定位。5. MES对接与数据追溯单机版上位机走不进量产线5.1 为什么半导体产线一定要接MES/EAP设备如果只做单机自动运行在实验室或打样阶段完全够用。但要进入量产线就必然要和MES或EAP系统交互。MES下发工单和配方设备上报批次、数量、结果、报警信息这样才能实现整个车间的自动化调度和产品追溯。上位机处于设备与MES之间相当于一个协议翻译器。MES一般用标准接口比如Web API、MQTT或者SECS/GEM而设备端则是TCP私有协议上位机要做的就是双向转换同时保证通信异常时不影响设备本体运行。5.2 上报数据模型设计我在做数据上报时定义了一个统一的设备事件模型数据库里每一条记录大致包含批次号、晶圆ID、石墨岛ID、当前工位、动作类型、执行开始时间、执行结束时间、结果代码、操作员、异常描述等字段。这样MES问起来时可以直接查询并按字段过滤。本地数据库用的SQLite所有动作记录先落到本地再异步同步到MES。这样即使上位机和MES之间的网络闪断本地的完整数据也不会丢网络恢复后自动续传。这个设计在产线现场特别重要因为自动化产线经常会发生网络设备重启这类事情。5.3 断网缓存与补传策略补传不能无脑把整个数据库丢过去MES更关心的是按工单维度汇总。我实现的补传策略是启动或网络恢复时先查询本地未上报记录数量按时间分批推送推送失败则继续缓存并生成一条补传异常日志方便追溯。每批推送都要有MES返回的确认码只收到确认码的记录才能标记为已上报。这套机制上线后在一次网络交换机维护中派上了大用场设备停线不到两分钟数据一条没丢维护结束后自动补传完成。6. 从联调到量产稳定运行一点实在的经验收尾6.1 先做仿真模式再上真实设备这是我踩过最大的坑之后总结出来的经验。第一次现场调试时直接在真实设备上跑完整流程结果一个IO状态判断错误导致机械手往下压虽然没有造成重大损失但已经让所有人吓出一身冷汗。后来我在上位机里加了一个仿真模式运动控制卡、视觉、IO全部用软件模拟界面和状态机完全走真实逻辑。新版本发布前先在仿真模式跑一轮自动化用例没问题再切真实模式。这个仿真模式的价值在后续改造升级中体现得淋漓尽致很多逻辑错误在仿真阶段就能暴露省下的停机调试时间远超写仿真代码的投入。6.2 报警、三色灯与生产记录报警处理在上位机里不能只是弹个窗。现场有噪声、有走动操作员不可能一直盯着屏幕。我做了三色灯蜂鸣器联动绿色表示自动运行中黄色表示等待人工确认红色表示故障停机。每一个报警都带故障码、原因提示、处理建议同时在报警记录表里留下时间戳和当时的设备状态快照。报警发生时要保留关键数据这一点非常实用。晶圆碎片或放片失败后维修工程师可以根据报警时刻的真空值、位置坐标、运动速度快速定位原因而不是靠现场回忆。6.3 部署、版本管理与后续思考工控上位机不像互联网项目可以频繁热更新部署必须严谨。我维护三套环境开发环境、仿真测试环境、现场设备环境。版本号采用主版本.次版本.修订号规则每次发布都生成包含更新内容的发布说明和数据库脚本。现场升级前必须备份当前的配置文件、配方文件和本地数据库保证升级失败时可以快速回滚。还有一个容易被忽视的点工控机本身需要一个看门狗机制。上位机通过心跳文件或定时任务监控自身的核心线程如果状态异常就自动重启上位机程序避免长时间无人值守时设备停摆。这套系统从立项到稳定量产运行大概花了四个多月。回看整个过程真正值钱的不是某个炫酷的技术点而是把通信、运动、视觉、安全、追溯这些跨领域的东西用一套清晰的结构组织起来的耐心。C#和WPF在里面的角色很朴实一个负责逻辑可靠一个负责交互清晰。以后如果再让我做同类设备我大概率还会选这套技术栈但会把仿真模式、趋势记录和数据补传这些基础设施从一开始就规划进去而不是等踩了坑再补。