通过将 [JOINT_3]MAX_LIMIT 从 50 减少到 40，然后归位并向 Y 最大值移动，可以使用 sim/axis/gantry 配置重现此错误。

我不认为d118ec4是正确的。运动应该在违反软限制时中止，但它不再这样做：

这是一个未修改的 sim/axis/axis，在 master ( 37e6fc4 ) 的当前提示处。我回零并慢跑到接近 X-soft 限制，然后编写了一个违反该限制的 MDI 弧。发出了错误消息，但动作继续完成。

此问题的部分原因在于，当 Motion 处于关节软限制时，Axis 会切换到 Teleop 模式。这会导致任务中永无止境的 NML 问题风暴。禁止切换到 Teleop 可以避免问题风暴。

修复的一部分应该是通过让它优雅地处理到 Teleop 的切换，或者让它拒绝命令来加强 Task 对此的处理。

但修复的另一部分应该是让用户通过慢跑从遇到关节软限制中恢复过来。也许在 identity-kins 机器上，我们应该允许 Teleop-on-soft-limit，并允许 Teleop 在返回有效音量的方向上慢跑。但也许在非 id-kins 机器上，联合限制之外的 Teleop 可能不是一个好主意？也许我们应该强制在非 id-kins 机器上进行自由模式慢跑？

我不确定这里的正确行为和限制是什么，但我有兴趣通过对话达成协议。

对于 identity-kins 机器，完全可以避免这种情况。我看到两个选项：

1. 如果轴限制不在关节限制内，则不应加载配置。
2. 忽略联合限制。

对于非身份亲属，它更复杂。一方面，这是配置错误。另一方面，由于工作包络是一个长方体，有时很想扩展世界限制以获得更大的包络，这意味着要避免关节限制可能咬住的角落（在线性和角坐标中）。但从技术上讲，仍然有可能到达那些角落，所以迟早会受到限制。

在这种情况下可以做什么？停止，抛出警告“超过关节限制”（这就是现在发生的事情）并给用户一个选择（可能通过检查按钮“覆盖软限制”）以任何方式离开那里：在世界或关节模式下慢跑到限制, 或 unhome 到自由模式，或重新回家。在联合模式下，最好在 DRO 中突出显示联合值。
更简单的方法是无力模式。但是在没有原位开关（手动归位）的机器上，从不寻常的位置重新归位可能会很痛苦。而且它仍然不能避免机器在错误点动的情况下损坏。

顺便说一句：我建议为非同一性亲属机器引入圆柱形工作空间限制，在大多数情况下这将是足够的近似值。

在每个人都在 JA 分支上努力创建它们之后，忽略 id-kins 机器的联合限制的想法感觉很奇怪，但也许这样做可以简化（大多数）用户的事情。

如果我们改为在 id-kins 机器上进行关节和轴软限制的加载时间验证，那么当用户使用 src/emc/ini/ 中的接口通过 HAL 设置这些限制时，将需要进行相同的检查。

哦，验证非常简单，只要机器在限制突破时或多或少表现正常，就可以跳过 inihal 更改。

但实际上，为什么我们需要为一个轴 = 关节设置 2 组限制？我认为对于 id-kins 来说，可以安全而愉快地忽略关节限制。这也简化了 INI 文件。

这个设计听起来怎么样：

id-kins机器

在 id-kins 机器上，轴软限制必须完全包含在关节软限制内。我们可以在加载时以及通过 inihal 更改任何软限制时验证这一点。

1. 如果未指定关节软限制的任何部分，则默认为轴软限制的相应部分。
2. 如果关节软限制的任何部分比轴软限制的相应部分更严格，这是配置错误，配置将无法加载（并发出有用的错误消息）。
3. 当用户通过 inihal 设置任何软限制时，将应用 2 中的检查。 开放性问题：这里应该如何处理失败？inihal 引脚是输入，HAL 中没有标准的错误报告机制。
4. 如果出现错误，轴软限制可能仍会被违反（例如，请参见通过软限制的弧的问题 MDI – 通过减加速度量超过软限制。 #80）。
5. Motion 需要一种方法来将轴软限制违反传达给任务和 UI。
6. 用户界面需要一种方法来从轴软限制违规中恢复。轴模式沿指向轴软限制内部的方向慢跑似乎是此处恢复的最佳方式。在解决轴软限制违规问题之前，可能应该禁止其他运动。

非 id-kins 机器

在非 id-kins 机器上，轴软限制可能包含违反关节软限制的点。例如，机器人手臂可能会围绕其底座旋转并到达其底座下方，但不会在其底座实际占据的体积内运行：

1. 有效轴空间不是有效关节空间的子集。如果关节软限制比轴软限制更严格，则不是配置错误。
2. 因此，Interp 和轴模式点动可以接受在轴空间中有效但违反关节软限制的运动。
3. Motion 需要一种方法来将这种联合软限制违反传达给 Task 和 UI。
4. UI 需要一种方法来从联合软限制违规中恢复。沿着关节模式慢跑回到关节软极限内部似乎是最好的恢复方式。在解决关节软限制违规问题之前，可能应该禁止其他运动。
5. 轴软限制违规可能会发生，就像它们在 id-kins 机器上一样（见上文），并且应该以相同的方式处理。 开放性问题：如果我们在解决轴软限制违规时遇到联合软限制违规，我们应该怎么办？下降到关节模式并首先解决该问题，然后恢复轴软限制违规恢复？

听起来不错。
我对非 ID 机器有一些额外的想法。

我们应该区分并联（六足、三角）和串行（机械臂）机械手。

并联机器人通常具有（或多或少）圆柱形或长方体工作空间，轴限制是主要的。我们几乎只需要圆形 XY 限制。

串行机器人的工作空间形状非常复杂。很容易看出它完全是用关节极限来描述的。因此，我们根本不需要串行机器人的世界限制！
因此对于串行机器人来说，关节限位应该是主要的，轴限位可以忽略。它可能需要一些不同的协议来处理联合限制。

此外，检查每一行 G 代码的关节限制是困难的，而且（可能）并不总是可能的。但这不是必需的！我相信笛卡尔 G 代码可以通过完全模拟来验证关节限制。比如说，现场情节与反向亲属相结合（只是一个猜测）。

我认为非长方体轴软限制是一个有趣的想法，但超出了这个特定问题的范围。

轴软限制可能应该由运动学组件指定，但这在 LinuxCNC 的体系结构中引入了巨大的变化，因为 kins 目前是 Motion 的一部分（实时），并且轴软限制需要在 Task 中提供给 Interp（这是非实时的）。随意为这个想法打开另一个问题，但让我们在这个问题上继续讨论，集中在取消打破我们目前拥有的良好的旧长方体轴软限制，这打破了最近与 JA 的合并。

串行机器人的工作空间形状非常复杂。很容易看出它完全是用关节极限来描述的。因此，我们根本不需要串行机器人的世界限制！

我不完全同意这一点。例如，当串行机器人必须在紧凑的机柜中工作时，将需要世界限制或其他临时工作空间限制功能。