类似的事情发生在我身上几次，除了我使用鼠标的屏幕按钮。当我释放鼠标按钮时，它停止了，然后又开始慢跑（不幸的是 Z 轴向下 ）。我想，我做错了什么，所以我没有报告。对不起…

顺便说一句，Mac 操作系统 10.16

我有着同样的问题。一旦我松开鼠标按钮，在 GUI 中使用鼠标的点动移动按钮就会停止，但尝试用键盘或游戏手柄点动会堆积队列中的命令，并在按钮释放后长时间保持机器移动。

同样的问题在这里。如果我按住屏幕上的按钮超过 1 秒，就会发生很多事情。松开点动按钮时它会暂时减速，然后逃跑。我在树莓派 3 上运行它。

@Voxar如果您按 GUI 按钮，则不应发生这种情况，而只会发生键盘快捷键。您运行的是什么版本的 UGS？

这种行为以前见过。在 gnea/GRBL 问题“慢跑取消 (0x85) 不工作 [已解决]”中查看此线程
它接缝 GRBL 有一个错误，当串行缓冲区已满并发送“取消文件传输”命令时，同时仍在慢跑正在处理，并且在 OK 从最后一个点动命令返回之前。
它接缝如果 UGS 在发送取消传输命令之前等待最后一个点动命令的“确定”，那么一切都会正常工作。显然，在连续点动模式下，UGS 每 100 毫秒发送一次点动命令，因此可能时间不准确并且 GRBL 需要更长的时间来发送 ok，因为点动命令的发送速度比 GRBL 执行的速度更快。一位用户修改了他们的 UGS 代码以在发送取消传输命令之前多等待 6 毫秒，这样接缝就可以工作了。这也许是所有需要的？

连续点动功能非常有用，所以忽视这个问题并不是一个好的解决方案。
UGS 可以通过在发送取消传输命令之前等待“ok”来避免 GRBL 错误。但是要等多久呢？
或许修改点动命令距离比100ms周期计算的更短，那么GRBL命令缓冲区在连续点动时不会填满。但是随后在点动时进给速率会发生变化，因为 GRBL 将开始减速，因为预计会在当前点动命令结束时停止。进给速度的这种变化听起来可能很奇怪，但至少它不会在您指示它停止时不受控制地继续运行！

抱歉，我不具备对 UGS 代码进行这些更改的技能，所以我所能做的就是评论并希望提出可能的解决方案。
感谢那些花时间开发 UGS（和 GRBL）的人。
我希望此评论有助于解决此问题。

@TrevorTigheUGS 中实现的连续点动功能应注意等待最后一个命令被处理的时间，直到它发送“点动取消”命令。据我了解，GRBL 中的点动取消将安全地将任何运动减速至停止，因此无需更改 UGS 的进给率。

如果有人好奇它在这里实现：https ://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/utils/ContinuousJogWorker.java

但连续慢跑功能仅在使用 GUI 按钮或游戏手柄时有效。我知道在早期版本中此实现存在一些问题，但应该得到解决。如果有人在使用 GUI 按钮或游戏手柄时仍然遇到此问题，欢迎您发布新的错误报告。

这个问题突出了键盘快捷键的问题。快捷方式不能使用，ContinuousJogWorker因为快捷方式的触发不会同时发出 KEY_DOWN 和 KEY_UP 事件。它仅以操作系统定义的时间间隔发出 KEY_PRESSED 事件。因此，UGS 无法知道在使用快捷方式时应该何时发出点动取消。

只要用户按住快捷方式，快捷方式就会继续发出点动命令，因此这个错误很可能源于串行缓冲区被填充的问题，并且没有像你提到的那样被 GRBL 处理。解决方案可能是点动服务应该在发出新的点动命令之前检查控制器规划器中是否有空间。

我刚刚又做了一些实验。
当我在 UGS 点动屏幕中设置的点动进给率远高于轴的最大允许进给率时，会发生重新启动点动问题。因此 UGS 发送的点动步数大于 GRBL 在 100 毫秒时间段内的能力。
因此，假设轴以请求的速率行进，由于 UGS，GRBL 计划缓冲区正在填满。

UGS 的唯一解决方案是确保它在发送取消传输之前等待最后一次点动的“确定”。但是，如果轴的移动速度比 UGS 认为的要慢很多，那么这段时间可能会比 100 毫秒长很多。

在 GRBL 中，我将 X 轴最大进给速率设置为 6000 毫米/分钟，将 Y 轴设置为 2500 毫米/分钟。这是因为 Y 轴比 X 轴更大更重。大多数机器的 Z 轴在机械上也不同。因此，不同的最大进给率很常见。
为了从我的 X 轴获得全速，我将 UGS 点动速率设置为 6000 毫米/分钟。所以我的 Y 轴通常会遇到失控点动问题。

我在测试时遇到了这个问题。

你怎么看，也许作为一种解决方案，我们可以启动一个计时器，如果超过 X 毫秒没有来自键盘的事件，则发送停止？例如，如果超过 50 毫秒没有事件发生，那么我们将发送 STOP。

@sergei66666如果我以 100 毫米的步进增量执行一次快捷方式，会发生什么情况？那也应该中止吗？

我刚开始使用 CNC。但如果我理解正确，那么当我们停止转动编码器时，控制面板（吊坠）就会停止移动。
将键盘控制视为一个挂件可能是正确的（从安全的角度来看）。
一旦我们松开键盘上的按钮，运动就会立即停止。

但是肯定会有人觉得不对。对于他们，添加一个设置，让他们可以不安全地工作（运行最后一个命令到最后）。

但在这里值得考虑一个细微差别。现在程序的工作方式如下：一个人按下组合键，按住它一会儿，发送了几个移动命令（每个 100 毫米）。
即使在不安全的情况下，也应该取消所有命令，除了第一个命令。如果做不到这一点，那么在释放键盘上的按钮时，我们必须始终停止运动。否则，可能会导致与障碍物发生碰撞。

或者，您可以更改程序的行为，以便仅在前一个移动命令完成后才发送下一个移动命令。
我不知道其他固件，但 grblHal 发送当前状态（慢跑、空闲等）。这将有助于确定当前命令的结束并发送下一个命令。

如果我把我的想法描述得太混乱，请原谅我。

@sergei66666感谢您的输入。但是正如我在这个问题报告中多次指出的那样，我们没有得到关于何时释放密钥的事件。这是我们使用的快捷方式框架的限制。我们需要在现有的快捷方式监听器之上添加我们自己的按键事件监听器，使用任何用于慢跑的快捷键组合。

您的第二个选择更容易实施，并且可以缓解严重的问题。

是的，我阅读了您关于框架事件系统不完善的帖子。我不是 Java 专家，但我认为未来几年框架不会有任何变化。
但在我的主观意见中，默认情况下，当我们释放键盘上的键时，运动应该总是停止。这将有助于节省大量切割工具
这就是为什么在上面的帖子中我建议使用计时器形式的拐杖来帮助解决这个问题。