LinuxCNC中Gmoccapy界面G96模式下的异常行为分析与修复

问题背景

在LinuxCNC 2.9.4版本中，用户报告了Gmoccapy图形界面在使用G96（恒定表面速度）模式时出现的两个异常现象：

1. 首次执行G96 S100 M3命令后，HAL引脚spindle.0.speed-out和界面显示会短暂显示正确速度，然后跳转为100
2. 再次执行M3命令后，HAL引脚工作正常，但界面速度显示出现过多小数位

技术分析

经过深入调查，发现问题的根源在于Gmoccapy界面与LinuxCNC核心之间的交互机制存在两个关键问题：

1. 状态通道数据问题

在G96模式下，Python状态通道中的"speed"值实际上反映的是最大CSS速度（由D字参数设置或默认值1e30），而非实际主轴转速。Gmoccapy错误地使用了这个值来显示主轴速度，导致显示异常。

2. 信号处理竞争条件

当首次执行G96 S100 M3命令时，GUI按钮状态变化会触发"clicked"事件处理器，这些处理器会调用_set_spindle()函数。由于竞争条件，当这个函数执行时，解释器已经处于IDLE状态，导致HAL引脚被错误地设置为界面参数而非实际计算值。

解决方案

针对这两个问题，开发团队实施了以下修复措施：

1. 显示修复

将速度显示从依赖不可靠的状态通道改为直接读取HAL引脚值：

# 原代码使用状态通道
speed = self.stat.spindle[0]['speed']

# 修复后使用HAL引脚
speed = self.halcomp['spindle-speed-fb']

2. 信号处理优化

重新设计了按钮事件处理机制：

• 将原有的"clicked"信号处理器迁移到"released"信号
• 为"clicked"信号创建新的处理器，避免调用_set_spindle()函数
• 确保按钮状态变化不会意外重置主轴速度

技术启示

这个案例揭示了GUI开发中几个重要原则：

1. 状态同步：GUI应谨慎处理来自底层系统的状态信息，特别是当这些信息可能有多种解释时（如G96模式下的速度值）

2. 事件处理：按钮等控件的信号处理需要考虑所有可能的触发场景，避免因自动状态变化导致意外行为

3. 竞争条件：在实时控制系统中，GUI响应速度与底层控制循环的时序关系需要特别关注

修复效果

经过上述修改后：

• HAL引脚spindle.0.speed-out在首次命令后即能正确反映实际转速
• 界面速度显示格式恢复正常
• G96模式下所有功能均能按预期工作

这一修复不仅解决了报告的问题，还提高了Gmoccapy界面在高级加工模式下的稳定性和可靠性。