您使用的是哪个版本的 GRBL？你能分享gcode文件吗？

grbl v1.1e，停止中途作业可以完美地处理较小的文件。
这是 g 代码：holes.txt
我记不太清楚了，但我认为它是由 jscut 生成的，然后使用 bCNC 进行面板化/平铺。

@Harvie感谢您的文件。加载文件并运行一段时间后，我认为这很可能是性能问题。使用数百条短线段制作圆弧的方式意味着处理 GRBL 响应和通知 GUI 需要做大量工作。

我仍然能够暂停作业，但有时我必须点击几次才能响应，这可能是 UGS 处理太多事件导致的某种竞争条件。

现在最奇怪的部分是……您提到作业已完成，但您仍然看到 gcode/ok 消息通过控制台传来并且机器位置正在更新？

是的，IIRC 停止/暂停按钮在第一次点击后变灰，但一切都保持运行。我认为应该有一些东西可以同步线程，所以一旦单击按钮，就不会向机器发送更多的 g 代码命令。如果后台有arc处理，可以在发送结束后单独完成。

我目前正在经历同样的事情。GUI 在雕刻的第一个小时工作，然后我可能在一个小时后得到更新，将经过的时间增加了大约 20 分钟。我在我的控制器上做了一个进给保持，让它闲置 1.5 小时，当我回来时，直到大约 30 分钟后仍然没有 GUI 响应，它赶上了我进行进给保持的点。该工作仍在运行，没有任何问题，我可以在切割完成后进行更新。这是一个 11MB 的 Gcode 文件，我正在为 3D 精加工刀具路径（629,000 行）流式传输。

GRBL v1.1f、Xcontroller、RaspberryPi 3，7 月 23 日每晚半稳定构建。

@BusbyGT我想通过等待来解冻，你可能想尝试完全相反的方法。单击 ugs-platform 中的暂停并等待 looong 时间，然后它 maaaaaybe 会被解开。如果你暂停控制器，ugs 将无法向它发送任何缓冲命令，因此它不会自行清理。但这正是我的想法。还没有真正尝试过。

您可以尝试在运行程序之前关闭控制台选项卡吗？我认为控制台是唯一随时间增长的模块，因此它可能会导致性能问题。

Netbeans 有一个内置的控制台，我一直想试用它来代替我自制的控制台。如果这解决了可能会影响进行该切换的优先级的问题。

我对可视化工具进行了一些更改，可能会解决此问题。我正在关闭它，如果问题仍然存在，请重新打开。