从https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface
出于某种原因，您的控制器不希望收到任何东西。
我不确定为什么会这样，您是否更改了任何更改缓冲区值/消息大小的参数。

让我们知道您正在使用什么前端软件。

缓冲状态：

高：15,128。第一个值是规划器缓冲区中的可用块数，第二个值是串行 RX 缓冲区中的可用字节数。

特定于 GUI 的任务。虽然默认情况下禁用此功能，但 GUI 应该希望出现此数据字段，但如果需要，他们可能会忽略它。

注意：缓冲区状态值从显示“正在使用”块或字节更改为“可用”。此更改不需要 GUI 知道 Grbl 已编译了多少块/字节。

出现此数据字段：

启用时在每个状态报告中。默认情况下，它在设置掩码中被禁用。
如果出现以下情况，则不会出现此数据字段：

它被 $ status 报告掩码设置禁用或在 config.h 文件中禁用。

既然你说：

但在某些时候我得到了一个

高：14,0

这意味着一个命令在队列中并且串行缓冲区已完全填满。

我怀疑您使用的是 Grbl 的 V1.1，因为缓冲区状态消息已更改，并且上述描述与 V1.1 报告相匹配。

我遇到过类似的问题，但不是在 Arduino 的“官方”V1.1 版本中。我一直在使用在 ESP32 上运行的 V1.1 并在该平台上遇到了问题。就我而言，它发生在慢跑期间，偶尔会发生以下情况：

1. 慢跑发出。命令以最大速度 5080 mm/min 结束机器行程
2. 取消点动实时命令发送
3. 机器速度明显减慢，但并未停止。减速到大约 75 毫米/分钟。

此时状态报告显示 Bf:14, 128 因为我使用的是发送响应类型的协议。如果我尝试发出另一个单字符的 jog cancel，则报告会显示 Bf:14、127。因此该字符到达串行缓冲区并且 Grbl 知道它在那里，但有些东西阻止 Grbl 移动过去的命令采取那个计划者缓冲块。如果我继续发送命令，它会根据发送的命令的长度不断降低串行缓冲区。除了状态报告中的串行缓冲区更新之外，没有来自 Grbl 的“ok”响应或其他响应。如原始帖子中所述，我可以轻松地将其降低到 BF:14,0。

我试图在 Arduino 版本上复制它，但还没有在 AVR Grbl 上完成它。我可以让它偶尔在 ESP32 版本上发生。这是我在那里的错误报告。

bdring/Grbl_Esp32#91

正在发生的事情不容易重复，听起来它可能会影响 AVR 版本以及 ESP32 版本。我将尝试进行更多调查，看看我是否可以查明什么顺序会导致它起作用。不幸的是，我没有 C/C++ 技能来检查代码本身，但也许我可以找出导致我的问题的命令序列，这可以帮助某人查明 Grbl 代码可能发生的情况。

你的控制器有 CH340 USB 芯片吗？你的板子是克隆的吗？
https://www.cnczone.com/forums/arduino/349176-cnc.html

嘿，约翰，你不能指望你记住一切。

要回答最重要的问题：是的，我使用的是 v1.1，似乎我不小心将它发布到了错误的项目中 – 我将在正确的存储库中重新打开这个问题。

为了完整起见：我既不使用标准 Arduino 也不使用 GUI，我通过串行接口直接从自己的应用程序中与 MCU 通信——这就是为什么我怀疑我在这里做错了什么。

这会让人感到困惑，我们是在这里回答所有帖子的位置还是随机添加评论到您的新帖子，我决定三明治馅料在这里。
好的，所以您的应用程序中的串行端口设置为 115200,n,8,1（无奇偶校验，8 位，1 个停止位）？
在代码传输结束时使用回车，也适用于换行和回车，但响应 ok ok 而不仅仅是一个。您多久轮询一次 GRBL 以获取状态，即发送“？”
每 200 毫秒是可以接受的，Candle 默认每 50 毫秒轮询一次，这给我带来了很多问题。
听起来您发送命令的速度会导致您出现问题。如果您没有更改固件，GRBL 会在收到请求时非常乐意在自己的时间发送状态报告。

请提供您的 Grbl $$ 设置、$I 构建信息输出以及错误时的完整状态报告。

您的应用程序中的串行端口设置为 115200,n,8,1（无奇偶校验，8 位，1 个停止位）

它以 57600 bps 运行

每 50 毫秒轮询一次，给我带来了很多问题

这可能是问题所在 – 在每次传输之前添加延迟后，死锁不再发生。但要确保不要因为意外发送数据太快而被锁定 – 是否有解决此问题的方法？

生成状态报告需要时间和资源。我不建议每秒最多查询几次。虽然看起来 Grbl 可以做得更快，但您开始从主程序的其余部分获取资源，并将影响系统的运行方式。

我完全理解这一点，我也接受 GRBL 不会以不可预测的方式做出反应/反应，只要请求速度过快。但是我的问题是死锁，一旦我处于“Bf：14,0”状态，就无法与 GRBL 通信，当没有更多请求以太高的频率发送时也是如此。在这种状态下，必须发出复位以重新获得控制权。这就是我现在正在寻找解决方案的地方，只是针对 GRBL 意外进入这种状态的情况。

如果您的通信同步，则不会发生这种情况，如果电视上的人说话速度非常快而您错过了他们所说的内容，那么您就可以清楚地了解您的设置发生了什么。您所描述的是由您的 GUI 引起的故障，如果您希望问题不会发生，那么您需要一种控制数据流的方法。您提到的不可预测的状态是故障情况，软复位没有意义 – GUI/发送器导致数据溢出并挂起处理器。最好的解决方案是为您的 GUI 编写一个更好的通信处理程序，如果 GRBL 按设计进行通信，它在 99.9% 的情况下都能正常工作。

如果您的通信同步，则不会发生这种情况，如果电视上的人说话速度非常快而
您错过了他们所说的内容，那么您就可以清楚地了解您的设置发生了什么。

我理解这一点，我同意你的看法。但我的观点是不同的：当电视中的人在某个时候开始说话变慢时，我就有机会理解他们当时在说什么。
但是当前的 GRBL 行为是不同的：无论人们在电视上说话的速度有多慢，超过这个“不归路”，我的电视将无法使用，直到我将其关闭再打开。
所以对我来说，在快速通信过程中没有（可用的）响应是没有问题的，但我认为通信被永远锁定是有问题的，当 GUI 减慢并尝试以正常方式通信时也是如此。

我想以非争论性的形象出现，并希望表达为什么除了完全重置之外你不能有任何其他东西，微型已经停止，计算机说不。你不会真的想要一个可以神奇地按下来重新获得控制权的按钮，因为你只会得到乱码和不稳定的控制权。代码可能会在某个时间点处于做某事的中间，而您真的不想回到同一点。在发生崩溃或重大故障后停止、重置和重新启动总是更好。例如，如果您在铣完一个圆弧并重新开始时，您将得到 3/4 而不是半圆。或者，当您躲避工具从夹头中逃逸时，您可能会听到尖锐的尖叫声、巨大的机械爆炸声和明显的砰砰声。重置是你的朋友。

@MeJasonT当这种通讯问题发生时，运动就没有问题了！在锁定之前到达控制器的命令被正确处理，唯一的问题是，一旦通信接口锁定，我就不能再发送任何命令了。因此，如果没有这个锁，只需发送下一个命令（缓慢地）就可以正常继续。

无论如何，谢谢你的帮助！

这是否与您的问题有关
https://github.com/grbl/grbl/issues/1504