@109JB：首先，您能否提供您的 $$ 设置、构建信息字符串和您编译时使用的 Arduino IDE 版本？

其次，您能否发布这个问题程序，以便我尝试重现该问题？

第三，您是否排除了通过运行另一个 GUI 或机器来设置 GUI 或机器等外部影响？

1. 当然。这����$ 信息如下。我正在使用 Arduino IDE 1.6.12。

2. 不确定你所说的“问题程序”是什么意思 GUI 使用用户输入，组装 G 代码行以发送到 GRBL，然后发送它们。发送到 grbl 的实际代码行在 GRBL echoes 的第一篇文章中。在 $$ 设置下方，我在下方粘贴了另一组 grbl 回声。最后一行是它这次挂的那一行，这是一个与第一篇帖子不同的G38.2命令。

3. 至于外界的影响，应该是没有的。我还没有在机器上进行测试，我目前使用的是带有 16U2 USB 芯片和连接到 uno 探针针脚的按钮的 UNO 克隆。

对我的一些 GUI 内容的一些解释。当从 grbl 收到 [PRB: 响应时，我的串行端口解析器开始工作，轴坐标存储在双精度数组中，另一个整数变量用于存储通过/失败位。我对通过失败使用整数而不是布尔值，因为我将其设置为值 3 以表示探测周期已开始。即：0=失败，1=通过，3=探测开始。此外，还有用户定义的最大探测距离值和探测进给率。因此，对于涉及探测器的代码部分，我这样做：

—–获取用户定义的 ProbeDirection、ProbeDistance 和 ProbeRate—–
ProbeResult = 3
SerialPort1.write(“G91G38.2” & ProbeDirection & ProbeDistance & “F” & ProbeRate & vblf)
Do While ProbeResult =3
Application.DoEvents()
Loop
—–获取探测结果 —–
—–做其他事情 —–

我已经确认程序在 Do 循环内等待发生这种情况时从 grbl 接收探测结果。

=======================================

[echo: $I]
[VER:1.1e.20161204:]
[OPT:VM]
ok
[echo: $$]
$0=10
$1=255
$2=0
$3=0
$4=0
$5=0
$6=0
$10= 1
$11=0.010
$12=0.002
$13=1
$20=1
$21=1
$22=1
$23=0
$24=25.000
$25=500.000
$26=250
$27=1.000
$30=1000
$31=0
$32=0
$100=250.000
$101=250.000
$1 = 250.000
$110=1000.000
$111=3000.000
$112=4000.000
$120=200.000
$121=200.000
$122=200.000
$130=200.000
$131=200.000
$132=200.000
可以

===========

[回显：G91G38.2Z-0.3F1]
[PRB:-3.2943,-3.6809,-2.6213:1]
好
[回显：G91G0Z0.100]
好
[回显：G91G38.2Z-0.2F1]
[PRB:-3.2943,- 3.6809，-2.5233:1]
好的
[回显：G91G0Z0.100]
好的
[回显：G91G0X-0.3]
好的
[回显：G91G0Z-0.2]
好的
[回显：G91G38.2X0.3F1]

@109JB: 我的意思是发布有这个问题的 gcode 程序，这样我就可以在我的测试平台上运行它。

就排除 GUI 而言，这是我在调试流媒体问题时尝试的第一件事。如果可能，我通常会尝试针对使用不同串行通信库和不同操作系统的流媒体进行测试。它确保问题出在流的哪一侧。听上去像是 Grbl，但我还是会测试一下。

@chamnit– 好的。将发送的 g 代码如下所示。代码有时会通过，有时会在发送 G38.2 线路后立即挂起，等待 GRBL 的探测响应。此时缓冲区应该是空的，因为 GUI 在发送下一行之前正在等待。我也会在我这边做更多的测试。

G91G38.2Z-0.3F1
G91G0Z0.100
G91G38.2Z-0.2F1
G91G0Z0.100
G91G0X-0.3
G91G0Z-0.2
G91G38.2X0.3F1
G91G0X-0.100
G91G38.2X0.2F1
G91G0X-0.100
G91G0Z0.2
G90G53G0X-3
G91G0Y-0.3
G91G0Z -0.2
G91G38.2Y0.3F1
G91G0Y-0.100
G91G38.2Y0.2F1
G91G0X-0.100

@109JB: 一直在用 G38.3 命令测试这个，而不是 G38.2，因为如果探测失败它不会报警。我没有模拟探针触发器的开关。到目前为止，我没有遇到任何问题。如果您切换到 G38.3，您的工作表现会有所不同吗？

我会检查。不过正在为办公室的圣诞晚会做准备，所以可能要等到明天。

有时间再检查一些。

G38.3好像没什么区别

正如我所说，这是一个自动探测例程。因此，在许多点上，线性 G0 命令紧接在 G38.X 命令之前。我在最近的测试中发现了一些东西。

1. 当问题发生时，它的行为就像 Grbl 处于 Hold 状态，但 Grbl 没有在状态报告中报告 Hold。但是，如果我发送“~”命令，Grbl 会恢复运动并且运行良好。

2. 由于这是一个自动例程，在 G38.X 命令之前立即进行线性 G0 移动，我发现如果我有 GUI 等待 grbl 空闲，然后在发送我不能发送的 G38.x 行之前再延迟 100 毫秒让问题发生。所以它这样做：

发送线性 G0 命令
等待“空闲”
再等待 100 毫秒
发送 G38.x 命令

不确定这是否指向某个方向，但会继续测试。

@109JB： 谢谢。这是一个相当大的线索。这可能意味着探测循环出口的状态机处理可能有点偏离。顺便说一句，我在没有探针的情况下运行我的测试，所以它们总是会到达探针的末端并失败。这意味着我没有切换任何东西来导致 Grbl 停止循环。您是否正在为 G38.3 测试使用探头开关？

是的。我通过观察 DRO 和 grbl 回声响应来启动开关，看看它何时在探测。

在做了更多测试之后，看起来它并没有在探测周期中停止，而是在探测周期之后立即停止，或者一旦读取另一个探测周期，Grbl 就会进入保持类型状态，而不会通知用户它在货舱中。这是我发现的：

G91G38.2Z-0.3F1 ————– 成品精
G91G0Z0.100 ————– 成品精
G91G38.2Z-0.2F1 – ————– 完成精细
G91G0Z0.100 ————–该移动开始但中途停止，就像进入进给保持
G91G0X -0.3
G91G0Z-0.2
G91G38.2X0.3F1 —————— 这是发送到 GRBL 并被回显的最后一条命令
G91G0X-0.100
G91G38.2X0.2F1
G91G0X- 0.100
G91G0Z0.2
G90G53G0X-3
G91G0Y-0.3
G91G0Z-0.2
G91G38.2Y0.3F1
G91G0Y-0.100
G91G38.2Y0.2F1
G91G0X-0.100

它并不总是停在那里，而是总是在 G38.x 命令之后的移动中停止，下一个 G38.x 命令是 GRBL 回显的最后一个命令。正如我所说，机器本质上处于暂停状态，发送“~”命令会重新启动它。当它是这种可疑的进给保持状态时，状态报告显示“空闲”而不是“保持”。非常令人费解。

我在机器上做了一些测试，并在 G38.x 命令之前有一个编程暂停，一切正常。暂停首先​​等待 GRBL 变为“空闲”，然后再等待 200 毫秒，然后再发出下一个 G38.x 命令。今天早上我运行了大约 100 个探测周期，在暂停期间一切正常。

我在店里的时候没想过要这样做，但稍后，我会把暂停注释掉，看看它是否还有问题。我在想，也许只是使用一个按钮进行测试可能与它有关。我会毫不犹豫地报告我的发现。

@109JB： 惊人的。谢谢。您的强制暂停结果表明此错误只会发生在多个连续的探测周期中。另一个好线索。我将在今天晚些时候深入研究代码，看看是否能找到任何东西。顺便说一句，你检查过 v0.9j 是否有同样的问题？

@109JB: 我今天带着我的便携式测试装置。午餐期间，我将一个开关连接到探针引脚，将 v1.1e 闪存到它，并写入您的设置（虽然关闭了软限制）。我一直在下面流式传输您的示例 g 代码，每个测试循环 3 次，使用发送响应协议。（也尝试过字符计数）。经过将近 20 次尝试后，我无法像您描述的那样让 Grbl 锁定。有什么我想念的吗？

G91G38.2Z-0.3F1
G91G0Z0.100
G91G38.2Z-0.2F1
G91G0Z0.100
G91G0X-0.3
G91G0Z-0.2
G91G38.2X0.3F1
G91G0X-0.100
G91G38.2X0.2F1
G91G0X-0.100
G91G0Z0.2
G90G53G0X-3
G91G0Y-0.3
G91G0Z-0.2
G91G38.2Y0.3F1
G91G0Y-0.100
G91G38.2Y0.2F1
G91G0X-0.100

编辑：我正在使用带有执行发送响应协议选项的stream.py流式脚本。-s刚刚将它的更新版本推送到 master 分支。它事先没有使用探测响应。

还没有检查 0.9j。我正在使用的 GUI 是为 V1.1 从头开始​​编写的新 GUI。它不支持旧式状态报告。

@109JB: 你能试试 Grbl stream.py 脚本吗？我今天断断续续地重新运行 g 代码程序，但仍然没有挂起。

@chamnit：今晚我没能回到商店，但我用我的 GUI 和测试装置做了更多测试。我忘记了我已经将波特率设置为 9600，因为我一直在用串行通信测试一些东西。为了测试波特率设置是否与它有任何关系，我重置为 115200，并消除了人为暂停，并在我的测试台上毫无问题地运行了大约 50 个测试周期。然后我将其重置为 9600 波特，并在循环的第二次运行时出现问题。所以看来波特率可以以某种方式触发它。在 115200，我无法重现该问题。我的测试装置是带有 16U2 芯片的克隆 UNO，但我认为这台装置没有 Alex Holden 发布的升级固件。

奇怪的是，它的行为就像在状态响应中没有“保持”的馈送保持。我知道我仍然收到状态响应流，因为我有一个文本标签，它会随着每个状态响应而更新，并且可以看到闪烁的附加信息。是否有可能导致 GRBL 在不更新状态响应中的状态的情况下进入进给保持状态？

@chamnit: 忘了说我的电脑上没有安装 Python。我明天会考虑这样做。

@109JB：可能不需要使用 Python 进行测试。我想我知道问题出在哪里。如果串行 TX 必须等待将字符放入 TX 缓冲区，则它会阻塞其他进程。我认为这是以 9600 波特率运行、启用回声和您可能有报告的组合。当串行 TX 等待太久时，这可能导致探测循环到期。我假设波特率始终为 115200 或更高，并将报告设计为永远不会以该速率填充 TX 缓冲区。修复这个潜在的 TX 缓冲区已经在待办事项列表上有一段时间了，但直到现在才提出问题。如果这是真的，我仍然认为可以肯定地说这不是我需要立即解决的问题。

@chamnit: 抱歉，我忘记了 9600 波特设置。我想我会在 WIKI 已知错误中做一个注释，让人们知道以太低的波特率运行可能会导致不可预测的行为。我想我不会真的认为这是一个“错误”，更像是一个可以忍受的限制，因为通常 115200 无论如何都会被使用。

@chamnit: 在WIKI note上，我去添加了一个简短的note，WIKI页面必须锁定用户编辑。不确定这是不是故意的。

@109JB： 谢谢。Wiki 写入权限是固定的。我还将在 config.h 文件中添加注释。