很难说。在查看 gcode 之前，我会先更新到最新版本。

我今天会做 grbl 更新。

gCode 都是标准的，所以不足为奇。我在流式传输时从代码中删除所有不必要的字符以提高性能。然后，我根据收到的“ok”消息，根据缓冲区级别的字节计数逐行发送。

首先，我检查了我的代码两天，但当我意识到另一个人的另一个流媒体软件有同样的问题时，我不再相信这是我自己的代码中的一个错误——尤其是在 15069/60000+ 行之后。另外，使用 $C 的代码检查适用于整个文件，并且逐行发送并等待“ok”也适用。

grbl latest 启动并运行后，我会回复您。

我迁移到 1.1g 后仍然遇到同样的问题。
如果您有一台可以移动得足够快的机器，那么如果您可以运行我的 gCode 来检查您是否看到相同的问题，那就太棒了。奇怪的是，我看到多个不同的流媒体应用程序出现了同样的问题，而不仅仅是我自己的。

您的设置显示 $10=8，但根据 WIKI，此掩码的最大值为 3。$10=8 没有缓冲区报告。但是请阅读以下内容：

此外，我使用 3 种不同的硬件（Bare Uno w/16u2、Bare Nano w/ch340g 和 ESP32 w/cp2102）在我的 GUI 上运行代码

ESP32 在我停止之前已经超过 17,000 行，但这是一个端口，而不是“官方”Grbl。在我的 Uno 和 nano 上运行多次后，它每次都停在 15063。我怀疑你说 15069 是因为你使用缓冲区填充，而我只使用发送响应。当它停止时，状态报告是：

<Idle|WPos:59.990,45.318,0.000|Bf:14,128|FS:0,141|Pn:XYZ>

并且线路挂断的是 F2000 S1 应该没问题。

请注意，规划器缓冲区在 14 处占用了一个块，而串行缓冲区在 128 处完全可用。它卡在那里。起初我认为可能缺少一个“ok”响应，如果它发生，我的 gui 会进入一个等待它的循环，所以我修改了我的 gui 以允许强制一个“ok”以查看它是否会继续。mod 完成了我的意图并发送了下一行，但所做的只是将报告的串行缓冲区减少为下一行发送的字符数。这是发送的行（我的发送带空格）G0 X57.461 Y47.231 状态报告转到

<Idle|WPos:59.990,45.318,0.000|Bf:14,108|FS:0,141|Pn:XYZ>

玩弄我发现发出循环启动“〜”实时命令让事情再次运行。因此，系统似乎不知何故处于一种未在状态报告中报告且不允许新命令的馈送保持状态。

所以仅供参考，我的 GUI 发送程序具有比较回波的功能，如果打开到发送的线路，则在不匹配时中止。我在打开回声的情况下再次运行，程序仍然在 15063 处停止，最后回显的行 (F2000S1) 与发送的内容匹配。

有趣的。只有 F 进给和 S 速度命令的命令将强制缓冲区同步，以确保主轴在正确的时间设置为正确的功率。如果将 S 速度命令移动到以下 G0 行，它应该开始工作，因为 S 速度现在与运动相关联并在缓冲区中排队。

在 G0 之前似乎还有一个多余的进给命令。您将其设置为 F2000。然后运行 ​​G0，它不使用 F 进给。然后再次将其更改为 F1500。对于激光作业，最好始终将 F 进给和 S 速度变化与运动命令结合起来，以避免强制缓冲同步。

我怀疑您发现的是在这些缓冲区同步场景和运行高速激光作业时出现的错误。缓冲区可能会进入不确定状态并以某种方式进入强制保持状态。不知道为什么，但我敢肯定，如果你去掉孤立的 S 和 F 命令，它会运行良好。

更正，F 进给指令不需要和运动指令一起使用。只有 S 速度变化需要。这就是激光模式的设计方式

