做了更多的工作，现在有了第一个固定循环。第一个是 G81 钻孔循环，此时，它只适用于 G90，但它是一个开始。

这是 grbl 使用 G81 钻孔循环运行我的铣床以气钻 5 个孔的视频。代码如下：

G90G20G54
G0X3Y3Z1
F10
G81X2Y2Z-1R0.1
G81X3Y2Z-1R0.1
G81X4Y2Z-1R0.1
G81X5Y2Z-1R0.1
G81X6Y2Z-1R0.1
G0X3Y3Z1

https://youtu.be/7gsQeShHsBk

@109JB： 这是太棒了。你有没有更新你的 LinuxCNC 看看他们的新轨迹规划器是否比这个测试表现得更好？

@chamnit

我还没有将我的 LinuxCNC 安装升级到新的。它还没有“正式”发布，我的 cpu 在我的谷仓里，我还没有互联网，这使得现在升级有点问题。话虽如此，安装了新计划器的 linuxcCNC 用户使用相同的步进器设置运行相同的 G 代码文件，并在 2.6 和 2.7 上获得相同的 5:35 分钟，而在 2.7 上他获得了 3:10 分钟。因此，LinuxCNC 中的新规划器确实产生了很大的不同。

话虽如此，我一直在尽可能地开发我的 GUI，并且出于一些原因我决定改变我的方法。首先，对于固定循环的完整实施，GUI 必须跟踪一堆内容以支持 G98/G99 和 G90/G91 等内容。接下来是工具更改，也需要做更多的工作。我也有未来实施 G40-G42 的想法，刀具补偿，这将需要更多的模态值、坐标等跟踪。主要的事情是必须至少向前看 CDC 的一个动作，所以我写了我的 GUI 将来会支持这些功能。

所有这些都需要计算时间，因此它延长了循环时间。我的 GUI 现在可以向前看，并完全解析每一行，并支持固定循环 G81、G82、G83、G85、G86 和 G89，并完全支持 G98/G99 和 G90/G91，但循环时间已到。在甚至不使用固定循环（仅 G0/G1 移动）的 roadrunner 程序中，循环时间约为 3:50，而没有前瞻或固定循环支持的循环时间约为 3:00。一个原因是在前一行完成之前它不会开始处理一行。

它仍然比 LinuxCNC 2.6 的循环时间好很多，但为了尝试优化，我正在重写我的代码以尝试利用可用的多线程功能。沿着这条路，我有一个基本的实现，它在 3:04 的循环时间内运行 roadrunner 代码，而没有启用固定循环或前瞻。这是从开始到 GRBL 完成其缓冲区中的所有内容的实际循环时间。循环计时器在运行结束时等待“空闲”状态，并使用该时间点来计算循环时间。

我还稍微更改了 GUI，使其更大一些，以便更容易实现触摸屏。我一直在玩一个带有旧安卓平板电脑的远程桌面，它工作正常，但我以前版本的小按钮让它很难。这个新界面是 1024 x 600，支持在 10″ 上网本上使用。我是小平台笔记本电脑/上网本的忠实粉丝，其他一些 GUI 太大而无法在它们上使用。我有一个 10″ 上网本我在上面加了一个触摸屏，它会很完美，但我大约一年前卖掉了它。

有些人向我发送了这样的消息，大意是“当 CAM 可以处理它时，为什么还要费心使用固定循环”。如果你总是使用 CAM，这是真的，但我仍然倾向于将我的铣床用作伪手动铣床，大量使用 MDI 来运行它。能够输入固定循环意味着与许多代码相比只有一行代码。特别是当您开始研究啄钻多个孔时。

这是我的新界面，它具有以下更新功能

1. 显示程序进度和缓冲区状态的进度条
2. 循环定时器
3. 用户定义的宏

感人的。
我不确定线程​​是否会为您提供所需的东西，我经常在 gui 未被阻塞等待任何事情的情况下使用事件。下面的一切都完全由串行 IO 事件驱动。各种按钮控制门允许事情继续或不等。

还要过几个月才能开好我的店，六月底才搬进房子。与此同时，自 2014 年 11 月以来遭受严重的机加工退回！

