好的，我也遇到了。我们需要弄清楚这一点。

数量或值太大？

我不知道代码中的数值是否无关紧要，但那些 G2 命令是非标准的。G2 和 G3 命令要求起点和终点的半径相等。您的 G2 移动的起点和终点在 z 轴上基本上相距 1 毫米，以原点为中心。这意味着半径比 X 起点和终点位置长一根头发。这可能会在数字上消失，但也许不会。我仍在处理咖啡 ATM，但我认为添加 K-0.5 和 K-1.5 是否正确？

一个快速测试是向它发送一个无效的 arc 命令，该命令不会在数字上消失，例如：

G1 X5.0Y5.0
G02 X1.0Y0.0I1.1J1.1

如果这引发了不同的错误或没有错误，那么我会说有一些缓冲区溢出了那些巨大的数字。我的意思是，这是 X 轴和 Y 轴行程为 1 公里的机器，对吗？这不会是用于实际切割的修复方法。:P

也许我应该在第一篇文章中提到它，但我认为 123456797 坐标很明显是假的。
我最关心的不是伪造代码，而是 bCNC 无法加载代码并试图分配无限内存。

我不明白为什么我的 G02 和 G03 代码是非标准的。
G02圆弧怎么会有两个不同的半径？？？
据我了解 G 代码，那么 G02 和 G03 始终是二维圆（通常在（X，Y）中并且添加 Z 不会改变半径，但只会将圆弧（圆）变成螺旋线。

正如我在第一篇文章中所说，我仍在试验这些东西，我的 G 代码和 Python 知识都非常有限。之前发布的G代码是从python脚本生成的，大的伪坐标来自设置不正确的工具半径（到：库中的123456789，忘记将其设置为某个正确的值。）

出于好奇，我将附上生成代码的库。G02 G 代码由“cylinder()”函数生成。
2021-03-27_cnc.py.zip

G02/03 代码可以是 2 维或 3 维……这里是对它们如何工作的相当详尽的描述：

https://www.cnccookbook.com/cnc-g-code-arc-circle-g02-g03/

每个圆弧命令只有一个半径。使圆弧命令无效的原因是它的起点/终点和枢轴点不可信（即起点与终点的半径不同）。

我也不精通 python 或 g bcnc 的任何底层代码。我只是指出这个问题可能是由数值错误引起的……在这种情况下，每单位 xy 行程的 z 移动几乎为零。根据 arc 命令的处理方式，它可能会导致问题（例如，如果规划器进行增量更改，则这些更改可能在数字上全部为零）。想象一下……想象一下 z 在那个角度的微小变化会导致 r 的巨大变化。也可以将此视为 z wrt xy 位置的接近零变化。在寻找数字原因时，这是一个需要重点关注的领域。

也许它根本与此无关……也许某些缓冲区溢出未正确处理？对于这些类型的编程错误，我帮不上什么忙。