发送点动命令的时机很敏感。如果我们发送的命令多于 GRBL 设法处理的数量，这可能会在我们填充其规划器缓冲区时发生。

此处对类似问题进行了讨论#1494。如果将最大点动进给速率设置为高于该轴的最大速度（$110-$112），则存在一个问题。因此，如果 X、Y 和 Z 的最大速度不同，这将导致 UGS 发送的命令多于 GRBL 可以处理的命令。

在代码方面，它可以通过获取该轴的最大进给速度来解决，并确保我们不超过它。它可以在以下任何级别中修复：

• https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/services/JogService.java#L210
• https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/model/GUIBackend.java#L352
• https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/GrblController.java#L542

@winder我不确定哪个级别最好。自发地我在想GUIBackend.java，但可能会有控制器没有执行返回最大进给速度的设置的情况。在那种情况下，*Controller.java实施会更好。但这将意味着大量的代码重复。

昨天再次发生这种情况，Y 轴以 1000 毫米/分钟的速度移动，远低于 8000 毫米/分钟的最大值

嗨，希望你们都度过了一个愉快的圣诞节/新年。

作为更新，当 X/Y 进给率为 1000 毫米/分钟（低于最大值，对我来说是 8000 毫米/分钟）时，这种情况发生了几次，主要是在长距离移动中。
当进给率与我的 1000mm/min Z 最大速率相匹配时，Z 移动似乎没问题。

作为解决方法，UGS 将最大点动进给率限制为最大机器速率的能力如何？
或者更好的是能够设置增量而不是必须坚持 100/1000/10000？
就个人而言，我使用控制器触发器来升高和降低速率，有时我发现 1000 和 10000 之间的差异太大，所以能够设置我自己的增量会很棒！

干杯。

你好，我们又见面了，

我猜你们知道这一点，但我只是想我会把它放在那里……当模拟摇杆返回空档时，UGS 会发送点动取消命令吗？
如果是这样，当缓冲区被刷新后它如何继续移动？

• 0x85：点动取消
  • 通过进给保持立即取消当前点动状态，并自动刷新缓冲区中所有剩余的点动命令。
  • 如果不处于 JOG 状态，或者如果已调用并在处理中，则命令将被忽略。
  • 如果在取消期间检测到安全门微开，Grbl 将返回 IDLE 状态或 DOOR 状态。

是的，UGS 发送了一个取消命令，但这只会清除 GRBL:s 规划器缓冲区中的命令。UGS 可能正在填充
规划器缓冲区，并且还在接收缓冲区中排队一堆命令，这些命令不会被取消命令清除。