在此期间，我非常乐意提供编码建议，我的（隐藏的）电子邮件列在我的用户名下。

格里特

@gerritv

谢谢。我很想得到帮助，但我是那些知识不够的业余程序员之一，无法知道该问什么。我知道您可能会嘲笑我的代码，因为我知道我正在做的事情有悖于最佳实践。不过，我学到了很多东西，一旦我学到了一些东西，我就会尝试在整个程序中回过头来纠正这些东西。

我同意串行 IO 事件是驱动大部分周期时间的东西。今天早些时候，我在玩我的第一个版本程序，注意到 GRBL 规划器缓冲区大部分时间几乎是空的，并且在使用固定循环和前瞻活动运行时，读取缓冲区基本上一直是空的。所以，我修改了几行，让它们停止运行，然后计划程序缓冲区在运行期间保持更满，周期时间减少了很多。这让我认为周期时间的增加至少部分是由于 GRBL 规划器缓冲区中没有足够的数据来充分发挥其轨迹规划器的作用。所以，我认为解决这个问题的一部分可能是从简单的调用/响应流协议到更高级的字符计数协议。

我的行解析器也做了一些有助于此的事情。由于它跟踪活动模态值和坐标数据，因此它不会在每一行中重新发送该数据，即使它列在最初读取的代码行中也是如此。它删除了空格和注释，也删除了不必要的坐标精度。这是用户在 GUI 用户设置中定义的，但我将其默认为最多 4 位小数。因此，以 roadrunner 代码为例。每行都有一个 G0 或 G1 模态值和精确到小数点后 6 位的坐标。一个典型的代码块如下：

G0 X0.000000 Y0.000000 Z0.200000
G0 X1.179950 Y4.004260 Z0.200000
G1 X1.179950 Y4.004260 Z-0.100000
G1 X1.179950 Y4.004260 Z-0.100000 Z-0.100000 G1 X12.130900
G1 X1.179900 Y4.004260
G1 X1.175140 Y3.980210 Z-0.100000
G1 X1.175140 Y4.004260 Z-0.100000

我的解析器将这个块减少到

G0X0Y0Z0.2
X1.18Y4.0043
G1Z-0.1
<—此处发送空行
Y3.9802
X1.1751
Y4.0043

这是 248 个字符与 64 个字符（包括 EOL 字符）的差异。我不确定在使用发送/响应协议时有什么不同，但在字符计数协议中，原始代码将两次填充接收缓冲区，而解析和“清理”代码仅 1/2 填充接收缓冲区，潜在地为 GRBL 提供 4 倍的数据用于其前瞻性。

也许@chamnit 可以评论他是否认为以上所有内容都会对周期时间产生重大影响。

再次感谢，

约翰·B。

我继续实施字符计数流协议。我这样做是为了在运行时选择字符计数或发送/响应协议。我进行了几次测试，在大多数情况下，没有明显的区别。最大的区别是在我编写的测试程序中看到的，该程序仅将一个轴增加 0.010 英寸数千次。两者的循环时间分别为字符计数 25.0 秒和发送响应 56.2 秒。显然这不是一个现实的测试，但它突出了字符计数的好处。单从这个角度来看，去字符计数协议上并没有太大的好处。

但是，我发现使用字符计数在其他方面确实有好处。我发现的一件事是，简单地启用包含 G 代码文件的数据网格的滚动可以大大增加循环时间。在禁用滚动并运行 roadrunner 文件的情况下，字符计数和发送/响应在 2:58 时大致相同。使用发送/响应协议时，仅启用滚动会使循环时间增加 37 秒，但使用字符计数时没有变化。在测试字符计数之前，我打算寻找减少滚动对循环时间影响的方法，但现在可能不必这样做。这也可以解决在添加程序为跟踪固定周期和未来 CDC 必须做的所有事情时增加的周期时间>

我想我会提供有关我的 GUI 和固定循环实施的更新。完全实施被证明是一项相当复杂的任务，至少对我来说是这样。对于完整的实施，GUI 必须知道几件事情，这些事情需要跟踪馈送到 GRBL 的每一行。

