哎呀，那太糟糕了。我通过子状态添加到 grblHAL 的简单探测保护也Run应该作为选项添加到 Bart 的端口吗？

我可以将所有更改放在它自己的选项卡中，如果这有助于使它可以接受的话，该选项卡可以通过设置切换。

您是否想添加一个新的探测选项卡（在单独的项目中？），可以通过设置选择：应用程序？如果是这样，我喜欢它，因为它符合应用程序的设计方式。

是的，这行得通，有任何指示让我坚持您对选项卡的预期用途吗？

是的，这行得通，有任何指示让我坚持您对选项卡的预期用途吗？

不知道我明白你上面的意思……

据我了解，您将制作一个更简单的 ProbingView（主选项卡）并更改部分或全部探测选项卡以匹配。我相信您应该可以至少使用ProbingViewModel.cs和Program.cs，如果不是更多的话，可以从现有代码中“按原样”或根据需要子类化/覆盖位。

我会试一试，让你知道去哪里看看。

Bart 创建了一个新设置来防止 $Probe/Protection={Off, Reset, or Feedhold} 问题。我已经用你的探测宏（中心发现）进行了测试，它似乎工作正常，你的代码似乎认识到发生了错误并停止了探测宏。我认为我现在面临的最大问题是；在探测宏期间从意外探测触发中恢复的最佳方法是什么？控制器可能不知道如何摆脱碰撞。似乎需要软重置，然后您从碰撞中慢跑。grblHAL 如何处理这种情况？

我认为我现在面临的最大问题是；在探测宏期间从意外探测触发中恢复的最佳方法是什么？

重来？如果触发了重置，那么您可以慢跑，如果暂停进给，则无论如何都必须执行重置？重置会导致原位丢失？

目前，如果控制器是基于 grblHAL 的，则探测保护由发送方处理，如果在非探测运动期间检测到探测断言信号，则会发出停止命令。停止命令不像软复位那样严厉，但无论如何都可能丢失位置，因此最好重新开始。我想改进 grblHAL 中的探测处理——一些位已经在核心中就位，但仍有工作要做，IIRC 主要在驱动程序级别。

我还注意到当前探测例程的一些局限性。

其中一些有用于快速移动的 G0/G91 指令。
在这些期间，探测状态无关紧要。
如果您犯了错误并设置了错误的参数，您的探针可能永远消失了?

有一些单独的控制器板可在意外触摸时保护探头。
我认为必须有一种更简单的方法来在当前设置中实现这种理想的安全性。

在 G0/G91 命令期间不断检查可能会矫枉过正，至少我的工厂可能不会及时停止。

在探测程序中检查更快的运动就足够了。

由于我们使用 G91 运行更快的运动并且已经存在Rapids feed rate用于探测的参数，因此应该可以将 G93 更改为 G38.3。

如果探头感应到什么，控制器会立即停止运动。
如果没有信号，G38.3 不会报错。

我的探头有大约 1.4 毫米的可接受过冲。
有了它，我可以将我的磨机以高达 800 毫米/分钟的速度运行，并且它仍然会及时停止。
我更喜欢整体上较慢的探测例程和更安全的设置，并且会在探测期间愉快地牺牲每个 G0 命令。

由于 Terje Io 已经完成了出色的工作，我希望这不会有太多的工作无法实施。

G0/G91 命令期间的持续检查

这正是我的计划 – 我应该抽空实施它。它将通过为探测输入启用中断处理在 grblHAL 驱动程序中实现。grblHAL 核心已经有了支持。也有对探针连接输入的核心支持，我应该为此编写一个插件，因为大多数驱动程序都支持可以通过插件代码访问的辅助输入。

顺便说一句，已经有一个必须启用的简单探测保护方案，如果收到探测触发报告，这将停止运动。这样做的缺点是响应时间最坏情况取决于轮询率——默认为 200 毫秒。
它通过检查状态报告选项设置（$10）的“运行子状态”来启用。

业余爱好领域中没有什么比内部中断更好的了，但是辅助故障保护肯定不会造成伤害。

我很乐意在实施时测试探针中断。

我很乐意在实施时测试探针中断。

好的，您使用的是哪个驱动器/板组合？

我正在使用带有通过以太网连接的 T41U5XBB 的 iMXRT1062，也会测试 USB。