注释
.png "GRBL 与 Bf:14,0 失速 #1507"){kind=avatar}
|
来自https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface 让我们知道您使用的是什么前端软件。
Bf：15,128。第一个值是规划器缓冲区中的可用块数，第二个值是串行 RX 缓冲区中的可用字节数。 特定于 GUI 的任务。虽然这在默认情况下是禁用的，但 GUI 应该期望此数据字段出现，但如果需要，它们可以忽略它。 注意：缓冲区状态值从显示“使用中”块或字节更改为“可用”。此更改不需要 GUI 知道 Grbl 编译了多少块/字节。 此数据字段出现： 在启用时的每个状态报告中。默认情况下，它在设置掩码中被禁用。 它由 $ 状态报告掩码设置禁用或在 config.h 文件中禁用。 |
.png "GRBL 与 Bf:14,0 失速 #1507"){kind=avatar}
|
既然你说：
我怀疑您使用的是 Grbl 的 V1.1，因为缓冲区状态消息已更改并且上述描述与 V1.1 报告相匹配。 我遇到过类似的问题，但不是在 Arduino 的“官方”V1.1 版本上。我一直在使用在 ESP32 上运行的 V1.1，并在该平台上遇到了这个问题。就我而言，它发生在慢跑期间，偶尔会发生以下情况：
此时状态报告显示 Bf:14、128，因为我使用的是发送-响应类型的协议。如果我尝试发出另一个单字符的点动取消，则报告会显示 Bf:14、127。因此该字符到达串行缓冲区并且 Grbl 知道它在那里，但有些东西阻止 Grbl 移动通过命令采取那个计划者缓冲块。如果我继续发送命令，它会继续驱动串行缓冲区，使其与发送的命令的长度一致。除了状态报告中的串行缓冲区更新外，Grbl 没有“确定”响应或其他响应。如原帖所述，我可以轻松地将其降低到 BF:14,0。 我试图在 Arduino 版本上复制它，但还没有在 AVR Grbl 上这样做。我可以让它偶尔在 ESP32 版本上发生。这是我那边的错误报告。 发生了一些不容易重复的事情，听起来它可能会影响 AVR 版本和 ESP32 版本。我将尝试进行更多调查，看看我是否可以查明什么顺序会导致它起作用。不幸的是，我没有 C/C++ 技能来检查代码本身，但也许我可以弄清楚是什么命令序列导致了我的问题，这可以帮助别人查明 Grbl 代码可能发生了什么。 |
.png "GRBL 与 Bf:14,0 失速 #1507"){kind=avatar}
|
回答最重要的问题：是的，我正在使用 v1.1，似乎我不小心将它发布到错误的项目 – 我将在正确的存储库中重新打开这个问题。 只是为了完整：我既不使用标准 Arduino 也不使用 GUI，我直接从自己的应用程序通过串行接口与 MCU 通信——这就是为什么我怀疑我在这里做错了什么。 |
|
这会让人感到困惑，我们是在这里回答所有帖子的位置，还是在您的新帖子中随机添加评论，我决定三明治填充物在这里。 |
|
请提供您的 Grbl $$ 设置、$I 构建信息输出以及错误时的完整状态报告。 |
它以 57600 bps 的速度运行
这可能是问题所在 – 在每次传输之前添加延迟后，死锁不再发生。但要确保不要因为数据意外发送得太快而被锁定——是否有解决此问题的方法？ |
|
生成状态报告需要时间和资源。我不建议最多每秒查询几次。虽然看起来 Grbl 可以做得更快，但您开始从主程序的其余部分获取资源并将影响系统的运行方式。 |
|
我完全理解这一点，我也接受 GRBL 不会以不可预测的方式做出反应/反应，只要请求速度太快。但我的问题是死锁，一旦我处于这种“Bf：14,0”状态，就不可能与 GRBL 通信，当不再以太高频率发送请求时也无法通信。在这种状态下，必须发出复位信号才能重新获得控制权。这就是我现在正在寻找解决方案的地方，只是为了 GRBL 意外进入这种状态的情况。 |
|
如果您的通信同步，就不会发生这种情况，如果电视上的人说话速度非常快，而您错过了他们在说什么，那么您就很清楚您的设置发生了什么。您所描述的是由您的 GUI 引起的故障，如果您希望问题不发生，那么您需要一种控制数据流的方法。你提到的不可预测的状态是一种故障情况，软复位是没有意义的——GUI/发送者导致数据溢出并挂起处理器。最好的解决方案是为您的 GUI 编写一个更好的通信处理程序，如果 GRBL 按照设计进行通信，它在 99.9% 的情况下都能完美运行。 |
我明白这一点，我同意你的看法。但我的观点有所不同：当电视里的人在某个时候开始说话变慢时，我就有机会理解他们在说什么。 |
|
我想给人留下没有争议的印象，并希望表达为什么除了完全重置之外你不能有任何东西，微型已经停滞，电脑说不。你不会真的想要一个你可以神奇地按下的按钮来重新获得控制权，因为除了胡言乱语和不稳定的控制权之外，你什么也得不到。代码可能会在某个点执行某些操作，而您真的不想返回到同一点。在撞车或重大故障后停止、重置并重新启动总是更好。例如，如果您在铣削圆弧的过程中进行了一半并再次开始，您将得到 3/4 而不是半圆。或者，当您躲避工具以避免工具从夹头中逸出时，您可能会听到尖锐的尖叫声、巨大的机械爆炸声和明显的砰砰声。重置是你的朋友。 |
|
@MeJasonT出现这种通讯问题时，运动是没有问题的！在锁定之前到达控制器的命令被正确处理，唯一的问题是，一旦通信接口被锁定，我就不能再发送任何命令了。因此，如果没有此锁定，只需（缓慢地）发送下一个命令就可以正确继续。 无论如何，谢谢你的帮助！ |
使用 GIT 的最新版本时，我偶然发现了一个奇怪的问题。我很确定我做错了什么，但不知道它可能是什么。我将我的 G 代码流式传输到 GRBL，并通过发送“？”定期检查缓冲区填充水平。并对结果进行评价。我的代码确保命令队列永远不会变满。但在某些时候我回来了
高炉：14,0
这意味着一个命令在队列中并且串行缓冲区已完全填满。令人惊讶的是，此时串行缓冲区不再被处理，无论我做什么我都没有摆脱这种状态并且必须重新启动我的硬件。
那么……知道什么会导致串行缓冲区在完全填满时锁定吗？
谢谢！