@viewsat我一直使用 bCNC 进行激光编码。关闭渲染

它将在 20 秒内加载。

您可以渲染边界/行程的较小文件。根据我的经验，这归结为您愿意等待渲染多长时间来仔细检查位置或您对 gcode 的信心程度。

Python 的速度不是很快，因此渲染时间可能会很长。我也计划通过发件人的线程进行优化。

你好。
@vlachoudis也许 bCNC 应该在 gcode 文件加载和渲染开始之间警告我们？事实是我希望看到：“加载（在 ram 中）完成（在 XXX 毫秒内），渲染 ram gcode（进行中的 X%）”；）

我不得不说这是 bCNC 最烦人的限制。点击开始，然后等待所有内容加载完毕，即使 GRBL 只能缓冲很少几行 gcode。
我有信心@vlachoudis处理这件事，如果您需要 Beta 测试人员，请告诉我。

期待已久的功能@effer也被其他人要求@wolfmanjm现在在那里。当您按下“运行”并在后台处理剩余命令时，新主控立即对命令进行排队。所以一旦你点击“运行”，响应应该是立即的。你能测试一下吗？

太好了，今晚将是一个测试之夜！

前 50K 行完成！（废木头）

做得好@vlachoudis它瞬间启动，运行平稳，没有问题。没有烦人的等待，很高兴运行代码。谢谢！

唯一的缺点（我知道它现在看起来很“挑剔”）是启动后不久就无法停止，也无法使用软件按钮暂停作业。

@effer恐怕你是对的。准备 g 代码的同一线程也在监视按钮，因此只要 gcode 准备好，GUI 就处于非活动状态。我想我有一个解决方案，我会在今天晚些时候尝试。

在当前母版中，“停止”和“暂停”在提交期间处于活动状态。
此外，为了提高响应速度，我在画布中的绘图中放置了一个 5 秒的计时器。所以如果有一个巨大的文件需要超过 5s 来绘制它会中断渲染。它是用户可在 .bCNC ini 文件中配置的。但是我必须直接从画布上进行更简单的配置。我在想一个下拉组合框，可以直接从 1、2、5、10、20、30、60、无限中选择渲染时间

很遗憾地报告 bCNC 在自行停止后恢复工作的问题仍然存在。
状态栏报告“运行结束”但 bCNC 继续流式传输。您也可以在没有通常警告的情况下退出程序。

大文件似乎更常发生。当点击停止时，我收到此错误：

然后在 5-6 秒后，bCNC 再次自行开始流式传输。

在我正在测试的 linux 中，它工作正常，我无法重现这个问题。可能跟windows有关。

关于如何调试的任何建议？我不能每次都重现，但仍然有最新版本。

你能试试最新版本吗我想我发现了问题

首先让我声明我喜欢这款软件，并感谢所有为它工作的人。

现在关于 Effer 的问题.. 我刚刚经历了同样的事情。我点击停止，bCNC 似乎只是跳到另一段代码并继续在那里工作。它实际上毁了这件作品，但无论如何……我不得不多次点击停止，因为它似乎只是跳到另一段代码来工作。就像代码被分成更小的块一样，因为它太大了（130k 行），点击停止只是停止当前块，而不是后面的其他块。

无论如何..希望这有帮助。

@st0jko您在哪个操作系统中运行？

Windows 10 专业版 x64 和 Windows 7 旗舰版 x86
我只是在 Windows 7 上试用，不得不按停止键大约 10 次。它仍然没有完成，所以我只是退出了程序。

@vlachoudis我可以在 Win7 和 WinXp 中重现。
根据我的测试，Sender.py 中的 stopRun 方法被执行，但 bCNC.py 中的 checkStop 方法没有被执行。

@effer @st0jko你能试试新主人吗？我想我这次找到了。

@vlachoudis第一次测试是成功的。更多测试来自@st0jko欢迎光临。
谢谢！

@effer我的猜测是 Windows 中的 os.sleep(1) 阻塞了 Windows 上的后台线程。

我只是在 PM 中寻求解释。你又读懂了我的想法。
这与我在测试中使用 eneconter 的一些奇怪输出完全兼容。

我非常有信心最后一次提交解决了这个问题。所以我关闭这个问题，除非它再次发生。