@tcoleman978: Grbl 非常稳定和可靠，所以它可能与配置有关。你能提供你的 $$ 设置和你的 $I 构建信息输出吗？谢谢。

error:33 也是一个无效的目标。它通常与不正确生成的电弧有关。Grbl 根据 LinuxCNC（慷慨的）指南对 g 代码进行一些基本错误检查。该错误产生于： arc Radius 模式下目标与当前位置相同；增量圆弧半径偏离 0.5mm 或 0.1% 半径（和 0.005mm）。当 G38.x 探测目标与当前位置相同时也会生成此错误，但在您的情况下这不太可能。

有报道称Fusion360在inch模式下生成弧线时Grbl会出现这个问题。它们在 mm 模式下生成时消失。其他CAM没有这个问题，所以我怀疑是Fusion360。如果您使用的是 MasterCAM，我可能需要进一步调查一下。

好的，今晚我下班回家时必须检索配置和构建信息，但是……工作中的设备设置与家里相同并且显示相同的问题如下：
Grbl 1.1f [ ‘$’寻求帮助]
$0=10
$1=25
$2=0
$3=0
$4=0
$5=0
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=0
$22=0
$23= 0
$24=25.000
$25=500.000
$26=250
$27=1.000
$30=256
$31=0
$32=1
$100=160.000
$101=160.000
$102=250.000
$110=10000.000
$111=10000.000
$1.0000 $112=5
$120=800.000
$121=800.000
$122=10.000
$130=100000.000
$131=100000.000
$132=200.000
ok
ok
[VER:1.1f.20170131:]
[OPT:V,15,128]
ok
ok
默认值，主轴最大配置、激光模式和基本轴配置除外X 轴和 Y 轴为 100、110、120、130。
至于错误 33，数学计算没问题。gcode 是在 LaserGRBL 中生成的，并在 MasterCam 上进行了校对，寻找坏的 G2/3 IJ。这也会发生在大文件上，无论它们是在什么上生成的。有时候报一行有多个G代码。这就是为什么我认为它可能是报告的非 16U2 usb 通信问题…..没有这样的运气。

@tcoleman978: 没什么特别的。尽管您已经非常接近 Grbl 可以在 Arduino Uno 上处理的最大步速，并且您的最大行程在 100 米处似乎有点高。你能提供问题文件吗？我想看看我是否可以重现错误。

没有家（还）旅行被设置为“不碍事”的维度。
如何附加 43k 行代码？

不确定是否有其他方法，但通常只是提供链接。Dropbox 可以很好地解决这个问题。

有报道称Fusion360在inch模式下生成弧线时Grbl会出现这个问题。它们在 mm 模式下生成时消失。其他CAM没有这个问题，所以我怀疑是Fusion360。如果您使用的是 MasterCAM，我可能需要进一步调查一下。

问题在于随 Fusion 提供并标记为 GRBL 的后处理器。它不能很好地工作，并且依赖于正确设置的 G28 并将输出工具命令和 GRBL 不支持的其他内容。就像他们从未读过 GRBL wiki 一样！

作为记录， https://github.com/Strooom/GRBL-Post-Processor/提供了一个更好的版本，
它为圆弧提供了额外的精度，不需要 G28，但确实需要一个合适的位置通过 G53 安全使用的位置。它将假定 G54 未设置 WCS，或者如果已设置则使用当前设置（仅限 G54 至 G59）。

所以，额外的数字……在毫米模式下，正常坐标是 3 位数字，弧线是 4 位数字，以英寸为单位，4 位和 5 位数字。
这就是我在SketchUcam中所做的，它似乎是圆弧精度问题的完整解决方案。

好的，这是有问题的程序。
https://www.dropbox.com/s/ohsfn5790o1gm8p/ToddLine.nc?dl=0
如果您有任何问题请告诉我，因为这是我的第一个保管箱。
哦，将最大行程降低到 1000mm 没有任何区别。

我刚刚通过我的接口程序运行了您的代码，并在第 38071 行收到错误 33。

这是第 38070 和 38071 行

G1 X39.496 Y0.045
G2 X39.202 Y0 I-0.293 J-0.045

所以圆弧从 39.496, 0.045 开始
对于编程的 I,J，半径是 0.2432，中心点在 39.257, 0
终点，39.202, 0，离中心只有 0.055，因此不在圆弧上。

