这听起来与重现的问题相似@SebKuzminsky在a2694ea中进行测试，并且（表面上）在我的1353895中修复：这是带有重新映射的配置中的起始行错误。

我无法使用最新的 2.7 分支 commit 382e52b根据上面给出的说明重现此内容。没有指定具体的起始行，但我顽强地测试了每一个，但仍然无法重现。

我确实按照说明遇到了一个问题，由于重新映射行号错误，我花了一段时间才弄清楚报告的问题是否被重现：程序源突出显示在跟踪运动的行号时四处跳跃inconfigs/sim/axis/remap/rack-toolchange/nc_subroutines/tool_*_move.ngc而不是停留在M6 T. 这使得很难看到实际执行的源代码行。

我解决了这个问题，方法是在这些文件的开头添加一堆空白，使突出显示消失，并通过将G0变成G1使这些行保持突出显示（这是一个词吗？）更长时间。

当然，该程序的设计目的是从预览中清楚地了解程序执行了多少，因此不应出现混淆。

您能否确认您确实如所报告的那样重现了问题，当使用“从此处运行”时整个文件都在执行，并且您没有将行号跳跃问题误认为是错误地执行的早期行？

我刚刚在全新构建的 master 上运行了示例代码。它不会运行整个文件，但会执行所有工具更改，直至程序启动所在的行。

完整程序：

从第 11 行开始：

我同意@zultron它似乎在 2.7.14 上正常工作

谢谢，@KurtJacobson，我能够在 master 中重现（提交02ba5a1）。

这是由programStartLine实现、重新映射和队列破坏者之间的交互引起的。

该programStartLine功能像往常一样通过排队来自 interp 的命令来工作；然后在任务中，如果尚未到达起始行，则截断 interp 队列。请参阅此处的代码。这样做是因为直接跳到一行而不通过 interp 运行会丢失导致该行的所有设定状态，例如速度、进给和单位等。

在子例程中，interp 队列不会被截断，因为当前行在子例程定义内的某处，甚至可能在不同的文件中，因此将当前行与起始行进行比较是没有意义的。通常情况下，这是可以的，因为 canon 命令在 interp 列表中排队，并且在子例程将控制权返回给主程序之前未发出，并且 interp 列表再次被截断。

然而，M6 重映射在生成器中产生了一个队列nc_files/remap_lib/python-stdglue/stdglue.py破坏者change_epilog()。这导致 interp 将控制权返回给任务，然后任务开始从队列中发出命令。由于自主程序中的上一行以来队列未被截断，因此已在其中排队的任何内容都会被执行。由于队列破坏者在工具更改结尾中，这意味着整个工具更改。

作为@KurtJacobson指出，仅执行起始行之前的换刀，但不执行中间的 G0 程序段。这是预料之中的，因为这些块在主程序中，并且正在按预期被截断。

这一定是在 PR #221之后被破坏的，它修复了change_epilog()函数中的队列破坏者，它已被破坏，如#217中所述。

我解决这个问题的第一个想法是：

• 使用顶层堆栈上下文进行起始行检查；那么即使在子程序或重新映射中也可以截断 interp 列表
• 或者，在任务中添加一个额外的状态位，记录是否已到达起始行，并以此来决定是否截断 interp 列表

无论如何，起跑线功能是一个丑陋、肮脏、粗俗和令人作呕的 hack，即使这个特定问题得到解决，我们也肯定会看到未来的问题。

我们正在努力为 Probe Basic Gui 解决这个问题，有没有人找到解决这个问题的方法？这在大多数控制系统上都是一个非常棒的功能，无论如何只是想看看这里是否有任何东西被重新解决，似乎它已经休眠了。或者是否有解决方法？非常感谢任何帮助！

我不知道这是否会满足您的需要，但我实现了一个“简单的从行开始运行”功能，它只是跳过所有代码到请求的行并开始执行。它在 2.7 上经过了很好的测试，并已基于 2.8 进行了重新设计，但未在那里进行测试。如果您想尝试一下，提交就在这里：mozmck@ 20640d4

这充其量是一种解决方法，并且必须在一条将设置所有需要状态的线上完成重新启动，但这总比我们在许多情况下所拥有的根本没有工作从线运行要好。当外部文件子例程中存在探测例程时，出现此解决方法的情况是一个类似的错误

从生产线运行很困难，因为它要么需要做 G 代码中没有的事情，要么依赖操作员正确设置所有状态。

我认为行为是后者，而且我已经养成了习惯，除了换刀之外，甚至不考虑从任何线路开始。例如，我相当确定 RFL 没有启动主轴。

系统可以在空运行代码时跟踪所有状态信息，然后进行换刀、主轴启动和 G0 到它本来应该在的位置。（可能直接潜入零件）在开始之前。虽然我猜在大多数情况下正确的工具已经到位并且机器将接近它应该在的位置。

我对这听起来像是又一次改组 run-from line 感到紧张，因为我们似乎已经有两个不令人满意的实施。

然而，LinuxCNC 现在正用于许多等离子切割机，如果它们失去电弧，通常需要重新启动。

我几乎开始认为我们可能需要一个 INI 部分来定义特定机器在在线运行时应该具有的行为。

我想知道状态标签有帮助吗？

“一条将设置所有需要状态的线”需要包括圆弧中心模式、增量、半径/直径、单位……

其中大部分都不是问题，但我认为单位和坐标系由 M2 重置，而且很容易忘记。

经历一堆不必要的工具更改真的是一件坏事吗？它至少确保工具更换器状态一致（我认为）

@andypugh如果您查看我的提交，我有一个 INI 选项来选择 RFL 函数。我本来打算在 2.8 中提交它，但显然没有完成——部分原因是我没有时间在 2.8 中测试它。它确实是为等离子切割机中的问题而创建的。我确实认为在线运行中的错误需要在某个时候被解决——或者可能以不同的方式实现，而不是什么@zultron术语“丑陋、肮脏、粗俗和令人作呕的骇客”？

在线运行在 2.8.2 和 Master 中仍然存在问题。
它循环执行所有工具更改，直到起点。
如果用户在在线运行之前启动了主轴，这意味着它将尝试在主轴运行时换刀。（VMC_toolchange Vismach 配置至少做到了这一点，因为 toolchange.ngc 不包含主轴停止命令。）