例如，G81 钻孔循环需要知道退刀模式 (G98/G99)，并且需要知道 G81 循环开始时的 Z 高度。由于 GRBL 缓冲命令，因此不可能简单地查询 GRBL 以了解上一个命令的编程 Z 高度是多少。如果在 G90 绝对模式下，人们会认为可以查看上一行以查看编程的 Z 高度是多少，但这并不那么简单。假设程序只是运行了一堆 X，Y 只移动。这可能意味着先前的 Z 指令是 G81 之前的 1、2 或 200 步。前一个命令也可能是固定循环，在这种情况下，Z 命令是孔的底部，而不是固定循环的终点。因此，这需要为程序的每一行跟踪机器的 Z 位置。

如果让我们说整个程序，包括固定循环都在 G91 中，事情就更复杂了。在这种情况下，您必须跟踪最后一个 G90 Z 命令发出的时间，或者机器在运行开始时空闲的时间。

如果程序切换工作坐标系 (G54-G59)，事情会更加复杂。

我有好几次开始和重写，但我终于在程序运行期间全部工作了。为此，我对所有模态值进行了默认设置，并在用户点击运行按钮时立即检查机器位置和偏移量。由于它是如此复杂，我还决定进行一行前瞻，以便将来我可以尝试刀具直径补偿 (CDC) 的实施。现在，我正在跟踪 41 个不同的值，并跟踪它们的 1-前一步、2-当前和 3-下一步。之前的移动是因为固定循环需要知道其中的一些值，例如 G98/G99、之前的 Z 结束位置等。接下来的移动纯粹是为了 CDC。我基本上跟踪了 LinuxCNC 将拥有的所有内容，即使在 GRBL 或我的 GUI 中不支持，所以将来我不会

我现在遇到的问题是它在完全执行 G81、G82、G83、G85、G86、G88、G89 的程序运行期间完美运行，但我必须弄清楚如何使其在 MDI 输入期间运行。MDI 期间的固定循环是我最初想要的。我认为我的方法是不允许 MDI，除非 GRBL 处于空闲状态并且我可以从 GRBL 状态响应中获取机器位置。另一个警告是我会默认使用 G98 缩回模式，除非 G99 专门位于 MDI 输入线上。实质上是在 MDI 期间使 G98/G99 成为非模态的。我的另一个选择是从与 grbl 的第一次连接开始跟踪这 41 个参数，或者在它看到包含“Grbl”的响应时跟踪这 41 个参数，这表明硬重置或软重置。

仍在努力，但没有足够的时间来做我想做的事情。我的妻子似乎认为我应该在空闲时间做其他事情！！！！

必须跟踪状态是 gcode 规范中比较不幸的事情之一。要中途启动程序，您必须运行它并跟踪在此之前发生的所有事情，以确保所有模式都设置正确。太可怕了。如果有帮助，我一直在考虑花一些时间编写一个完全兼容的 gcode 解析器，GUI 可以获取和使用它。问题是找到完成它的时间和动力。（将包含宏 B，以便 GUI 可以自动执行自定义机器任务）

grbl/grbl-sim#3 的一些变化会有帮助吗？它基本上可以让您在 PC 上编译 grbl gcode 解析器，并为您提供相同的输出。我可以想象把它变成 ac 图书馆。从那里可以很容易地为大多数现代语言提供语言绑定。
（这周我应该有时间重新调整那个 PR。）

使用 regex 和 select-case 的解析器实际上还不错。不确定最好的方法是什么，但我是这样做的

1- 删除空格
2- 全部转换为大写
3- 使用正则表达式删除注释
4- 使用正则表达式拆分命令词（G1、F100、X10 等）
5- 使用 select-case 和一些 if thens 来放置它在适当的位置进入我的跟踪阵列。

我只用了 2 个正则表达式命令就可以做到。不确定有多少代码行，但一点也不长。

我遇到的最大问题是试图只跟踪我需要的东西，却忘记了一些东西。那当然需要一些重写。然后越来越多。然后我最终决定只跟踪一切，不管我是否需要。另外，我从来都不是一个非常优秀的程序员，而且从字面上看，我已经好几年没有做过任何编程了，这让我放慢了速度。

我还有一些事情想做，完成后我想把它交到一些用户手中。我想您可能会认为他们是 alpha 测试人员，但我计划到那时已经准备就绪。