@chamnit我一直在玩 Grbl_ESP32 端口@bdring并在那里提出了一个关于可能相关的点动取消/进给保持的问题。我在那里报告的问题是因为我无法在 Grbl 的 AVR 版本上重现它，但它与这个问题有相似之处。我将链接该问题报告，但简而言之，点动取消或进给暂停有时似乎未完成并锁定到降低速率的状态。在这种情况下，它仍然在状态报告上显示 Jog，但相似之处是计划缓冲区报告的 14 和串行报告的 128。发出新的命令和上面一样，把规划器留在 14 并减少串行。在这种情况下，循环启动或另一个点动取消不会纠正。唯一似乎通过的命令是软复位，它当然会由于运动中的复位而产生警报。我认为在这里提出这个可能会帮助您缩小正在发生的事情。

bdring/Grbl_Esp32#91

编辑：我在看到所有其他回复之前写了这个。我现在正在阅读它们。

谢谢！！这比我对 grbl 配置和状态响应的有限理解要深入得多。

我没有打开响应回声来提高光栅雕刻的性能。我可能会尝试您描述的内容并实现类似的回声比较功能。

但是，既然您确实确认了我的症状，那我们该怎么办？在我的 Nano 克隆上运行的 328p 版本的 grbl 是否可能以某种方式损坏并且有错误？IRQ 溢出？过去我遇到过几次，总是怀疑我自己的 gcode 发件人。但它从未如此可复制，尤其是即使使用不同的 GUI，现在甚至使用不同的机器。

很多人可能不同意，当然也有很多人在 Nano 克隆上运行 Grbl，但我个人不再使用 nano 来测试我的 GUI。原因就是因为这个问题。

https://github.com/gnea/grbl/wiki/Known-Issues#usb-to-serial-transmission-errors

虽然很少见，但确实会出现数据传输错误。一个不可重现的错误可能是由于 ch340 usb 到许多克隆上使用的串行芯片的随机数据损坏。这个问题是几年前发现的，很可能已经被纠正了，但没有办法确认。事实上，我上面使用的 nano 在文件的回显比较运行期间没有显示数据损坏，并且是我在过去 6 个月左右购买的新克隆。可能是他们更新了固件，但根据我过去的经验，当带有 16U2 的 Uno 克隆仅约 5 美元时，我没有充分的理由冒险。其他人可能不同意，但对我来说，我不会运行带有 Nano 克隆的实际机器。我相信真正的 Nano 使用 FTDI 芯片，这可能没问题，但需要测试。我有数百万行的测试程序。听起来很极端，但如果程序没有完成，即使它通过了 90% 的文件，那么我书中的那个 MCU 也不能在机器上使用。我在编写我的 GUI 时仍然使用它们，并且遇到了随机问题。我不记得具体细节了，但我的 GUI 中添加了一个功能，但它运行不正确，并尝试并尝试调试我的代码。最后，我切换到 UNO，一切正常，无需在我的 GUI 中更改代码。这类事情不会激发信心。只是我的观点。你的旅费可能会改变。但是在我的 GUI 中添加了一个功能，该功能运行不正常，并尝试并尝试调试我的代码。最后，我切换到 UNO，一切正常，无需在我的 GUI 中更改代码。这类事情不会激发信心。只是我的观点。你的旅费可能会改变。但是在我的 GUI 中添加了一个功能，该功能运行不正常，并尝试并尝试调试我的代码。最后，我切换到 UNO，一切正常，无需在我的 GUI 中更改代码。这类事情不会激发信心。只是我的观点。你的旅费可能会改变。

有趣的。我听说了这一点并阅读了 340 问题。然而，我所有的克隆都有那个芯片，而且我从来没有遇到过损坏的数据或不希望的机器运动。我在我的 PCB 铣床以及我的定制 K40 CO2 激光器上使用它。但是，我确实觉得在某些时候升级是必要的。

但是上面讨论的问题与 340 问题无关，因为您和我在多台不同的机器、固件和 gcode 发送器上运行相同的 gcode 时遇到同样的问题！

