确保您的程序中没有任何 g 代码解析错误。通常 g 代码的前几行设置模式，如定义英寸或毫米模式的 G20/21。如果同一行中有不受支持的 g 代码，Grbl 将忽略整行。在实际运行程序之前修复所有 g 代码错误。

感谢您的快速回复，我会仔细检查代码。我有点困惑，尽管 b/ci 在 v0.8 中运行了完全相同的程序，没有任何问题；然后 10 分钟后，在我切换到 v0.9 后，它以毫米为单位插入英寸。我切换回 v0.8 并且工作正常……

将您的 gcode 上传到pastebin之类的东西然后在此处发布链接可能会很有用

较旧的 grbl 版本在检测到块（行）中的错误时仍然允许设置某些 g 代码模式，v0.9 现在完全抛出整行，这是更正确的。这种变化可能会让一些人感到困惑，但它本来应该是这样的。您遇到的错误类型很常见。像 UGS 这样的 GUI 需要更新他们的流协议以在遇到 g 代码错误时停止程序，以防止用户运行他们的错误程序。

问题解决了！我检查了文件，CamBam 正在将 G20 G90 G64 G40 添加到标题中。我删除了 G64 和 G40，一切正常。我返回并从后处理器的标题中删除了这些并且没有更多问题。
谢谢您的帮助！

我刚才更新了那个后处理器，可能想看看？如果您添加了一些漂亮的东西，请在 CamBam 上与我们分享

@chamnit:

如果同一行中有不受支持的 g 代码，Grbl 将忽略整行。

那是 NIST 规范的一部分吗？

@paulkaplan：NIST 规范指出，当出现错误时，您可以“继续出错”或“出错时停止”。它还声明“任何导致错误的输入行都不会被解释”。所以是的，它是规范的一部分。

我已将其留给 GUI 编写者和用户来区分如何处理错误，是继续还是在出错时停止。机器控制器通常会在检测到错误（也称为警报）并强制用户重置时停止所有进程。我看到的其他方式是控制器会扫描程序并禁止程序运行，直到错误得到修复。UGS 和其他 Grbl GUI 需要为此更改更新其流媒体协议。

嗯，似乎“任何导致错误的输入行都不会被解释”与丢弃整行相冲突，因为这听起来像是导致错误的输入行只是“不被解释”。如果不对其进行解释，则不会导致错误。如果错误发生在行的中间，GUI 没有机会从该错误中恢复。

鉴于为 grbl 生成 gcode 的软件种类繁多，要求 GUI 将可接受的 gcode 列入白名单似乎是自找麻烦。特别是因为该白名单仅来自 grbl 而不是来自 gcode 规范。G20 G90 G64 G40不是模态违规或任何会使其无法接受的 gcode；这只是grbl的错误，所以感觉应该由 grbl 处理。

@paulkaplan： 我不同意。它表示任何输入行，意思是整行，而不仅仅是部分。如果您确实允许 g 代码的某些部分通过，则用户无法在那种情况下判断什么被接受了，什么没有被接受。扔掉整条线会更稳健。

当然G20 G90 G64 G40看起来应该可以工作，但 Grbl 不支持 G64 或 G40。这一切都应该由 CAM 程序的后处理器处理，以创建兼容的 g 代码。Grbl 没有责任说明 CAM 程序的输出类型。恰恰相反。

我确信大多数 CAM 程序都有可编程的后处理器。我愿意将这些后处理模板添加到 Grbl 存储库以帮助解决这些类型的问题，但这些将是严格的用户支持，因为我没有时间或金钱去购买那里的每个 CAM 程序。

@paulkaplan如果控制器出于某种原因不接受某些 G 代码，则生成的程序是不确定的。更改您的 Cam 程序的后处理器，这就是它们都提供此功能的原因。我正在创建的 GUI 有一个“出错时暂停”，以便用户可以决定是否继续。该决定对机器和/或零件有潜在风险。Grbl 提供了一个检查/模拟模式，所以他们真的不是首先在 gcode 中出现错误的借口。正确的解决方案是修复 gcode 程序以适应其运行的控制器。

“如果不进行解释，就不会导致错误。” 一个程序怎么能告诉？这完全取决于意图。如果您的程序依赖于 G40 或 G64 的行为，那么将会出现错误并且您的零件报废。

NIST 文档是 IMO，不是规范，它不是写成一个规范，里面有太多变幻莫测的地方。我不记得看到过一个“可以”或“应该”。它也是古老的，最近是 2000 年？从那时起，加工中心发生了很多变化。此外，每个控制器制造商都有自己的解释。这也是 Cam 公司提供定制输出方式的原因。

此问题的特定情况是由于未使用提供的 Grbl 特定后处理器。它在 CamBam 论坛中提供。

如果控制器出于某种原因不接受某些 G 代码，则生成的程序是不确定的。

绝对是一个好点。我在想一些简单的情况，当一个命令被遗漏时它不会产生后果，但是如果改变了内部设置（比如坐标系）的东西被忽略了，整个程序就是错误的。

我知道这可能是一个黑洞，但后处理器是否有某种“通用”形式？支持 gcode 白名单/功能白名单的东西，以及数字格式等小想法。我必须看一下 CamBam。我为 Vectric 的软件编写了一个使用 Shapeoko w/ Grbl 的软件，但它似乎更多地是关于格式化而不是基于功能的东西，如 G40、G64 等。

CamBam 的 Grbl 帖子已经用 G0/G01 替代品转换/替换了 G81 钻孔。Peck 钻孔更具挑战性，需要在生成 gcode 文件后使用 CamBam 的运行外部程序。您还可以影响前导码 Gcode 来设置程序的参数。最好不要依赖控制器认为初始参数应该是什么。

我不知道一个通​​用的帖子，每个 Cam 程序都有自己独特的风格。控制器人群中显然没有标准化或增强初始规格的愿望。与医学成像不同，在 90 年代末，所有扫描仪和 PACS 公司都觉醒并创建了 DICOM 和 HL7，以便它们可以互操作。（当时我是几个 DICOM 委员会的成员，这就是为什么我知道规格是什么样子的原因:-)