当所有命令都刷新到 grbl 时，该条停止。然而 grbl 有它自己的队列，它仍然可以容纳一些命令。也许我应该在末尾添加一个 %pause ，这样运行就可以等到所有命令都被刷新并由 grbl 执行

你好，
谢谢你的回答。这可能是个好主意，这会清空线轴。等待你的改变，我提高探测速度看看。
问候。

当我将探测进给减少到 10 并且 bcnc 只多记录一个点时，当我将进给设置为 200 时没有任何变化。我们可以提高 grbl 的速度吗？

随着新的更新，我相信它应该可以解决这个问题。你能检查一下吗？

嗨 vlachoudis，我刚刚拉了 master 分支，我仍然看到这个问题。

嗨，我认为我有同样的问题：我尝试用 25 个点进行探测，但只保存了 18 个点（100% 完成）：但是探测正在进行到最后的第 25 个点。看图片：

问候

嗨，我注意到了同样的问题。
我通过删除self._gcount += 1Sender.py:651 为自己做了一个本地修复（我自己承担风险，我不鼓励在不了解所有后果的情况下这样做！）。

gcount发送到 grbl 的命令数量与实际数量之间似乎存在差异。在探测期间gcount，在实际发送之前发送到 grbl 的命令数量达到，这表明运行结束。因此，在这一点之后从 grbl 接收到的剩余探测器的任何数据都将被忽略（即使所有剩余探测器都已成功访问）。

问题出在运行期间使用探测点的条件。通过在运行结束时添加一个等待条件，我忘记了同步运行完成的预期行数，所以它在缓冲区中多了一行。@roboduck即使是非 grbl 命令（bCNC 内在），我也在要提交/执行的行和 gcount 中对它们进行计数。然而，WAIT 完成后必须增加 WAIT。

但是我遇到了另一个问题，内部命令 WAIT 一直等到 grbl 的缓冲区为空并且 grbl 报告空闲。有趣的是，grbl 报告在最后（1 或 2）次探测命令之前有几分之一秒的空闲时间。或许@chamnit能否赐教，如何才能知道grbl是否清空了所有buffer，是不是真的空闲了呢？

简而言之，现在它已修复（就像过去一样）但是检查运行状态更安全。抱歉让您久等了，现在我的车库里太冷了:)

@vladchoudis：这听起来像是状态报告中的无意错误。当我有时间的时候，我会看看探测周期后会发生什么。在这种情况下，grbl 可能会报告不确定状态。

我可能是错的，但 Sender.py:651 中计算的行看起来不像内在函数（至少在我在 Win7、python 2.7.2 上的设置中），而是像常规的 grbl 命令，但是 unicode 编码的 u’string’s（因此isinstance(tosend,str) 返回 false）。因此，这些行被计数 2 次，一次在 651 行，一次在 grbl 的“ok”确认时。然后 gcount 可能高于 should 并且 runEnded() 被调用得太早（然后 self.running 变为 false，因此忽略以下探测）。

但是，如果这是故意的行为，我可能又错了……

抱歉，我注意到最近的变化，所以 Sender.py:651 我的意思是这一行https://github.com/vlachoudis/bCNC/blob/master/Sender.py#L658

我尝试的是在 gcount 增加时记录它。在探测周期结束时，它超过了 30，即使只有 20 多行要发送（gcode 和 bCNC 内在函数）。

@roboduck也许如果评估结果 L649 返回一个 unicode，则不应将其计算在内。您能否尝试将 L654 更改为
if isinstance(tosend,str) 或 isinstance(tosend,unicode):
以查看是否可以。

@vladchoudis：是的，我认为这是有道理的，我也在考虑。去测试一下。

@vladchoudis：不幸的是，它只提供了部分帮助。原因是在这种情况下添加空行 (‘\n’) 也会增加来自 grbl 的 ‘ok’ 响应的数量（我的是 0.9j.20150930）。当 gcount 也增加（通过接收“ok”）并且运行将结束（因为 self._gcount >= self._runLines 会更快发生）时，它会变成这种情况。

从 run() 记录：

len(lines) =  14
lines: ['G0Z0.7', 'G0X0Y0', u'G38.3Z-1F1', 'G0Z0.7', 'G0X20Y0', u'G38.3Z-1F1', 'G0Z0.7', 'G0X20Y10', u'G38.3Z-1F1', 'G0Z0.7', 'G0X0Y10', u'G38.3Z-1F1', 'G0Z0.7', 'G0X0Y0']

这是来自终端的转储（在 Autolevel 启动并删除启动命令 G90 之前清除）：

G0Z0.7
G0X0Y0
G38.3Z-1F1

ok
G0Z0.7
ok
G0X20Y0
G38.3Z-1F1

G0Z0.7
G0X20Y10
G38.3Z-1F1

G0Z0.7
G0X0Y10
G38.3Z-1F1

G0Z0.7
G0X0Y0
[PRB:0.000,0.000,-0.693:1]
ok
ok
ok
ok
[PRB:20.000,0.000,-0.520:1]
ok
ok
ok
ok
[PRB:20.000,10.000,-0.461:1]
ok
ok
ok
ok
[PRB:0.000,10.000,-0.653:1]
ok
ok
ok
ok

18x ok
14x G 命令

最后（就在 runEnded() 调用 _monitorSerial() 之前）：
self._gcount: 15
self._runLines: 14

（如果没有结束，gcount 可能会上升到 18）

我希望这将有助于分析此问题的根本原因。

顺便提一句。绝对惊人的应用程序，谢谢！:)

我有点不解。空行应该从“编译”方法中过滤掉，除非它们是表达式的结果，我应该在发件人中修复它。但是，您的输出有问题。’ok’ 由 grbl 为每个发送的命令返回，所以程序发送 14 行而你得到 18 个 ‘ok’ 是没有意义的。

也许我错过了什么，但如果在 Sender.py:L655 中添加了空行，它就会直接转到串行，所以 grbl 回复“确定”。然后那 4 (=18 – 14) 个额外的“ok”响应来自空行（或更好的“\n”），您可以在我发布的输出中看到。

探测命令取自 Tkinter 小部件，它返回一个 unicode 而不是一个字符串，从而导致发送方出现错误同步。我还为将 unicode 视为字符串添加了一个条件。
我还修改了自调匀整中的逻辑。现在它计算在给定限制内有效的探测器，并且即使在“运行”结束后它也会继续添加它们。

此外，我已经消除了在自动调平周期后归零的需要。这取决于用户是否认为他在自动调平之前首先正确地将库存归零。或者从文件中恢复自动级别。
需要避免换刀校准错误，因为零位的位置没有保留。

尝试最新版本后，我无法再重现该问题。似乎它工作正常。谢谢！

谢谢你我关闭了这个问题。当 grbl 将在探测后更正间歇性空闲状态时，我可以恢复更安全的功能。