慢跑和状态机问题可能与此有关，但我认为仅与状态机可能正在做一些时髦的事情有关。目前尚不完全清楚究竟是什么触发了这个激光问题。更有可能是激光代码中的某些东西没有应有的强大。再一次，如果您尝试按照我的建议进行操作，则应该纠正此激光程序问题。如果有效，请告诉我。

我已经可以确认我的光栅雕刻 gcode 正在使用您建议的 gcode 语法并且确实有效。我现在正在实施矢量雕刻的更改。它主要将 gcode 从 FlatCAM 输出的内容转换为您建议的内容：
G0XxYxFxSx 和 G1 相同，而不是与运动命令分开运行 FS。

是的，这个特定问题与数据损坏无关。然而，当你说

然而，我所有的克隆都有那个芯片，而且我从来没有遇到过损坏的数据或不希望的机器运动。

我会争辩说你真的不知道，因为数据损坏是阴险的，通常是丢失字节的结果。例如，如果您将以下代码行发送到 grbl

G1 X4.453 Y6.907
G1 X4.480 Y6.904
G1 X4.503 Y6.899
G1 X4.528 Y6.891

数据损坏可能类似于仅删除下面由括号限制的字符

G1 X4.453 Y6.9[07
G1 X4.480 Y6.90]4
G1 X4.503 Y6.899
G1 X4.528 Y6.891

所以 Grbl 会看到这个

G1 X4.453 Y6.94
G1 X4.503 Y6.899
G1 X4.528 Y6.891

整个命令丢失但 Grbl 没有收到任何无效命令。所以，Grbl 不会抛出错误。上面是一个很好的例子，说明上述代码中的短距离移动可能无法识别，并且短距离可能无法被眼睛感知。

这只是一个假设的例子，但在我对 ch340 芯片的测试中，我发现 Grbl 得到的东西是不正确的。它是否会在现实中引起问题取决于丢失的确切性质。这正是我在 GUI 中实现回声比较功能的原因。顺便说一句，我发现问题的方式是在实现字符计数协议时。当上述情况发生时，您会得到一个更少的“ok”响应，并且 GUI 最终停止发送，认为缓冲区已满，而实际上它不是。

在我们拥有可以对传输数据执行错误检查的硬件/软件设置之前，我已经放弃了我的 GUI 中的字符计数。对于我目前在铣床上使用 Grbl 的目的，它不会花费我任何费用，因为发送响应对于铣削操作来说足够快。我知道这可能不是某些用途的选择，尤其是激光用途，在这些用途中，吞吐速度非常重要，但这是我在我的工厂所做的。

我重新配置了最新的 FlatCAM 以输出与 grbl_laser 兼容的 gcode。
现在，该程序运行时间更长，但由于命令结构不同，它也是发送到 grbl 的完全不同的程序。
坏消息是，它仍然会在任意数量的 gcode 行之后停止。比最初的 15000 行大关要晚得多。

输出.zip

当我将切削的最大进给率降低到 750 并将急流的最大进给率降低到 1000 时，新代码一直贯穿始终。

症状似乎是， grbl 有时只是在饥饿时死亡，而不是在最后一个向量的末尾停止以等待下一个可用命令。

以 20kHz 以上的频率运行 Grbl，同时在高进给率下进行非常短的直线运动的激光作业可能会使 AVR cpu 过载。Grbl 每秒可以执行大约 300-400 行 gcode。激光光栅作业很容易达到这个阈值。这很可能是您遇到的问题，因为当您降低进给速度时它运行良好。

尝试以较慢的速度运行更快的作业或增加每个 gcode 行的距离，即降低分辨率。Grbl 在有限的 AVR 8 位控制器上运行得比较好。如果您需要更快，有 ARM 版本的 Grbl 可以运行 3 到 5 快。

20kHz+ 步频。您还可以通过调整微步来降低 CNC 机床的步长/mm。这将降低您的最大步速，同时保持相同的速度。它通过为 Grbl 释放更多周期来处理和计划传入的 gcode 来工作。每次 Grbl 必须执行一个步骤时，步骤中断都会调用相当多的周期开销。