可能还要再过一两周，因为我还有一些其他事情需要处理。

祝我好运

我终于有时间在我的 GUI 上做更多的工作，但遇到了一个令人费解的情况。在测试一些东西时，我发现 G2 和 G3 命令无法正常工作。他们不是沿弧线移动，而是简单地从起始位置直线移动到最终位置。这是一个 GRBL 上传，在大约一个月左右的时间里一直运行良好，在此期间没有进行任何更改。我发现这不是由于我的 GUI，而是 GRBL 发生了一些事情。我使用一个简单的串行监视器发送 G2/G3 命令来验证它，但机器仍然直线移动而不是弧形移动。GRBL 上传设置为回显命令，GRBL 的回显响应已确认正确。我试过重置和拔掉插头都无济于事。我终于使用 Arduino IDE 重新加载了 GRBL 并重置了修复它的 EEPROM 设置。我应该先尝试重置 EEPROM，但没有。但是，我在 EEPROM 设置中看不到任何可以解释此行为的内容。有没有人遇到过这样的事情？

@109JB：您还记得遇到 G2/3 问题时的版本日期吗？在此期间是否能够看到 EEPROM 设置或存储值有任何问题？是某种类型的弧计算会导致这种情况吗？

我不记得像这样的任何特定问题，除了，也许一年前，我修复了罕见弧情况的弧计算。

是的，我应该检查版本日期，但没有，但是当我重新加载 GRBL 时，我没有下载最新的版本，而是使用了我之前加载的版本。所以我应该可以在我回家后向您提供版本日期。我可以告诉你，它是在 6 月底左右从 github 下载的。

当问题发生时，我执行了正常的 $$、$#、$G 和 $N 请求，没有发现任何异常。我的 $N 块如下：

$N1= G90G20G54G17G0G94
$N2= 空

当它最初发生时，虽然我可能已经发出了一个命令来解决问题，所以我按此顺序发送了以下命令：

G90G20G54G17G0G94
F20
G2X0Y0I1J0（起始位置为 0,0,0）

这根本没有任何动静，所以我发送了以下内容：

G2X2Y0I1J0（起始位置还是0,0,0）

这导致线性移动到 x=2 而没有 y 或 z 移动

然后我回到 0,0,0 并发出以下命令

G2X1Y1I1J0

这导致以 45 度角线性移动到 X=1，Y=1

我还使用 G3 尝试了类似的命令，结果类似，只有线性结果。

在这一点上，我重新启动了我的图形用户界面，再次尝试得到相同的结果。然后我使用一个基本的串行监视器发送具有相同结果的命令。然后重新设置 GRBL，结果相同。此时我决定重新加载 GRBL 并重置 EEPROM。正如我所说，我应该先完成 EEPROM 重置，看看 EEPROM 是否是问题所在，但在匆忙中我忘记了执行故障排除步骤。

@chamnit版本日期为 20150620

@gerritv关于线程与串行事件——我在 GrblPanel 中遇到很多意外暂停，可能是因为发送方部分正在等待 GUI 绘制，而在我的设置中，GrblPanel 在带有 Intel 图形芯片的笔记本电脑上运行。我认为线程会提供更好的结果 – 当然，从程序员的角度来看，它们也会使事情变得更加复杂。

@109JB您是否计划添加用于对单个轴进行归零的按钮？自从我第一次尝试 GrblPanel 以来，我就爱上了这个功能。

我一直在研究我自己的 Grbl 控制器（Python、Qt、Linux、开源 – 它在 Github 上），但放弃了它，因为除了时间故障之外，GrblPanel 似乎可以做我需要的一切……

@kfoltman出于这个原因，我目前正在研究（又一个）新的发送者，它使用多个线程和一个异步事件循环。是的，事实证明它非常复杂！它是用 C/GTK+ 编写的，以便在像 RPi 这样的低端系统上提高效率，当它准备好使用时，我将把它作为开源发布。

@kfoltman我的图形用户界面确实能够将轴归零。你只需点击 DRO 的文本，它就会弹出一个框来选择你想要设置的内容。0.000 是默认值，但您可以输入任何内容。例如，如果使用寻边器，您可以输入 0.100。

