论坛：https ://forum.linuxcnc.org/40-subroutines-and-ngcgui/36030-call-external-subroutine-not-working-in-recent-versions-of-lcnc?start=10#126297

邮件列表（git bisect）：https ://sourceforge.net/p/emc/mailman/emc-developers/thread/CAN1%2BYZV8nr5ZsCWQxbYWtZADhk-w5_cUKo%3DNCcno19kOxLWJzA%40mail.gmail.com/#msg36585666

感谢您的提醒，@andypugh， 我会看一看。

嗯，坏消息。我发现在24ef2fe之前，在一个%-delimited 程序中，调用一个%-delimited sub 也会从第一个文件中关闭子例程文件，%并且该子例程永远不会运行。不同之处在于程序会在此时静默退出，而不是打印令人困惑的消息然后退出。

这是我的测试用例（GH 不允许.tgz文件）。linuxcnc我像这样从RIP 构建树的顶层运行它：

unzip percent-subs-test.zip 
(cd tests/interp/percent-subs/; ./test.sh)

嗯，这很有趣。
我猜是时候再使用一个 Git Bisect 了。

我认为我们首先需要决定是否%应该首先允许 -delimited subs。就个人而言，我对此没有意见，除非之前没有报道过，听起来几乎没有人以 . 开始他们的子文件%，我更喜欢提供合理行为的最简单的修复。

如果答案是%-delimited subs are NOT allowed，那么我们可以在打开的子例程文件中给出更有意义的错误消息。（这是一个简单的修复。）

如果答案是它们是允许的，那么我们可以重用跳过初始部分的代码，如此处所述，在此处附近。Interp::open()%Interp::read_text()

我刚刚检查了ad6c9b5，发现一个（简单的）% 终止子和 % 终止 G 代码文件似乎可以与通过 MDI_COMMAND 调用的子一起工作。
如果从 G 代码调用 sub，我确实看到了带有上述哈希的 sub 的静默忽略。
（论坛上的原始问题是与 MDI_COMMAND 相关的子程序是否有效，具体取决于加载的 G 代码文件的定界符。）

最新的主人在两种情况下和 MDI 窗口中都给出了“在 EOF 之前找不到子” 。

我不确定谁会对应该允许的事情发表意见。通常的嫌疑人都变得非常安静。

据我所知，从快速的谷歌 % 最初标记数据的开始，所以有人可能会争辩说将它放在逻辑上插入正在执行的主文件中间的子程序文件中是不明智的。

我想把我的 2 美分放在这里。由于文件子例程是一个程序，因此它可以而且应该被视为嵌套的 XML 类型的结构。如果文件加载程序检测到一个开头的 %，那么它应该期待一个结尾的 %，这应该很容易实现。如果您不允许在子程序中使用前导 %，则表示编写代码有两种规则，一种用于主流代码，一种用于包含代码。如果您不允许在子例程中使用前导 %，那么您也应该在子例程返回后通过适当的 M2 禁止，或者就此而言，返回后不是被调用子例程文件中的子例程的任何代码。一致性是关键。

这里放两个文件。一个是testcall.ngc，另一个是testexternal.ngc。两者都非常简单。在 testcall 程序中.. 我有一个也在文件中调用的子程序。所以在这种情况下，我使用 % 来分隔整个文件，它运行得非常好。在第二个 testexternal 中，我调用了第一个文件中的子例程，但由于百分比而失败。所以……如果我想是正确的……我将不得不生成第三个文件，（另一个维护..）只包含子例程。但是由于 LinuxCNC 允许我将其他代码放在与可调用外部子程序相同的文件中。我觉得 LinuxCNC 都必须测试并报告外部代码在文件中，甚至验证外部调用程序确实有正确的形成。它不应该 生成比我们今天所拥有的更有意义的错误消息，或者允许 % 进出都没有那么难。的文件。如果 % 是不允许的，那么我也不得不争辩说 m2 应该在子程序文件中被禁止。2 美分乘以四分之一，抱歉……但是当我构建我的子程序时……我从中建模的示例包含 %，并且因为它们曾经在旧版本的 LinuxCNC 中工作……我以为我是金色的.. 感谢收听。

