注释
.jpg "Planner 同步后的延迟 #416"){kind=avatar}
作者
|
注意：我决定使用冷却液喷雾功能代替我的自定义 M 代码进行测试，只是为了检查它是否是我所做的。我还在我的 gcode 中注释掉了 G4，所以它只是严格使用 M7， 这仍然有延迟，因为它还调用了 protocol_buffer_synchronize()； 任何帮助表示赞赏:) |
.jpg "Planner 同步后的延迟 #416"){kind=avatar}
成员
|
@timryder： 是的。尝试使用源代码中的 stream.py 流程序。此方法预加载串行读取缓冲区，因此“ok”通信协议之间没有滞后时间，也不必等待下一个命令的较慢串行下载。 如果您已经在使用它或者您正在使用的 GUI 正在使用它，我很惊讶会有这么大的延迟。在我对规划器和解析器的计时中，每个块不应超过 4 毫秒左右，但通常为 0.2-0.4 毫秒。在绝对最坏的情况下，恢复和重新加载整个规划器缓冲区的时间不应超过 50-100 毫秒。 |
成员
|
@timryder：另外，禁用 step_idle_lock 设置。通过将它设置为 0 秒以在它停止时完全禁用你的步进器，或者将它设置为 255，这将使其保持启用状态。这可能与您看到的延迟有关。 |
作者
|
关闭，肯定是step_idle_lock的设置。 👍 |
我正在将 Grbl 用于自定义应用程序，我发现每当我调用
protocol_buffer_synchronize();
我注意到每次调用后都会有很大的延迟。
例如，我正在编写一些自定义 GCode 来协调工具和 G4 作为延迟。
我为这个工具写了一个特殊的 M 代码来打开输出，然后我调用 G4 P0.05 以确保这个工具到达工件，我希望它尽快完成，因为工具不应该延迟一次G4 已经完成，我想立即开始动议。
相反，我看到在处理下一个命令之前有 ~250 – 500 毫秒的延迟
使用 0.9c rev，一个想法？