运动控制软件不能只是对厂商 SDK 的薄封装。上层需要的是“平台移动到晶圆坐标并稳定”，而 SDK 提供的往往是脉冲、编码器计数和轴号。硬件抽象层负责在两者之间建立稳定、可测试的语义。
1. 抽象轴的能力而不是品牌
通用轴接口通常包含使能、回零、绝对与相对运动、停止、状态和故障复位，但不能用最小公分母抹掉差异。扫描触发、龙门同步和位置比较等能力应通过可发现的能力接口表达。
配置中要明确单位、正方向、软限位、速度和坐标系。禁止让上层猜测某个数值是毫米、微米还是编码器计数。
2. 命令完成不等于运动完成
异步接口至少要区分已接受、运动中、进入位置窗口和稳定完成。超时后也不能假设轴已经停止，必须查询真实状态并决定受控停止还是等待。
取消请求要定义减速停止、立即停止或在扫描段结束停止。不同动作的物理后果不同，不能只暴露一个通用 Cancel。
3. 坐标变换要集中管理
电机坐标、平台坐标、相机坐标与晶圆坐标之间存在旋转、缩放、偏移和补偿地图。变换链应版本化，并保留正反向验证。业务代码随处加偏移量，会让校准和故障定位失控。
4. 联锁必须靠近硬件
软件软限位提升可用性，但不能替代硬限位、驱动保护和安全回路。门禁打开、真空吸附丢失或碰撞传感器触发时，停止路径应尽量少依赖上层进程和网络。
硬件抽象层要统一故障分类，同时保留原始厂商错误码和诊断数据。过度翻译成“运动失败”会丢掉最有价值的信息。
5. 仿真接口从一开始就设计
同一接口应支持真实驱动和行为仿真。仿真不仅立即返回成功，还要模拟时间、限位、跟随误差和断连。这样上层状态机可以在没有硬件时验证失败路径。
总结
好的硬件抽象不是隐藏所有细节，而是稳定业务语义、显式暴露能力与失败，并把单位、坐标和完成条件统一起来。它让硬件替换可控，也为仿真和自动化测试建立入口。