@kfoltman虽然我没有明确地使用线程，但系统本质上使用线程。GUI 在主线程上，串行响应在它们自己的线程上，我认为一旦发送调用就在它自己的线程上发送。我唯一阻止的地方是第一次读取文件本身，这只会在读取大文件时产生影响，就像激光雕刻一样。
它在带有 Intel 视频的 Intel Atom 上运行愉快。

如果不分析运行时，就不容易确定阻塞的位置。这很少是直观的（根据大量 Z80 和 68000 代码的经验）。
您的动作是否像激光蚀刻那样频繁且小？如果是这样，那很可能是问题所在，因为我还没有实施打包协议。我发送一行，等待确定并发送下一行。例如，您可以通过观察缓冲区和 Q 条来了解 GrblPanel 为 Grbl 提供数据的情况。如果它们通常为空，则很可能是由于 G 代码中的小移动。

@gerritv是的，这种情况发生在由小段组成的详细轮廓上，因此可能是缺少数据队列协议的原因。不幸的是，某些 CAM 程序无法发出圆角的圆弧命令，这使得这种行为更加痛苦。

另一个有趣的事情是，显示的坐标经常滞后于机器的实际运动，甚至是几秒钟。也许原因是它在暂停前没有读取整个缓冲区？我试过更改空闲时间，但找不到合适的设置。

只是更新我的 GUI 现在所在的位置。由于工作和家庭的原因，我没有太多时间来处理它，但最近抽出了一些时间。对于项目的初始阶段，我看到了隧道尽头的曙光。初始阶段的很多内容都是为下一阶段进行设置。

这是 GUI 现在的样子，我想我已经完成了外观。

主窗口功能说明：

最上面的 2 行菜单很容易解释：
文件 – 打开或保存 G 代码文件
连接 – 到 GRBL
设置 – 用于 GRBL 设置、用户设置、端口设置
编辑工具表 – 为工具更改调出工具表（稍后解释） )
Char Count – 这是一个用于字符计数流的临时按钮，它将消失

第二行有通用的 GRBL 命令按钮，以及 5 个用户可定义的按钮（宏）

DRO 面板有工作坐标和机器坐标。要将轴归零，您可以单击轴编号，然后会出现一个窗口，您可以在其中为当前位置设置所需的坐标。例如，如果使用寻边器，您可能希望输入 -0.100″ 而不是输入 0。默认值为 0.000。

点动按钮面板具有用于每个轴的按钮以及用于选择增量或连续点动的按钮。现在只有增量工作。一旦发布带有连续点动的 GRBL V1.0，这将得到修复。下拉框具有慢跑的分级值，但您可以在该框中键入您想要的任何慢跑增量。

左下方的控件用于主轴和冷却液。非常自我解释。

主窗口的右侧是一个选项卡框。一个选项卡用于 MDI 输入和串行端口监控。上面的 MDI 输入面板的工作方式与 LinuxCNC 中的 MDI 非常相似。单行框是您键入的当前 MDI 输入框，上面的框显示 MDI 历史记录。您可以使用向上/向下箭头或单击历史记录框将以前的行放入当前 MDI 输入框。

下面的串行监视器显示 GRBL 发回的内容。有一个复选框，您可以关闭连续的状态报告流。

G 代码文件选项卡是放置要运行的 G 代码文件的位置。有2个盒子。上部是 G 代码文件，下部显示选择“运行”后的运行进度。G代码可以直接在文本框内编辑。

所有的盒子都可以调整大小

Finally, the status strip has the current GRBL state, progress bars for the sending of the file, planner buffer state, receive buffer state, a cycle timer, and a clock.

What is working now:
G81 – drilling cycle
G82 – drilling cycle with dwell
G83 – peck drilling cycle
G85 – Boring cycle (feed in – feed out)
G89 – Boring cycle (feed in – dwell – feed out)

The above canned cycles are fully implemented in both G90 and G91, and remember modal values, so for example, the following 2 lines of code will result in 2 drilled holes, one at x=2, y=4, and to a depth of z=-1″, and the other at x=5, y=7.

G90G98G81X2Y4Z-1R0.1
X5Y7

Tool change is working using a tool table.