@mschorer: 这绝对是可能的。我一直在思考如何处理这个问题。主要问题是我们仍然必须完全清空规划器缓冲区以确保按时执行冷却剂和主轴命令。我们有意将 Grbl 设计为不必在规划器中处理任何这些命令。它使任务清晰且易于管理，但代价是出现了这个问题。

问题的原因是当规划器同步并完全清空时，状态机看到队列中没有更多的动作并且传入流中没有任何命令，因为 Grbl 还没有用“ok”响应. 因此状态机决定 CYCLE 已完成并将 Grbl 置于 IDLE 模式，导致您在流媒体赶上时发出另一个循环开始。

因此，要解决此问题，您确实需要在清空规划器缓冲区和 Grbl 向 GUI 响应“ok”并解析下一个命令之间有某种延迟。我们可以使用段缓冲区作为创建此延迟的方法，因为段缓冲区将在循环完成最多 50 毫秒之前清空计划程序缓冲区。这可能会给 Grbl 足够的时间来响应“ok”……但是，这不是很可靠，因为低波特率可能无法及时发送下一个命令。（9600 波特 ~= 1KB/秒，所以最好的情况是这次发送 50 个字符）。

IMO，最好的方法是重写流协议。我认为我们可以通过分解 g 代码解析器首先解析和错误检查 g 代码块并在执行命令之前以“ok”响应返回 GUI 来稳健地解决这个问题。因此，这将允许 GUI 在规划器同步时开始发送下一个 g 代码命令。这就是我过去几周一直在思考的问题，试图想出如何巧妙地实现它并检查这种方法是否有任何问题。

不完全的。我的同步想法是：

• 将 M[x] 和 S[y] 命令解析为 stream_m 和 stream_s
• 对于新解析的移动，将 stream_m 和 stream_s 写入移动的段
• 当段被执行/发送到步进器时，排队的 stream_m 和 *_s 也被发送到硬件

不需要清空。变化将与动作同步……

otoh，正如您的机械师朋友可能会说的那样：主轴可能需要一段时间才能达到/更改所需的转速 – 也许我们不应该移动！

@mschorer: 不幸的是，段缓冲区不会以这种方式运行。段缓冲区仅获取规划器缓冲区中第一个块的片段，供步进模块执行。规划器缓冲区仍然可以充满排队的动作，并且 g 代码解析器将动作添加到规划器缓冲区的末尾。所以，你仍然需要清空计划缓冲区。

你可能会想为什么我们不只是在规划器缓冲区中标记一些东西，所以当段生成器到达它时，它会将它添加到段缓冲区以使步进器 ISR 按时执行它。问题是规划器是建立在假设整个过程中有连续运动的基础上的。我们可以重写计划器以在其中对非运动任务进行排队，但正如我之前所说，它会使一切变得复杂。也许有一种干净的方法可以做到这一点，但肯定需要大量重组。

我正在研究激光切割机/蚀刻机控制器，这似乎在使用主轴控制来驱动激光时非常有用。在这里，我们不希望在激光打开或关闭之前停止，因为激光会燃烧太多材料。我破解了一个简单的版本，它在 ISR 函数中的每个块执行开始时打开和关闭一个引脚（基于 G1.1 命令打开它，G1 默认关闭）

至于串行流式命令，那也很有用。刻录灰度图像时，数据传输为每像素 8 位，通常每行 1000 像素。一次加载整行是很好的，但 328p 就是没有可用的 ram。我一直在玩 teensy port@matthewSorensen解决这个问题。此外，它具有原生 USB2.0 支持，因此理论上我们可以传输高达 12 Mb/s 的数据流。