因此，Grbl 正确报告错误，因为最终点不在使用 i,j 坐标的弧上

我与 G28、G53、小数位数等无关。

顺便说一句，添加文本文件所需要做的就是像我在这里所做的那样拖放它。

文本文件.txt

@tcoleman978：我可以确认它在第 38071-38073 行失败，从第 38071 行的圆弧开始。我已经运行了两次并在同一个地方失败。这不是随机的，主要是 CAM 软件质量差的问题。对于像这样的非常小的圆弧，CAM 确实应该生成一条线或几条线。G 代码弧在数学上的定位很差，会导致这样的错误。

在 Grbl 方面，我可以开始检查这样的短弧，并在小于一定尺寸时忽略错误，但这不是标准错误。不过老实说，如果您开始遇到这些类型的问题，我认为让您的 CAM 生成 G1 弧而不生成 G2/3 弧会更好。

@109JB: 很高兴知道 txt 文件。

顺便说一句，我对标准的 Fusion 360 后处理器没有任何问题，而且我只使用过英寸。并不是说这是不可能的，但我没有遇到任何来自 F360 帖子的弧形错误。此外，它不依赖于 G28，因为在选择后处理选项时可以关闭 G28。至于工具更改，即使 grbl 不支持 M6T#，但某些 GUI 支持。我的有，我想要 M6T# 命令在那里。编辑 grbl 后处理器文件并不难，如果使用不支持它的 gui，您可以简单地向后处理器文件添加 4 行以创建后处理选项以不更改工具。我刚刚做到了，这些行是：

在 // 用户定义的属性中
添加此行：

useToolChange：真，

或者

使用工具变化：假的，

如果你想让 false 成为默认值

然后，在第 266 行附近，找到这一行：

writeBlock(“T” + toolFormat.format(tool.number), mFormat.format(6));

并替换为这 3 个（实际上只是将上面的行放在 if 语句中）：

如果 (properties.useToolChange) {
writeBlock(“T” + toolFormat.format(tool.number), mFormat.format(6));
}

好的，看来 LaserGRBL 正在喷出垃圾。我还没有运行过整个输出。更糟糕的是 backplotters 没有捕捉到它，当然它发生在 1/2 到 3/4 小时运行快结束时。有什么接近 LaserGRBL 的东西可以工作吗？
到目前为止，感谢您的帮助。是的，拖放 .txt 又简单多了 Thanx ..

您可以在检查模式下通过 Grbl 运行它。只需向 Grbl 发送一个 $C 命令，然后流式传输程序。Grbl 将尽可能快地检查它，并在不实际运行机器的情况下检查这样的错误。我的经验是使用我的流式程序的检查模式以每分钟约 9500 行的速度运行，因此您链接的程序在检查模式下花费的时间不到 5 分钟。

@chamnit @109JB: G(2|3) 弧验证的公差是多少？
我问是因为我似乎也有一些糟糕的 CAM 输出…

G01 X10.75 Y-47.437
G02 X8.271 Y-47.704 I-1.247 J-0.058 : 10.750,-47.437,-0.500 --> 8.271,-47.704,-0.500
; rad1=1.248348 ; from I & J parameters
; rad2=1.249602 ; from dX & dY
; error=0.001254 mm

0.001254mm 是否超出公差？

另外，对于后期处理 gcode 文件以解决此类问题有什么建议吗？

我发现的最佳解决方案是让 CAM 为圆弧移动输出额外的精度数字。 在我维护的 SketchUcam（Sketchup 的 CAM）中进行校对
后，我将其添加到 Fusion360 的 Stroooms 后处理器
https://github.com/Strooom/GRBL-Post-Processor中。

你没有说你是如何生成 Gcode 的，但也许这会帮助你解决这个问题。

谢谢@swarfer
我正在使用 heekscad (heekscam) 生成 gcode，但由于该软件似乎已被废弃，我可能应该转向其他软件。
感谢您的推荐。

回答我自己的问题：“0.001254mm 是否超出公差？”

LinuxCNC 文档说不

[当] 圆弧投影到所选平面上时，从当前点到中心的距离与从终点到中心的距离相差超过 (.05 英寸/.5 毫米) 或 ( （.0005 英寸/.005 毫米）和半径的 .1%）