谢谢你的好帖子！

确定点动步长的代码在此处定义：
https://github.com/winder/Universal-G-Code-Sender/blob/master/ugs-core/src/com/willwinder/universalgcodesender/utils/ContinuousJogWorker。 java#L109

我发现的最好方法是这个公式：
(maxFeedRate / 60.0) * (JOG_COMMAND_INTERVAL / 1000.0) * 1.2;

以秒为单位的最大进给率乘以以秒为单位发送点动命令的间隔，并增加 20% 以补偿延迟等。

我认为这会产生足够的工作来让控制器规划器缓冲区保持忙碌。

另一种方法是检查控制器规划器缓冲区大小并发送命令，直到它充满足够的命令。但这需要更多的工作……

我们可以对 20% 进行试验，改为对其进行自定义。

好的，谢谢你告诉我代码的相关部分在哪里。我一直在测试一些变化。

我尝试的第一件事是在序列开始时偷偷进行额外的移动（之后没有延迟），然后继续正常进行。想法是稍微加载队列，这样它就不会干涸。

    private void sendContinuousJogCommands() {
        try {
            isRunning = true;
            final double stepSize = calculateStepSize();
            
            // I only added this line:
            jogService.adjustManualLocation(1.0 * x * stepSize, 1.0 * y * stepSize, 1.0 * z * stepSize);
            
            while (isRunning) {
                // Ensure that we only send one command at the time, waiting for it to complete
                if (!isWaitingForCommandComplete) {
                    isWaitingForCommandComplete = true;
                    jogService.adjustManualLocation(x * stepSize, y * stepSize, z * stepSize);
                } else {
                    Thread.sleep(JOG_COMMAND_INTERVAL);
                }
            }

            waitForCommandToComplete();
        } catch...

那行得通。绝对更好。大约一半的时间我会得到一个很好的平稳慢跑。另一半时间，它会启动和停止一次，然后平稳地慢跑。接下来，我尝试使第一步变大，将 1.0 乘数更改为 2.0 或 5.0。这没有帮助，行为大致相同，只是最初的口吃时间更长（很明显）。当乘数为 5.0 时停止移动后，我确实也注意到偶尔会出现卡顿

运行此测试时我注意到的另一件事是 G1 命令有时发送的速度比每 100 毫秒快得多。短暂（约 1 秒）的点击可能会产生约 5 个 G1 命令或约 20 个，看似随机。我怀疑这是一个与我的修改无关的错误。

我尝试的第二件事是只发送一个大命令，然后不再发送。

    private void sendContinuousJogCommands() {
        try {
            isRunning = true;
            final double stepSize = calculateStepSize();
            
            //try one big move
            isWaitingForCommandComplete = true;
            jogService.adjustManualLocation(50.0 * x * stepSize, 50.0 * y * stepSize, 50.0 * z * stepSize);
            while (isRunning) {
				Thread.sleep(JOG_COMMAND_INTERVAL);
			}

            waitForCommandToComplete();
        } catch...

这真的很管用。每次慢跑都很顺利。当然它确实有一些主要问题，比如它在 50 * stepSize 结束时停止，即使您仍然按住按钮也是如此。如果您靠近它们，它也会触发软限制。

所以，这就是我的建议：我们实施大动作战略。如果启用了软限制，我们会计算它们的距离并将移动大小设置为略低于该距离。如果未启用软限制，我们仍然可以使用相同的计算，但这可能会让用户在机器归位之前尝试慢跑而感到沮丧。所以在那种情况下，我们可以将移动大小设置为等于轴的整个范围（如 Xmax – Xmin）。

你怎么认为？UGS 是否具有计算移动大小（软限位启用和轴限位）所需的信息？如果 feedhold 无法发送或出现其他问题，机器崩溃的风险是否太大？

抱歉我的延迟回复。

我认为在使用诸如游戏手柄之类的控件时，更大的步长不会起到很好的作用。如果我拿着一个模拟控件并稍微改变方向，它会在改变方向之前尝试移动完整的距离（无论单位是 50）。

作为短期解决方案，我们可以自定义步长，用户可以根据需要选择将其设置为 50.0。我们甚至可以尝试检查软限制，尽管我认为这会变得混乱。尝试在可视化器中实施软限制时，我的头仍然很痛。而且我不确定控制器之间是如何处理的… =（
我记得以前尝试过这条路，但当时可能还有其他问题。

根据这一点，我们应该做所有正确的事情，除了检查规划器缓冲区（我认为这与 g2core 上的行为相同）：https
://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging#joystick-implementation 我更有兴趣尝试一下。

明白了。与此同时，我想出了一些其他的方法来尝试。当我有更多结果时，我会更新。我还认为最好的解决方案实际上是在控制器中内置本地慢跑命令。听起来 GRBL 不会那样做，但也许可以在 g2 中完成：synthetos/g2#473

先生们，美好的一天，

我一直在尝试解决慢跑问题。我正在使用带 NEMA23 电机的 DM542T 驱动器。除了以 .001″（或实际上 < 大约 .005″）慢跑外，一切似乎都完美无缺。我怀疑正在发生的事情是在唤醒时间丢失了步骤。如果我一直保持电机电流，问题就消失了。我希望找到一种在启用信号后稍微延迟步进/方向脉冲的方法。有什么想法吗？

我感谢任何帮助。谢谢！

@mojorisin1967这不能从 UGS 完成，需要在控制器固件中完成。
如果您使用的是 GRBL，则有一段关于使用空闲延迟时缺少的步骤：

https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration#1—step-idle-delay-milliseconds
另外，请记住，一些步进驱动程序不记得它们执行了哪个微步停止，因此当您重新启用时，您可能会因此看到一些“丢失”的步骤。在这种情况下，只需通过 $1=255 保持步进器启用。