更新 – 它仅发生在具有 1 GB 内存和 Atom n450 的笔记本电脑上。i7 6700 +8Gb 内存运行良好。

@inFamousMcGrath尝试关闭控制台窗口，如果这不起作用也关闭可视化工具。如果其中一个或两个都修复了它，我可以调查为什么它们会随着时间的推移而泄漏内存。

我会尝试，但到这个小时还有更多坏消息 – 它甚至在 i7 6700 上也停止了 – 6 小时后，但停止了。我无法停止发送，它不会对我的操作做出反应，只有重新启动才有帮助。有 111000 行，少了之前的文件，大约有 1000000 行。Visualizer 已禁用，但控制台未禁用，我将尝试禁用它。

那个吊坠发送器有很多错误，
希望有人能修复，这将是智能手机的一个很好的应用程序

吊坠是我什至没有考虑的另一个变量。当我完成我现在正在处理的功能时，我将尝试分析代码以找出内存泄漏的位置。在那之前，如果您将吊坠与控制台和可视化器一起禁用，希望问题会消失。如果没有，那么问题比我意识到的要大得多。

所以，关闭控制台对我没有帮助。这很奇怪，它只发生在晚上，当我离开我的工作时））
嗯，我有一些想法，它可以是什么。
发件人没有从 GRBL 收到确切数量的“ok”答案（或者它是一个 UGS 错误），需要继续发送。如果没有来自 UGS 的错误信息——我认为它真的是主要的选择。我建议将 UGS 计数器与详细同步 – GRBL 1.1 队列运动和可用缓冲区的响应数。看起来 Candle 在 GRBL 1.1 中使用了这种方法。但是 Candle 不会使用 Arduino 损坏的答案来操作。
这里的另一个人写了一个可能错误的列表：
a）UGCS 不知何故缺少来自 GRBL 的“ok”响应
b）UGCS 期望的“ok”响应比它应该的多
c) GRBL 在应该返回“ok”时没有返回
d) PC 以某种方式丢失了来自 GRBL 的响应
所以实际上，您需要检查来自 GRBL 的详细消息以了解队列是满的还是空的。因为我用小的微线发送 Gcode，最长 0.05 毫米，所以在 500 毫米/分钟的速度下，它可能是非常快的发送过程，并且在这个过程中不会有任何错误，所以如果我是作者 – 我可能是尽我所能添加最大检查。

@inFamousMcGrath我已经阅读了 UGS 的一些代码库，响应的接收是通过事件发生的，那里没有检查频率——代码通过接收消息触发。

@Siand所以你认为这是 GRBL 问题吗？

我对可视化工具进行了一些更改，这些更改似乎对性能有很大影响。如果问题仍然存在，请重新打开。