nc_文件.zip

首先，让我重申一下，我不是 G 代码专家，我经常去的 Smid 被打包在一个存储柜 ATM 中。

我想把我的 2 美分放在这里。由于文件子例程是一个程序，因此它可以而且应该被视为嵌套的 XML 类型的结构。

文件子程序真的是程序吗？这对我来说是违反直觉的，因为我看到的所有文件子文件（LCNC 源代码树中的 95%）不包含任何内容o<mysub> sub……o<mysub> endsub如果作为主程序文件运行，它将执行。（我没有计算像tests/remap/variable-injection/rm405.ngcsub 后面的文件m2\n%，这对我来说似乎完全无关，并且在任何情况下都不要从该文件中调用定义的 sub。）这也是违反直觉的，因为在 LCNC 中，子文件是降级到自己的目录中.ini文件，进一步表明它们不打算作为主程序独立运行。我可以想象一个文件作为子程序或作为独立主程序的价值加倍，但即使这在理论上是可能的，但从我所看到的所有迹象来看，这种做法并不常见。

如果文件加载程序检测到一个开头的 %，那么它应该期待一个结尾的 %，这应该很容易实现。如果您不允许在子程序中使用前导 %，则表示编写代码有两种规则，一种用于主流代码，一种用于包含代码。如果您不允许在子例程中使用前导 %，那么您也应该在子例程返回后通过适当的 M2 禁止，或者就此而言，返回后不是被调用子例程文件中的子例程的任何代码。一致性是关键。

我同意一致性是关键。%子例程中并未明确禁止使用前导。相反，它只是你所说的：有两个读取文件的函数，一个用于主程序，一个用于子程序。在#559 (comment)中，我指出了这两个函数的位置。请检查它们。请记住，rs274ngcG 代码解释器（以及src/emc/目录下的所有其他内容）是一大堆不一致之处，几十年来数十名贡献者添加了新的大型功能，但没有明确的组织和体系结构指南，不可避免地导致这样的问题。

同样，对于 G 代码解释器的正确行为是什么，我没有固定的想法，但我确实认为无论我们选择什么，都应该是产生合理行为的最简单的修复。在我赞成实施该修复之前，我想要更有说服力的证据证明允许%-delimited 子文件是有价值的，假设我最终会这样做。

“允许”……这是它在以前版本中的工作方式，新版本没有警告或手动输入表明 LinuxCNC 正在弃用它以前允许的行为。所以，你是对的。另外，子程序的用户相对较少，实际上生成子程序的帖子也很少。所以，是的，这可能是一个外部案例。如果您进行了民意调查……您可能会发现很少……通常被降级为与按钮链接。就个人而言，我们这里有两个问题。

一：LinuxCNC 是否想修复子程序中的 % 问题，或者只是放置一条错误消息来准确说明问题所在，而不是现在那里的钝消息。这对我有用..虽然这意味着不支持向后兼容没有警告。

二：LinuxCNC 是否应该允许子程序文件中的任何其他活动代码，而不是在子程序本身的约束范围内的代码。（活跃的意思不是评论。一个记录良好的子例程文件应该有详细的评论..）这会阻止我用子例程编写代码..我喜欢为测试目的而做的等等……

我对其中一个或两个都满意……我已经做了 50 多年的程序员，所以我理解这个问题……但一致性和定义是关键。Fanuc 子程序调用不同于 LinuxCNC 子程序调用。我正在寻找其他 CNC 制造商的一些例子.. 但我没有找到任何类似的东西。大多数用户似乎使用程序内部的子程序，除了附加到按钮外，不调用外部文件子程序。我相信您会得出一个有助于改进 LinuxCNC 的结论。谢谢！

实际上，以前版本的 LinuxCNC 可能已经“允许”语法，因为没有给出错误消息。但在同样的条件下，结果是子程序根本没有运行，而且没有任何警告。这可能更糟。