Tiger 控制板历史审查：运行标志与急停状态（2025-09-15）

这是 2025-09-15 的 Tiger 控制板状态同步审查记录，与9 月 11 日整体审查属于不同阶段。本次保留其修改线索和待核对问题，去掉了“不会产生副作用”“可直接投入使用”等缺少工程证据的结论。

原记录没有对应仓库、完整提交、构建产物或实机测试报告。下述文件名和行号是当时的定位线索，不保证匹配当前工程；本次只审读记录和片段，没有重新审查当前固件。

修改意图：让运行标志跟随实际停转

原记录称，在 A3Servo_CommStateMachine() 第 1279～1283 行，以及 A3Servo_ReadServoStatus() 第 1463～1467 行加入了类似条件：

if (!old_zero_speed && new_zero_speed && g_buttonControl.machine_running)

其意图是：已观察到非零速，随后观察到零速，并且运行标志仍为真时，清除 machine_running。这可以解决某一种“实际停止后软件还显示运行”的情况，但该条件本身不能证明修复完整。

情形	单靠该条件的局限
启动命令已发出，但电机尚未开始转动	需要区分启动请求、启动中和已运行，不能直接用零速推断整个操作完成
通信超时后仍保留旧的零速值	数值未变化不表示状态仍有效
软件运行标志错误地为真，而零速从开始就为真	没有非零→零边沿，条件不会触发
两个更新入口交错执行	old/new 与运行标志可能不来自同一份状态快照
急停、故障或重新上电	需要明确定义恢复条件，不能只复用普通停转路径

原文声称不会影响启动、急停和其他互锁。这些应转成回归测试项，而非先验保证：检查每条路径对标志的写入时机、通信失败行为，以及新旧命令的对应关系。

原记录中的其他问题

线索	待复核问题	可验证的目标
g_buttonControl.machine_running 与 g_servoController.State.bo_zeroSpeed 多处直接访问	是否由多个任务或中断读写，是否存在未同步访问	建立读写者清单和统一的状态发布边界
emergency_stop_active 与 bi_emergencyStop 两套字段	分别是实际输入、请求、锁存状态还是执行结果？	明确语义，不把不同概念强行同步为一个布尔值
freertos.c:334 的 ButtonControl_SetSystemReady(true)	是否只按启动延时就认定系统可运行？	就绪条件包含必要通信、驱动器及传感器检查，并有失效撤销路径
modbus_slave_map.c 与状态机都清除命令标志	请求可能在消费前被清除，或重复消费	定义请求接收、处理、完成/拒绝的生命周期
气阀管理只有部分入口受保护	直接访问是否绕过同一状态检查？	所有入口使用一致策略及同一份有效快照
Modbus 表与控制状态分别更新	上位机可能读到不一致组合	将相关字段作为一组提交或发布
错误恢复与看门狗策略不完整	故障后的状态是否可辨认，恢复是否需要人工确认？	为每种故障明确状态转移和确认条件

原文还给出“485 次全局变量访问”的统计，但没有检索命令、源码快照或计数范围。本页保留这个历史数字作为线索，不将它当成已经复算的缺陷数量。全局访问次数多也不自动等于同等数量的竞态。

气阀与急停片段不能作为安全验收

原记录展示了两条判断：machine_running 为真时禁止气阀操作；emergency_stop_active 为真时返回允许，并将后者解释成“急停时允许开阀释放工件”。

这只是当时报告描述的行为。阀门究竟用于夹紧、松开、制动还是泄压，工件在急停后是否仍可能运动，当前文档都没有给出。不能将“急停即允许释放”推广成通用规则，也不能凭软件零速标志证明可以释放工件。 必须结合机械与气路设计、实际反馈和故障状态确认动作条件。

同样，“多个位置检查了伺服报警”只是原报告的概括，没有覆盖全部入口的证据。需要检查报警或通信失效时，本地按钮、Modbus 命令和自动流程是否采取一致行为。

建议的状态组织方式

先把以下概念分开，再决定锁或消息机制：

概念	例子
输入事实	采集到的急停输入、驱动器状态字、零速反馈
数据质量	有效标记、采样时间、通信故障
控制请求	启动、停止、复位、阀门操作请求
执行状态	待机、启动中、运行、停止中、故障锁存
对外结果	已接收、已执行、已拒绝、拒绝原因

一种可评估的方案是由控制任务拥有状态机，其他任务通过队列提交请求，读者读取完整快照。队列还需定义满、超时、重复请求和确认策略；换成队列不会自动消除所有逻辑错误。

如果继续使用互斥锁，应覆盖相关字段的一致读写，并避免在持锁状态进行长时间通信或延时。原建议结构体混入 osStaticMutexDef_t 与 osMutexId_t，没有标明 CMSIS 适配版本，不能当作可移植的完整示例；CMSIS-RTOS2 的创建接口为 osMutexNew()，静态控制块通过 osMutexAttr_t 描述，具体存储要求依实现而定，而且互斥锁不能在 ISR 中使用。CMSIS-RTOS2 互斥管理

原文提出的 SystemState_IsConsistent() 可以作为诊断入口名称，但其检查规则必须由明确的不变量定义。例如“状态无效时不能报告正常就绪”比“几个布尔值看起来一致”更可测试。原建议没有函数体，不能视作已经实现。

按原计划建立验证闭环

原记录的近期目标是统一状态管理和增加一致性检查；中期是集中状态转移、消息队列和转移日志；长期是增加物理反馈、自动化测试与延时/阈值参数化。保留这些方向，同时增加每一步的验收条件。

建议的回归矩阵至少覆盖：正常启动与停止、启动失败、停止后仍报运行、通信中断与恢复、陈旧零速反馈、急停发生在不同运行阶段、重复远程命令、并发本地/远程请求、队列或锁超时、看门狗复位及重新上电。每个案例记录前置状态、输入事件、期望输出和实际观测。

原先对“修改优秀、整体良好、可直接投入使用”的评价没有附这些证据。本页将其改为待验证结论：完成源码定位、构建、并发测试和实机故障场景后，才能判定具体修复是否符合该版本设备的要求。