夜雨聆风1. 先看一个动作为什么麻烦
半导体设备里的一个“动作”，多数时候不是调用一个函数就结束。
以 Load Port 的 Home、Map、Load、Unload，Robot 的 Pick、Place，Aligner 的 Align，Process Module 的 Initialize、RunRecipe 为例，真实设备动作里经常夹着这些步骤：
检查当前状态是否允许动作。
下发硬件命令。
等待硬件进入 Busy。
持续读取硬件状态。
判断完成、失败、报警或超时。
更新模块状态、Wafer 状态、事件和报警。
允许后续动作继续执行。
如果在界面按钮或业务逻辑里直接同步等硬件完成，问题会很快暴露出来：
UI 或控制服务线程可能被阻塞。
长动作期间无法及时响应 Abort、Alarm、Stop。
多个动作可能并发进入同一个设备，造成互锁失效。
动作失败、超时、硬件报警没有统一处理入口。
后续调试时很难知道动作卡在了哪一步。
所以设备控制软件很少把长动作写成一个阻塞函数，更常见的是用“状态机 + 周期监控 + 分步动作”来管理。Routine 机制就是这套做法里很常见的一种组织方式。
2. Routine 负责什么
Routine 可以看成设备长动作的分步执行器。
它不是 C# async/await，也不是简单开一个后台线程。它把一个动作拆成三类入口：
Start()负责启动动作，一般只下发一次命令。Monitor()负责周期检查动作是否完成。Abort()负责中止动作或清理动作状态。返回
RUN表示动作未完成，下一个周期继续检查。返回
DONE表示动作完成。返回
FAIL或TIMEOUT表示动作失败或超时。
设备软件里的 Routine 接口一般长这样：
publicinterfaceIRoutine{ResultStart(paramsobject[] objs);ResultMonitor();voidAbort();}
这个接口看起来很简单，但它把“启动”和“等待完成”拆开了。这样设备控制系统就不需要阻塞等待硬件，而是可以在状态机的周期扫描中持续推进动作。
3. 它在平台里怎么跑
Routine 一般和模块 FSM 一起用。
模块收到 OP 操作后，不是直接长时间执行硬件动作，而是向模块状态机投递一个消息。状态机根据当前状态判断动作是否合法，合法后进入对应动作状态，例如 Homing、Mapping、Picking、Placing、Homing。
进入动作状态后，FSM 的 TIMER 周期会反复调用 Routine 的 Monitor()。Routine 内部根据硬件状态判断动作是否继续、完成、失败或超时。
这条链路里，动作启动和动作完成不是在同一个同步调用里完成的。OP 入口只把动作送进平台调度，完成判断交给 FSM 和 Routine 在后续周期里处理。
4. 异步动作怎么守住互锁
这里容易产生一个疑问：动作既然是异步推进的，会不会多个动作同时进入同一个设备，造成冲突？
在这类设备软件平台中，异步和互锁并不矛盾。这里的异步不是“随便开线程并发执行”，而是通过多层机制控制动作边界。
4.1 OP 层互锁
对外暴露的动作一般先注册到 OP 中，例如：
LP1.HomeLP1.MapRobot.PickRobot.PlaceAligner.AlignProcessModule1.HomeProcessModule2.Home
当操作界面或业务逻辑调用操作时，OperationManager 会先检查：
操作是否注册。
是否配置了
IInterlockChecker。interlock 检查是否通过。
如果检查失败，操作不会进入模块 FSM。
4.2 FSM 状态互锁
模块 FSM 是第二层互锁。
每个模块都有自己的状态机。只有当前状态定义了某个消息的 Transition，这个动作才允许进入。
例如：
LP 只有在 Idle 或允许的状态下才能 Map。
Robot 正在 Pick 时，再进入 Place 或另一个 Pick 就会有风险。
Process Module 正在 Initialize 时，重复进入 RunRecipe 会破坏动作边界。
如果当前状态不允许该消息，CheckToPostMessage 会拒绝动作，并记录 Warning。
4.3 Routine 队列互锁
模块内部可以维护 Routine 队列。一个模块同一时间只监控队首 Routine。当前 Routine 没有完成之前，后续 Routine 不会开始。
这保证了同一个模块内部的长动作是串行推进的，而不是多个动作同时写同一个硬件。
4.4 设备状态互锁
设备驱动层还会暴露这些状态：
IsBusyIsErrorIsReadyIsOnlineIsAlarm动作完成位
PLC ACK / UNACK
Routine 的 Monitor() 会读取这些状态，决定动作是否继续等待、完成或失败。
4.5 IO 层互锁
对于 IO 型设备，平台还可以在 DO 输出前检查 interlock。
例如夹爪、气缸、门锁、真空、E84 信号这类 IO，不能只看软件状态，还需要检查输入信号、互锁条件和安全条件。DO 写出前应通过 IOManager.CanSetDo() 或类似机制判断是否允许输出。
4.6 业务层互锁
半导体设备还有大量业务互锁，例如：
目标 Slot 是否有片。
手臂上是否有片。
目标模块是否 Ready。
Wafer 尺寸是否匹配。
当前 Recipe 是否允许执行。
当前 Route 是否允许搬运动作。
模块是否 Online。
这些检查不适合都塞进硬件驱动里，通常由 Module、Route、WaferManager 等上层逻辑完成。
所以平台里的互锁是多层叠加的，不是只靠 Routine。
5. 动作流示例：Load Port Home
以 Load Port Home 为例，动作流可以这样拆：
6. Routine 与直接调用设备方法的区别
直接调用设备方法适合非常简单、短时间、无复杂状态依赖的动作，例如读取一个普通状态值、设置一个本地变量、执行一个不会阻塞的模拟命令。
遇到下面这些情况，可以把动作交给 Routine：
动作需要等待硬件完成。
动作可能 Busy 很久。
动作有多步骤。
动作需要超时控制。
动作中需要持续检查 Error / Alarm。
动作需要和模块 FSM 状态绑定。
动作失败时需要统一 PostAlarmLog 或进入 Error。
动作完成后要更新 Wafer、Slot、Recipe、Route 状态。
长动作如果写成一次同步调用，短期看起来能跑，后面很容易遇到这些问题：
操作界面点击后不知道动作到底完成没有。
调度逻辑不知道能不能继续下一步。
动作超时没有统一出口。
Abort 很难插入。
同一个设备可能被重复调用。
现场问题不好定位。
所以长动作不要轻易写成一次同步调用，更稳妥的做法是走 Routine，或者走等价的 FSM 长动作结构。
7. 按设备类型看怎么落地
7.1 Load Port
适合放进 Routine 的动作：
HomeResetMapLoadUnloadClampUnclampReadCarrierIdWriteCarrierId
LP 动作通常涉及机械运动、FOUP 状态、门状态、E84/RFID 子设备、Slot Map 结果和超时控制，不适合简单同步等待。
7.2 Robot
适合走 Routine 或 FSM 长动作的动作：
HomeResetStopPickPlaceGotoGripReleaseTraverseMove
Robot 动作要做强互锁，因为它直接影响 Wafer 搬运安全。Robot 还要检查手臂 wafer 状态、目标模块状态、目标 Slot 状态、当前位置和横移轴位置。
7.3 Aligner / OCR
适合放进 Routine 的动作：
HomeResetStopAlignReadWaferIdVerifyOCR
Aligner 和 OCR 通常涉及旋转、找 notch、读取 Wafer ID、OCR 结果校验。动作结果不仅是硬件完成，还要产生业务数据。
7.4 Process Module / PM
适合走 Routine 或等价 FSM 长动作的动作：
HomeInitializeResetRunRecipePrepareTransferPostTransferCleanAbort
Process Module 可以属于 PLC 型 PM 设备，动作判断往往依赖 PLC 位、ACK/UNACK、报警位、Recipe Step、剩余时间等状态。尤其是 Initialize 和 RunRecipe，不适合只做一次同步调用，更适合通过 FSM/Routine 周期读取 PLC 状态，直到明确完成或失败。
7.5 IO 型设备
IO 型设备不一定每个 DO 都需要 Routine，但这些动作最好纳入 FSM 或 Routine：
多个 IO 组合动作。
带传感器确认的气缸动作。
带安全互锁的门、夹爪、真空动作。
需要等待输入信号变化的动作。
需要超时判断的动作。
单点 DO 输出可以较轻量，但仍要经过 IO interlock。
8. Routine 的代码骨架
一个常见写法是这样：
classXxxActionRoutine : ModuleRoutine, IRoutine{publicResultStart(paramsobject[] objs) {Reset();// 读取配置，例如 timeout// 记录开始日志returnResult.RUN; }publicResultMonitor() {try {Step1_SendCommand(1);Step2_WaitDone(2);Step3_QueryStatus(3); }catch (RoutineBreakException) {returnResult.RUN; }catch (RoutineFaildException) {returnResult.FAIL; }returnResult.DONE; }publicvoidAbort() {// 按需要通知设备停止或清理本地状态 }}
每个 Step 保持这个节奏：
第一次进入 Step 时执行动作。
后续周期只检查状态。
成功后进入下一 Step。
失败或超时要明确返回失败。
9. 写 Routine 时容易踩的坑
9.1 Monitor 里不要长时间 Sleep
Routine 的作用之一就是避免阻塞线程。如果在 Monitor() 里长时间 Thread.Sleep()，会破坏 FSM 周期调度，也会影响 Abort 和 Alarm 响应。
9.2 命令只下发一次
ExecuteAndWait 这类结构的意义是：第一次进入时下发命令，后续周期只检查状态。不要在每次 Monitor() 中重复发送同一个硬件命令，否则可能导致设备动作被反复触发。
9.3 超时要明确
真实硬件长动作都要有 timeout。没有 timeout 的动作一旦硬件无响应，模块可能永久 Busy。
9.4 失败要留痕
动作失败时应记录清楚：
哪个模块失败。
哪个动作失败。
哪个 Step 失败。
是设备 Error、互锁失败、通信失败还是超时。
必要时要 PostWarningLog、PostAlarmLog，并让 FSM 进入 Error 或可恢复状态。
9.5 主状态交给 FSM
Routine 不要绕过 FSM 随意改模块主状态。更清晰的分工是：FSM 决定动作状态，Routine 决定动作进度和结果。
9.6 参数不要写死
动作超时、端口、IP、启用状态、模块数量、Slot 数量等，不要硬编码在 Routine 里。在这类设备软件平台中，应延续配置中心和设备模型的统一设计，使控制服务、操作界面和仿真程序能保持一致。
10. 同步调用和 Routine 的差别
| 维度 | 同步调用 | Routine + FSM |
|---|---|---|
| 动作等待 | 调用线程阻塞 | 周期 Monitor |
| UI 响应 | 容易卡顿 | OP 快速返回 |
| 互锁 | 容易分散 | OP/FSM/Routine 多层控制 |
| 超时 | 容易遗漏 | Routine 内统一处理 |
| Abort | 难插入 | 可在 FSM/Routine 中处理 |
| 状态可视化 | 不清晰 | 可显示 Homing/Mapping/Busy/Error |
| 现场排查 | 依赖日志猜测 | 可定位到动作和步骤 |
| 扩展性 | 动作越多越混乱 | 模块化扩展 |
11. 落到代码时看这几处
写到代码里时，最容易出问题的是动作入口、状态推进、失败处理和仿真路径是否一致：
对外操作统一走 OP，不让 UI 直接调用硬件驱动。
OP 入口只做快速检查和消息投递，不做长时间等待。
每个模块维护自己的 FSM。
长动作使用 Routine 或等价 FSM 长动作结构。
Routine 中所有硬件等待都使用周期 Monitor，不使用长时间阻塞。
每个长动作都配置 timeout。
失败路径能留下日志或报警。
IO 输出先经过 interlock。
Robot、Load Port、Aligner、Process Module 等关键设备要检查业务状态。
仿真程序和真实设备应尽量共用相同 OP/DATA/Module 路径，避免仿真和现场逻辑分叉。
12. 最后再看整体链路
说到底，Routine 是把半导体设备里的复杂长动作拆成可监控、可中止、可超时、可互锁的分步流程。
它处理的不是“怎么开线程”的问题，而是“怎么让设备动作在平台中可靠运行”的问题。
在这类设备控制平台中，一个动作从操作界面发起后，会经过 OP、FSM、Routine、Device、IO、业务状态等多层控制。正是这些层次共同作用，才让系统既能异步执行长动作，又能保证互锁、安全和可维护性。
后续新增设备时，Load Port、Robot、Aligner、Process Module、IO 板卡和 PLC 型设备都可以按这套思路设计动作入口。简单命令可以轻量处理；只要涉及硬件运动、等待完成、状态确认、报警或超时，就应纳入 Routine/FSM 的动作模型中。
