此 EStop 功能与边缘分支上的安全门功能有何不同？

@poelstra: 我大约每月一次收到这个问题，最近更频繁。这是我的立场。

• 最佳设置：急停应通过硬接线到 Arduino 复位引脚（不是 Grbl 软复位）来处理。这保证了电源被杀死并且不受编码错误/错误的影响。
• 备用设置：急停应由 GUI 本身处理。如果 GUI 实现 E-Stop 风格的功能，它应该发送软复位并立即停止与 Grbl 的所有通信。软复位将终止所有电源和运动，同时它还将清除规划器和串行读取缓冲区。如果它停止通信，Grbl 就会愉快地闲着。（也许在之后也发送新提议的 $DIS stepper disable。）
• 安全门开关不同于急停。门开关将进行受控的进给保持，然后允许您继续排队的动作。E-stop 应该终止电源，终止工作，并防止任何事情发生，直到用户确认为止。假设急停将迫使您重新设置机器，因为它的严酷性质。

@ashelly：@chamnit完美地解释了它（第三个项目符号）:)

@chamnit: 我同意 EStop 应该主要在硬件中处理（这确实是我所做的）。不过我不同意，将其连接到 Arduino 的复位引脚是最好的设置。

我实际上认为将 EStop 连接到 Arduino 的重置甚至是一个坏主意，因为当它处于重置状态时，我无法验证它是否实际启动正确，是否具有正确的配置，与 GUI 的通信是否符合我的预期，等等。

验证这一点的唯一方法是释放我的硬件 EStop 信号，然后它会启动我的驱动程序并同时启动 Arduino，这将有一个（短暂）周期的未初始化输出引脚，甚至可能看起来已经闪烁错误的固件/设置…

我确实同意，如果 GUI 也知道这种行为，并且可以例如在 $DIS 模式被释放之前保持禁用诸如 Homing 之类的按钮，那将非常有用，但我不介意必须在其上输入 $EN(ABLE) ‘命令行’暂时;）

@poelstra：我认为显而易见的一件事是，根据他们对急停应该是什么的解释，有很多方法可以实施急停。

对于您提到的物理按钮问题，我认为这不是问题。这是 Grbl 上电时的标准行为。您已经有一个现有的过程来处理这个问题。e-stop 表现出相同的行为并非不现实。

虽然不是每个人都会连接（或知道如何）一个物理按钮，但我能做的最好的事情就是提供工具来在 GUI 端实现一个。让 GUI 解释他们自己版本的急停行为。每台机器都不同，可能需要这种类型的灵活性。

最后，Grbl 本身并不是 LinuxCNC 的多合一替代品。它需要一个 GUI，编写一个相当简单。IMO，Grbl 应该尽其所能保持灵活性，并让 GUI 确定特定行为，如急停甚至工具更换。

对于 HW Estop on Reset 引脚，需要下拉，或者在
反转步进引脚的情况下需要上拉。
为了获得更好的急停硬件，应使用。您可以将脉冲线
从微控制器切换
到下拉，其中 Ne555 以低频连接，并且 如果您不想使用爱好 类型的旁路电子限位 开关断开限制，则用于将 cnc 移出开关的瞬间
拨动开关从急停按钮切换。

2015-02-19 16:15 GMT，Sonny Jeon notify@github.com：

@poelstra：我认为显而易见的一件事是
，根据他们对
急停应该是什么的解释，有许多方法可以实施急停。

对于您提到的物理按钮问题，我认为这不是问题。
这是 Grbl 上电时的标准行为。您已经有
一个现有的过程来处理这个问题。
e-stop表现出相同的行为并非不现实。

虽然不是每个人都会连接（或知道如何）一个物理按钮，但
我能做的最好的事情就是提供工具来在 GUI 端实现一个。让 GUI
解释他们自己版本的急停行为。每台机器都不同
，可能需要这种类型的灵活性。

最后，Grbl 本身并不是 LinuxCNC 的多合一替代品。它
需要一个 GUI，编写一个相当简单。IMO，Grbl 应该尽其所能
保持灵活性，并让 GUI 确定特定
行为，如急停甚至工具更换。

---

直接回复此邮件或在 GitHub 上查看：
#604（评论）

@chamnit是的，Grbl 已经支持了广泛的机器和功能，我认为你在所有这些之间取得了很好的平衡！

我一直在思考更多，我同意我正在寻找的大部分内容确实可以通过 GUI 完成（例如，只要“EStop”处于活动状态，就根本不发送运动命令，并且总是发送 $DIS当检测到 Grbl 重置时），尽管来自 Grbl 的固件支持肯定会帮助那些不支持该功能的 GUI 的情况，并使其更可靠。

如前所述，我很高兴为 PR 提供我建议的更改的建议。仅所有三个编译时选项，我认为它们都不过是不同的初始化值或额外的“如果”。
如果你连合并都不考虑，那当然是没用的，不然我就试一试。

@cri-s我没有以任何方式将限位开关连接到我的 EStop，而且我也没有尝试将硬限制用作 EStop。所以我担心我无法跟随你？

@poelstra: 我不确定我是否同意 Grbl 的固件支持会使 GUI 更可靠。如果我们安装您的一些可选建议，这意味着 GUI 必须考虑这些可选条件才能正常工作。需要某种方式来告诉 GUI 构建配置是它所处理的。

关于你的三个建议：

• Suspend on startup-reset：这可能是一个好主意，但这需要所有 GUI 来说明这种状态。尝试使用现有状态或机制来向后兼容可能会更好。
• 在重置/中止期间防止循环启动：不能这样做。如果可以，Grbl 总是执行它发送的所有内容。最近在 v0.9h 中对此进行了更改。它依赖于 GUI 通过流来管理“循环启动”。这样做是为了大大简化 Grbl 的状态机，并且能够与流和慢跑命令无关。
• 当重置从活动变为非活动时不重置 Grbl：我不确定你的意思。IMO 重置应始终重置 Grbl，以免对其操作造成混淆。

我认为我们可以使用现有的警报机制之一来制定基于软件的急停。喜欢@cri-s提到，硬限制是一种做你想要的急停的方法。触发后，它会完全阻止 Grbl 执行任何操作，直到您发送重置命令。也许，可以有一个像“Ctrl-E”或“Ctrl-Esc”这样的实时命令来触发同样的停止/重置机制。

如果您只有 E-Stop，并且希望 gui 能够识别 E-Stop，只需将 DTR 或任何
其他无串行状态线连接到 E-Stop。

对于固件支持，当检测到复位作为 avr 的启动原因时，可能会发出警报。
如果你有归位，它就没什么用了，因为上电后已经处于警报模式。

@chamnit谢谢你的想法！我对可靠性的推理是，GUI 已经“需要”处理启动时的初始归位警报、安全门和您建议的 $DIS 状态等状态。可选条件所做的唯一事情是在此类模式变为活动状态时发生变化，这是 GUI 可以自动处理的事情。所以我认为一切都可以以对任何 GUI 透明的方式实现，只要 GUI 正确处理状态（空闲、警报、禁用……）。

• 启动/重置时暂停：我绝对同意我们应该为此使用现有状态，如果我正确理解 $DIS 将成为新状态，“现有”可能是“新”？
• 在重置/中止期间防止循环启动：嗯，我想你提到你想在 $DIS 状态下防止任何运动，这就是为什么我认为这很容易（一旦实施 $DIS）
• 重置从活动变为非活动时不重置：目前，如果重置/中止引脚（不是 Arduino 的重置，而是 Grbl 的重置）被“触发”，它总是执行软重置。即，如果我将引脚设为低电平，它会软复位，如果我将其设为高电平，它会再次软复位。我认为如果它只在“边缘”之一上进行软复位（可配置，如限制引脚的反转逻辑）会更有用，这样我就可以在 EStop 处于活动状态时使用 GUI“准备”它（我但是仍然无法离开 $DIS 模式），并确保它不会“出现故障”或重置我在释放 EStop 时所做的任何设置。例如，Chilipeppr 会弹出一条“Grbl 已重置”消息，“感觉”好像出了点问题，而实际上它们变得更好了

是的，当前的硬限制行为在某种程度上有点像我想象的那样，但不同之处在于它完全“锁定”了 Grbl：我不能要求设置等。我猜如果硬限制警报机制仍将允许“正常”交互（但当然会阻止移动），这也可能会达到我的目标。

添加 Ctrl-E 或 Ctrl-Esc 当然也是一个好主意，因为它确实与现有的 Ctrl-X 不同，因为 Ctrl-X 可能会启用步进器，而 Ctrl-Esc 也可以禁用它们，就像“硬重启”就可以了。不过，我可能总是使用我的硬件 EStop 按钮，但它可能对想要 EStop 但没有硬件电路的人有用。

@cri-s好吧，我有硬限制和 EStop。我想触发硬限制是否也应该强制 EStop ‘模式’是有争议的，但我的接线方式，它们不可能完全相同：当我的 EStop 处于活动状态时，我的驱动程序没有电源，但我如果之前达到了限制，则“需要”给他们权力以将他们赶出硬限制（“强制限制覆盖模式”）。
而且我认为如果我有归位（我确实有）没有用，因为所有这些讨论的原因之一是，目前可以发出 $H 来摆脱最初的警报，而我的 EStop仍然活跃。Grbl 将愉快地开始发送脉冲（因为驱动程序被物理禁用，所以什么都不做）。如果 Grbl 直接拒绝任何动议，直接指出问题所在，那就更好了。它可以用“只是”一个 GUI 来完成，但是在 Grbl 中获得支持会自动使其在所有 GUI 中工作（好吧，阻止它工作:)）。

请注意，我非常感谢您对此的所有意见！因此，如果我的某些言论由于措辞不当而显得严厉，请原谅，它们绝不是这样的:)

@poelstra: 在急停（或硬限制）期间，与 Grbl 交互的目的是什么？这是紧急状态，应该不会有其他事情发生。

至于$DIS，的确，它可能是一个额外的状态，但它对Grbl的整体操作来说是相当透明的。我仍在思考如何实现它，保持对 GUI 的向后兼容，并确保它在所有场景中都能正常运行。目前，这只是一个提议。

在我的情况下（外部参考：#580），我的机器附带的并行端口驱动器盒包括一个不会切断任何电源的急停开关。我理解你对此的立场，@chamnit的，并且希望有一天能弄清楚如何为盒子制作这样的模组……但现在我试图不修改它的内部电路，这仍然给了我一些基本的“紧急按钮”功能。

我的问题仍然是我可以在按钮仍处于锁定状态时恢复 Grbl，这通常会在我下次需要它时造成糟糕的情况。也许我在这里的用例只是缺乏经验/幼稚，但到目前为止，我使用它的时间并不是完全保证丢失步骤的紧急情况 – 只是想修改部分夹紧或在继续之前仔细检查这个或那个.

添加一个物理提要保持按钮可能真的是我所追求的更多，但即使这样可以解决我的用例，它仍然困扰着我，软件（Grbl 或 PC）无法帮助我记住弹出紧急按钮以备下次使用。

当我正在为这台机器的 Grbl 控制编写自己的界面时（主要是为了体验），我想知道（仍然禁止任何其他解决方案）你是否可以简单地暴露 pin 状态——然后我的 UI 可以拒绝发送任何 $X 直到解决了，没有任何您认为与安全相关的更改？

@chamnit确实，在 EStop 发生的那一刻，有一个紧急状态。所以我然后解决问题，并（软）重置 Grbl（Ctrl-X）。在当前情况下没有真正的麻烦，虽然我认为 GUI 总是可以请求当前状态是很好的。例如，如果我决定 GUI 也处于错误状态（可能是我点击 EStop 的原因），我首先想重新加载它，它需要一种方法来询问当前状态（就像它目前也可以例如，当它正在等待执行归位时）。

但是，在 Grbl 软重置后，我的物理 EStop 仍然处于活动状态。在这个时间点，它可能不再是真正的“紧急情况”，所以我们可以称之为正常的“停止/禁用”状态。然后我希望能够与 Grbl 通信（例如，验证 GUI 确实看到正确的状态，即：禁用/EStop’ish），所以现在我可以安全地通过按下我的物理开始按钮来移除 EStop ，从而让 Grbl 控制我的步进器。

请注意，当时硬限位开关可能仍然处于活动状态（即使我释放了 EStop），我希望有可能将步进器从硬限位中移出。当然，这应该只能通过手动覆盖来实现，例如输入 $X。LinuxCNC 有一个“覆盖限制”复选框，允许您进行一次点动操作，如果硬限制仍然存在，它会再次进入自己的硬限制模式。

我知道 $DIS 仍然是一个提案，这就是为什么我将此场景添加为讨论的输入，特别是对于它确实需要成为额外状态的情况:)

@poelstra：将您的物理急停按钮连接到 Arduino 重置引脚将完成您想要的一切。当你释放时，Grbl 会重新启动到它的加电状态。当您的物理急停处于活动状态时，Grbl 操作没有潜在问题，因为您已经提出。

正如您的长帖子所示，软件急停要复杂得多。没有一个干净简单的解决方案，它可能会涉及 Grbl 操作方式的大量变化。您仍然可以让 GUI 完全按照您的需要进行操作。Grbl 唯一不报告其状态的情况是出现严重警报（硬/软限制），并且 Grbl 明确指出存在警报及其原因。我发现那里没有问题。

我认为你想太多了，我真的不认为有什么问题。请记住，Grbl 不是 LinuxCNC，反之亦然。Grbl 必须谨慎选择，因为它只是 CNC 控制器的一半。另一半是 GUI，就像我之前多次说过的，软件急停应该是一个 GUI 协议。为了帮助解决问题，也许应该发布关于编写软件 E-stop 的推荐方法的 Wiki 描述。

至于硬限制问题，您可以通过“$”设置禁用硬限制，然后点动机器。之后重新启用它们。就个人而言，我认为在使用硬限制时赋予用户移动机器的权力是危险的。最好让他们手动处理问题，因为 Grbl 不可能知道那台特定机器上的情况。如果有人不断达到硬性限制，那么他们真的应该重新评估他们如何使用他们的机器。

@natevw：我听说过关于物理急停开关的反馈问题，但急停确实不应该经常发生，您可以随时连接闪光灯以指示紧急情况。让 Grbl 在检测到急停时提供反馈会很好，但实际上没有必要，特别是考虑到我们必须为其专用一个输入引脚。

@poelstra我不确定我是否理解您为什么不只是使用我们已经拥有的提要保持和恢复输入，为什么不制作一个 grbl 吊坠（可能像这个https://lunaticcharade.wordpress.com/2014/11/ 15/grbl-吊坠/ )

然后将 estop 连接到主轴和电机电源？这样，在我看来，您可以做任何您想做的事情，暂停机器，恢复，停止，关闭电源更改设置？

@natevw没看到你的帖子，不好意思。看来您（几乎）和我有相同的用例。

@chamnit是的，对于我认为是一个小小的变化来说，太多的话。

@skrutt因为进给保持是受控停止（保持位置），而我的 EStop 物理移除电源，因此位置丢失，并且因为只要“保持”（EStop）处于活动状态，GUI 就不能发出恢复。

我认为我想要的大部分（全部？）都可以通过一些非常小的更改来实现，并且可能甚至不需要更改现有的 GUI（尽管如果他们积极理解行为，用户体验可能会更好）。

公关可能会说一千多个单词，所以少说话多编码（从我的角度来看）；）

@poelstra: 一切都没有丢失。我仍在考虑可能的解决方案。

• 也许我们需要的只是一个选项，可以在重启时始终将 Grbl 引导到警报状态。这包括硬接线急停，如果您没有启用归位（因为这已经触发了警报）。
• 硬/软限制不会停止 Grbl，而只是将它们置于暂停而不是锁定的警报模式。所以你有反馈控制。
• 急停实时控制字符，GUI 可以通过挂起模式触发此警报。

总的来说，我认为这不会进入 v0.9，而是进入 v1.0。让这个对话继续下去，并尝试提出一个简单优雅的解决方案，该解决方案既可以向后支持，也可以为当前的 GUI 轻松更新。

我听说过关于物理急停开关的反馈问题，但急停确实不应该经常发生，您可以随时连接闪光灯以指示紧急情况。

那时，如果我打开盒子备份并进行自定义修改，我可能应该分析一下我是否可以在紧急停止按钮被锁定时以某种方式至少切断主轴电源。（当我看到它时，看看我的步进器启用情况到底是什么……）

我想要的是能够以“软件闪光灯”的形式做到这一点。

让 Grbl 在检测到急停时提供反馈会很好，但实际上没有必要，特别是考虑到我们必须为其专用一个输入引脚。

我有点困惑你在这里说什么？我将我的 E-Stop 连接到已经为 保留的引脚 A0，PIN_RESET它的行为与我预期的一样……当我按下按钮时（第一次；-）然后我在 Grbl 中收到警报，它会切断主轴电源并停止移动步进器等。是否可以通过类似的方式暴露现有引脚的状态BITFLAG_RT_STATUS_RESET_PIN？

@chamnit是的，这正是我的想法！（加上仅在它们从非活动状态变为活动状态时触发中止/重置和限制，并且只要中止/重置处于活动状态，就可以防止退出警报状态。）

@poelstra好的，我更了解您现在想要做什么以及为什么。而且我可以看到，我还希望在那些按住会抑制所有动作直到被释放的线条上的东西。对于我的机器，尽管我仍然希望将其分成两个按钮，一个可以按住，另一个仅用于紧急情况和切断电源。
我明白你为什么不愿意重新布线，因为我自己也没有完成所有的布线，在我的 todolist 上获取和布线实际上仍然在我的 todolist 上。

我现在也意识到我以为你也写了@natevws post，想要停止机器以检查一切是否正常是使用进给保持的更典型情况:)

@skrutt呵呵，对，@natevw的和我的用例相似，尽管 Nathan 也描述了更多的 feed-hold 用例。不过，这并不是我真正想要的，因为我认为这已经由现有的进给保持/循环启动和安全门功能处理（尽管我必须承认我自己还没有使用过）。

@poelstra: 有点像你的建议。:) 急停仍然连接到 Arduino 硬复位线，而不是 Grbl 的软复位。

• 一个编译时选项，用于在电源循环或硬复位时强制发出警报，但不是软复位。当用户启用 Grbl 的归位时，这已经是 Grbl 的行为。所以这应该不是问题。当用户上电时，不让 Grbl 自动报警（没有归位）的想法是为了让第一次尝试 Grbl 的新用户变得非常简单。如果您没有带有硬接线急停开关或归位限位开关的机器，您将永远不需要此自动警报。为某些机器和用户类型添加一个编译时选项可能是一个好主意。
• 我特别声明不要在上电时使用此自动警报软复位。软重置不打算用作急停，我认为不应该，因为它的使用过于复杂。
• 仅从非活动到活动不触发。关于这个主题有很长的问题帖子，与硬限制有关。简而言之，如果开关弹跳或存在线路噪声，您不能保证 Grbl 会正确读取开关。已经进行了测试来验证这种行为。只有当你有一个 100%、健壮、过滤的输入时，你才能做这样的事情。几乎所有用户都不会。将急停开关硬连接到 Arduino 硬复位解决了复位问题，但硬限制仍然有点烦人。但是，有一些解决方法。
• 在复位激活时防止警报退出，这是通过将 Estop 硬连接到 Arduino 硬复位引脚而不是 Grbl 软复位来解决的。同样，软重置应该只重置 Grbl，而不是管理急停。此外，软复位并不总是连接到物理交换机，而是与实时命令一起使用。如果您没有开关，则在复位激活时此防止警报的操作是未定义的。同样，这里的解决方案是让 GUI 使用可用工具管理他们的急停版本。
• 添加强制警报可能是一个好主意，该警报的行为类似于 GUI 添加到其工具箱的硬限制警报。在这种情况下，软重置命令会退出，就像在硬限制情况下一样。

作为参考，这是LinuxCNC 的 Integrator’s Manual（第 54 页）对此的说法，这是在我的机器上以这种方式接线的灵感：

这假设 ESTOP 开关连接到 parport 上的引脚 01。只要开关保持按下状态，LinuxCNC 就会处于 ESTOP 状态。当外部按钮被释放时，LinuxCNC 将立即切换到 ESTOP-RESET 状态，您只需切换到 Machine On，您就可以继续使用 LinuxCNC 工作。

@poelstra： 是的。首先，Grbl 不是 LinuxCNC。其次，您可以通过将急停装置连接到 Arduino 硬复位引脚来获得这种精确的行为。

@poelstra: 另外，如果 Grbl 没有响应状态报告实时命令并且没有通知您警报和原因，那么 GUI 可以假设 Grbl 出于某种原因禁用。就像一个E-stop。GUI 只需要声明“Check Grbl”或“Check E-stop”。

@chamnit是的，Grbl 不是 LinuxCNC，但是你在兼容它的很多概念方面做得非常好，而且你现在吸引了不少前 LinuxCNC 的人

我明白你关于让使用“简单”机器的用户保持简单的观点。
我也喜欢将 EStop 连接到 Arduino 复位的简单性，但我真的不同意它与 LinuxCNC 的行为完全相同。

现在，我开始明白为什么我们对此的看法可能会有所不同。我想我认为 Grbl 不仅仅是一个步进脉冲发生器。对我来说，它也是管理机器整体状态的软件部分。我认为 Grbl GUI 更像是对该状态的“视图”。所以这将包括有关加电的知识 -> 启用步进器 -> 哎呀，EStop -> EStop 已发布 -> 重新启用步进器 -> 等等。
也许这确实是因为我脑海中有 LinuxCNC 画面。打个比方，我将 Grbl 视为 LinuxCNC 的实时内核驱动程序部分，并将 Grbl GUI 视为 Axis（LinuxCNC 最流行的 GUI 之一）。

在我看来，将 EStop 连接到 Arduino 的重置，类似于将 EStop 连接到我的 LinuxCNC PC 的重置按钮（如果 PC 仍然有这样的东西 ;)）。也就是说，如果我点击 EStop，整个 PC 会变为空白，直到我释放 EStop，之后它会慢慢启动，在其并行端口上发出一些毛刺脉冲，然后再次显示它的 GUI。

我不认为软重置应该清除“硬限制”类型的警报，即使它仅由 GUI 命令激活。原因是软复位也是“重新同步”Grbl 的“line -> ok”协议所必需的。因此，每个 GUI 都应始终发出软复位，以刷新由于先前的 GUI 通信而存在的任何未决行。我之前并没有真正想到这一点，这确实使是否应该在像这样的软重置时进入禁用模式（警报状态）成为值得商榷的。

拥有这样的东西有意义吗？

• Ctrl-X 软重置，但从不改变状态，GUI 基本上必须从基于行的协议的已知状态开始
• 硬限制导致软重置为硬限制警报状态（如您所建议的）
• 复位/中止引脚变为活动状态会导致 Grbl 软复位到中止警报状态，并且只要复位/中止处于“活动状态”就不能离开
• 复位/中止引脚变为非活动状态会导致转换（不是软复位，不中断 GUI 协议等）进入禁用警报状态。这与我们目前的状态相同，我们需要输入 $H / $X
• 进入 $H 先归家，然后进入 Idle 状态，$X 也是如此
• 上电启动进入 Abort Alarm 状态或 Disabled Alarm 状态，具体取决于 Reset/Abort 引脚的状态
• Ctrl-Esc 软重置为禁用警报状态

当然，只有当人们有限位开关和/或 EStop/Abort/Reset 线时，Abort 和 Disabled 状态才有意义。我们已经定义了“需要$H / $X”模式，所以我们需要另一个定义人们是否有Abort，以及它是低电平有效还是高电平有效。

关于不遗漏例如对引脚更改的硬限制：这是一个很好的观点，我确实在#542 (comment)中阅读了关于它的讨论。

我认为这种竞争条件在实践中并不是一个真正的问题，因为作为@matthijskooijman还注意到，如果人们有弹跳线，则开关将“最终”永久进入其活动状态，并且每次弹跳都会不断发生引脚更改中断，因此最终总会被拾起。
考虑到人们无论如何都会遇到电气问题，这并不是真正的问题。它们有嘈杂的线路，因此在检测到限制之前它们也有“嘈杂”的延迟。
此外，即使在当前情况下，技术上的问题仍然存在：如果尖峰短到足以触发引脚更改，但在我们在 Arduino 中读取时已经清除，它也可以足够短甚至根本不会触发 Arduino 的引脚更改中断。

在离开 Abort（并清除硬限制）时没有意外重置 Grbl 很容易胜过让 Grbl 提前几个滴答检测到嘈杂的限制，IMO。

我希望明天有时间对代码进行一些试验，看看我的想法是否真的可行。

@poelstra: 我觉得你软复位的目的有点糊涂了。它的主要目的是提供一种无需重启即可将 grbl 重置为默认状态的方法。这也恰好清除了缓冲区，因此可以同步流式传输。

软重置永远不会清除硬限制警报，它只会退出任务暂停以强制用户确认问题。之后 Grbl 恢复到 ALARM 状态。这会阻止所有 g 代码命令，但允许用户发送一小组“$”命令来执行他们需要的操作，如果他们需要访问它。’$X’ 仅用于中止警报。软重置不应该释放警报。只有 ‘$X’ 和 ‘$H’ 归位。

此外，如果您在 Grbl 运动时对其进行软重置，则执行此操作时会发出警报，因为用户强制 Grbl 立即停止，并且 Grbl 无法再保证位置（可能丢失步数）。这是唯一一次重置会引起警报，而且它肯定会保持这种状态。

我还认为您忽略了用户不会总是使用软复位引脚的考虑，并且可以通过串行协议发送实时字符命令来执行它。如果你试图在开关处于活动状态的情况下强制 Grbl 不释放，那么在根本没有开关的情况下你会怎么做？您必须应对两种不同的情况，这会使事情变得不必要地复杂。

我不同意您的 PC 类比，因为您没有关闭 PC 和 Grbl GUI。这有点极端。而是根据您的类比禁用 LinuxCNC 实时内核。同样，我认为使用硬重置没有问题，因为用户已经有了处理这种情况的上电序列。

我强烈建议您在周末剩下的时间里查看 ALARM 功能以及软重置如何在源代码中与它交互。然后再回来讨论这个。我们已经在这上面浪费了太多的精力和时间。

就目前而言，我仍然认为 Grbl 有一个足够的急停解决方案，带有硬复位引脚，用于那些实际连接到物理急停并有 GUI 模拟的人。我们不能要求 GUI 突然改变 Grbl v0.9 的一切。

后来对于 Grbl v1.0，一年后，我认为我们可以提出一个令人满意的解决方案，让 GUI 更容易知道 Grbl 在紧急停止期间正在做什么。这将使他们有时间追赶和接受。但就目前而言，我认为您的建议在当前条件下行不通，尤其是当您必须处理物理 e-stop 和基于 GUI 的 e-stop 的结合以及它们如何协同工作时，同时保持它尽可能简单。

我的直觉是，Grbl 需要一个专用的急停销来处理像你这样的情况，但我们必须决定为此使用有价值的销是否真的很重要。可以稍微调整警报处理，以便为 GUI 提供更好的事件洞察力。

底线是你在哪里画线？Grbl 和 GUI 做什么？很明显，我们不同意这一点。我的总体理念是 Grbl 需要管理的越多，它就越不灵活。如果我们不能达成任何协议，你可以随时分叉并做你想做的事，就像许多其他人所做的那样。Grbl 将继续前进并保持其专注于运动控制的核心竞争力。

我知道软重置目前做了什么，我对不让它改变警报状态的回应是对你的评论：

在这种情况下，软重置命令会退出，就像在硬限制情况下一样。

我已经说过我会停止说话并开始编码，但是你说

让这个对话继续下去，并尝试提出一个简单优雅的解决方案，该解决方案既可以向后支持，也可以针对当前 GUI 轻松更新

并且实际上想出了几乎正是我想要的！

我很困惑，如果我浪费了你的时间，我很抱歉。

@poelstra
让我知道一旦解决了我需要添加到 GrblPanel 中的内容:-) 甚至可以尝试荷兰语翻译。

我和你一样看待 Grbl 和 Gui。
格里特

@poelstra: 我想解决这个问题，但我们必须小心行事。我不同意你的建议的确切实施和一些细节。但是，我认为有一种方法可以通过对警报处理进行一些调整来实现，而不是使用软复位。我认为我们仍然需要继续进行这种对话，但是对于一个轻松的周末来说，它变得有点紧张。我只是建议，在这一点上，退后一步。仔细考虑一下。查看/破解代码。让我们在有机会让事情陷入困境之后重新审视这个问题。就像我之前说的，我们无法更改 v0.9，但需要为 v1.0 实现一些东西。我们有时间。

@poelstra： 好的。我有一些时间让这一切沉入其中，并与我的机械师朋友详细讨论了这一切。

• Grbl 不是 LinuxCNC，但它确实使用基于 NIST 标准的 g 代码描述。机器控制器和行为（通常）是在生产独立 CNC 机器上建模的，比如 Haas 和与我一起工作的专业人员的历史输入。一些关于其行为方式的决定是基于此，以及如何在某些状态下仅通过一条与 Grbl 的串行通信线来保持 GUI 控制。一切都必须通过它，仍然必须发挥作用。因此，看起来 Grbl 是 LinuxCNC 传真，因为它使用相同的 g 代码和定义（这也是 ISO 标准），但这并不是由于其中一些限制。
• 也就是说，很明显，Grbl 中的 ALARM 处理有点复杂，可以清理，但有一种方法可以解决它如何以这种方式结束的疯狂。
  • Grbl 有两个 ALARM 状态。一个严重事件警报和一个正常警报。
  • 关键事件 ALARM 是冻结 Grbl 的东西，就像硬限制一样，带有一个不与 GUI 同步的事件。发生这种情况时，GUI 可能仍在流式传输 g 代码。如果 Grbl 返回到其启动提示，此流式传输将导致 Grbl 将一大堆“错误：警报锁定”发送回 GUI。不完全干净。因此，这种冻结是为了强制 GUI 确认关键事件，转储所有传入的流数据（USB 不是 100% 同步的），并让 GUI 进入警报处理。RESET 退出此关键事件 ALARM 并使 Grbl 进入正常的 ALARM 状态。
  • 正常的 ALARM 不会冻结 Grbl，但它允许即时交互，同时锁定所有 g 代码命令和大多数 Grbl ‘$’ 命令。这允许 GUI 或用户与 Grbl 进行一些最小交互来临时更改某些设置，例如禁用硬限制、取消 ALARM 并通过 g 代码命令手动移动机器，或运行归位循环。RESET 不会取消此警报。它只会将 Grbl 重新初始化为其默认状态。
  • 为了清除正常的警报，Grbl 使用终止$X警报或$H归位循环命令。回想起来，这些命令不应该存在，但需要有一种方法让 GUI/用户在正常警报期间与 Grbl 交互。于是，$X被介绍了。在 Haas 上，RESET 应该在技术上清除警报状态，如果可以的话。我想，这$X可能是清理东西的候选者，但这需要对 Grbl 接口进行大量重构，正如我已经多次提到的那样。
• 这是我现在可以做的：
  • 安装编译时选项以在电源循环时始终发出警报。这是 Grbl 启用归位时的默认行为，因此 GUI 应该可以接受。此选项涵盖需要此行为的机器或用户，但默认情况下，不会启用此选项，以确保新用户入门绝对简单。
  • 安装编译时选项以仅在硬限制 ALARM 处于活动状态时触发它。确实，弹跳开关可能会继续触发硬限制 ISR，并最终可能正确读取引脚。然而，当硬限位开关被释放时也是如此，Grbl 最终将再次读取引脚作为触发。我仍然认为这没有真正的好处，并强烈建议用户使用软限制。在实践中，你永远不应该达到硬性限制。IMO，硬限制应该表现得很严厉，并且 100% 保证机器会停止。我将使用此选项在 config.h 中对此进行评论。
• 这是我认为潜在的重构候选者：
  • 软限制不应像现在 v0.9h 边缘分支那样引发严重事件警报。它可能应该进入一个正常的 ALARM，但是 Grbl 的 g 代码解析器的编写方式以及它如何检查软限制使得这个改变有点困难。问题是 Grbl 应该如何在发生此警报时通知 GUI，以便它可以 100% 确定地停止流式传输。保持原样似乎更容易。
  • 由于 RESET 引脚和 RESET 实时命令发出相同的命令，我认为将 RESET 引脚用作急停引脚是不正确的。这会使 RESET 实时命令复杂化。最好有一个专用的急停输入引脚，以保持分离和简单。问题是，当使用 Arduino 硬复位引脚时，是否真的有必要为此使用宝贵的输入引脚。
  • 关键事件警报和正常警报处理：这肯定需要一些工作，但我现在想不出更好的方法来做到这一点。这是我们必须仔细考虑的事情。如果我们以任何重要的方式改变这一点，我们将不得不给 GUI 时间来更新他们的协议以保持兼容性。也就是说，这将安装在更高版本的 Grbl 上，比如 v1.0。

想法？

@gerritv谢谢，会做的:)

@chamnit感谢您的详细回复！这个周末我自己一直在玩代码，确实遇到了你提到的一些问题，特别是警报状态处理的实现与我脑海中形成的不同，而是从外部观察行为。不过，我真的不会称其为“疯狂” 而且我看到您已经进行了相当多的重构以使事情适应未来。

• 安装选项以始终在警报中通电：我已经实现了一个编译时选项（我目前将其命名为#define ABORT_LOCK），以防止退出警报状态（$X）和归位（$H），只要中止引脚活跃’。如果用户没有将任何东西连接到中止引脚，它实际上应该对用户完全透明，而且我认为 GUI 也将在不改变的情况下处理它。我将做更多的测试，并将其提交到我的 fork 上，让您查看您是否认为它有意义。
• 安装选项以仅在活动时触发硬限制：昨天也实现了，快速测试似乎工作正常。看来我的限位开关确实有一些弹跳，有时这足以在实际离开它时触发额外的硬限制，所以我将安装一些过滤器并在提交之前进行更多测试。

顺便说一句：暂且不谈我想要仅激活中止/复位引脚的触发。它已经这样工作了……看看硬限制代码，我认为中止/重置引脚逻辑也是如此，特别是考虑到我也在我的机器上看到了这种情况（以前从未在 LinuxCNC 上看到过） . 看来我在那个继电器电路上有一些弹跳：-/ 很抱歉上面的噪音！
我在我的示波器上测量到弹跳大约为 1 毫秒，所以我可能从未见过它，因为 LinuxCNC 有一个为该逻辑运行的 1kHz 线程（IIRC）。

• 软限制和关键事件：是的，我明白你在说什么。我花了很多心思（希望）确保只要中止锁定处于活动状态，就永远不会退出警报模式。对于中止锁定，它实际上看起来很简单（仍然需要一些测试；）），但对于其他情况，事情可能会变得更加复杂。
• 出错时停止流式传输：我也考虑过这个问题，有一些想法，但需要仔细考虑一下，然后才能完全愚弄自己；）我认为发回错误流实际上不会但是，这是一个坏主意（在发送指示警报的状态消息之后）。GUI 可以在看到警报状态消息后立即停止流式传输（如果没有，请不要担心，因为 Grbl 会继续发送错误消息）。这将确保流协议保持同步，无需进一步重置等。
• 重置引脚行为：实际上，我在代码中的注释中将其称为“中止引脚”，以减少与 Arduino 的重置引脚的潜在混淆。我确实也想知道有一个专门的急停输入是否更有意义，我认为它确实如此，因为它在功能方面更类似于硬限制，也许可以更好地处理相同的代码/引脚更改中断等。您提到重置引脚和重置实时命令（ctrl-x）执行相同的命令。在我的实现中，我改变了这一点，如果定义了 ABORT_LOCK，复位/中止引脚现在总是（即不仅在运动正在进行时）触发 CYCLE_ABORT 警报。所以这些重置不再相等，但这似乎还不错？
• 关键事件与“正常”警报：目前，关键事件不必是单独的状态，而可以是硬限制和软限制的 OR。保存状态 除此之外，我同意为了使这个更健壮，必须进行相当大的更改。从 GUI 的角度来看，很可能实际上不会有太大变化，但它可能需要进行一些认真的测试，所以实际上可能不是 0.9。

我在玩代码时弹出的一些东西（注释和结构都很好，顺便说一句，感谢一百万:)）

• 明确标记轴是否需要归位可能是个好主意。例如，在软限位警报后不必回家。甚至可能每个轴都有一个单独的“归位”位。
• 我认为protocol_execute_realtime() 中存在竞争条件（实际上是两个），因为在复制例如sys.rt_exec_alarm 和重置其位之间可能已将更多位设置为一个。最好删除 if() 末尾的位重置，并用原子“读取和清除”替换副本。
• 目前处理引脚更改中断中的控制位可能有点棘手，因为触发任何这些位的更改，实际上只会查看“第一个”活动位。例如，更改门针的状态，如果该针仍然为高电平，则会触发复位。在那里安装与我用于检测仅活动硬限制的代码相同的代码可能会有所帮助。
• 拥有“仅活动”触发逻辑还有助于使其他一些代码更简单（在某些情况下甚至更可靠），因为不再需要“手动”读取物理引脚并应用可选的引脚反转，并防止读取物理引脚之间的竞争条件以及它是否已被引脚更改中断拾取。我想它在代码中比在文字中更容易显示，所以我会看看我以后是否可以做一个例子。

嗯，又话太多了。
无论如何，我还有更多的测试要做:)
当我提出我的一些想法时会回复。

问题是当 [soft limit] ALARM 发生时 Grbl 应该如何通知 GUI，以便它可以 100% 确定地停止流式传输。保持原样似乎更容易。

软限制警报是否可以是一个简单的“错误：命令超出软限制”，类似于我发送不受支持或无效的命令？

谢谢，顺便说一下，我应该如何将现有的急停按钮连接到 Arduino 的硬件复位引脚而不是 A0。我正在研究用于将 Grbl 连接到我的机器的屏蔽适配器，我很高兴我在走得太远之前就意识到了这一点。

@poelstra: 让我考虑一下这一切。

@natevw：带有“错误：”响应的软限制是可以的，但它有几个问题。首先，主要问题是它与弧或具有多个运动的任何运动（固定循环）不兼容。您必须在 g 代码解析阶段和进入执行阶段之前明确检查所有排列。Grbl 只是在生成运动时进行检查。第二，对这种情况发出警报可能会更好，因为一些 GUI 只是忽略“错误：”。在这种情况下，如果您继续直播，可能会发生非常糟糕的事情。

至于使用 Arduino 硬复位引脚，请告诉我们它是如何为您工作的。这是一个解决方案，但不是解决方案。这就是我们想要弄清楚的。

对于它的价值，这是对我有用的设置。我在 Mega 上运行修改后的 Grbl。我有一个常高的 E-Stop 开关，当它变低时它会将驱动芯片复位，从而切断电机的电源。我在一个备用引脚上监视相同的信号，当它变低时，我设置了关键事件警报位，就好像它是一个硬限制一样。
这似乎非常适合 a) 实际保护电机，b) 通知 GUI 存在问题，以及 c) 阻止任何进一步的命令，直到释放 E-Stop 按钮并重置 Grbl。

如果我没有备用 IO，我可能会重新使用引脚 A0。鉴于存在相同的串行命令和 Arduino 板的复位按钮，我还没有发现需要专用的硬件复位/中止线。

嗨桑尼，

作为自 1970 年代后期以来一直从事 CNC 工作的人！

在不需要的时候，你的时间被用来保护 Grbl，真是太可惜
了。该设计几乎完美地满足了要求。

您创建的所有功能都显示了
CNC 工程需要的真正扎实的知识，使用 Grbl 作为
完整系统所需的一套软件和硬件的非常关键的 G 代码解释器组件。

所以我说；让我们都让桑尼继续编程，不要
再用琐碎的建议来纠缠他，他会花几个小时来解释
和回应。

问候，

莲花包

发件人：Sonny Jeon [ mailto:notifications@github.com ]
发送时间：2015 年 2 月 23 日 17:51
收件人：grbl/grbl
主题：回复：[grbl] 暂停状态和 EStop 处理（#604）

@poelstra https://github.com/poelstra ：好的。我有一些时间让
这一切沉入其中，并与我的机械师朋友详细讨论了这一切
。

• Grbl 不是 LinuxCNC，但它确实使用基于
  NIST 标准的 g 代码描述。机器控制器和行为（
  通常）是在生产独立 CNC 机器上建模的，比如 Haas 和与
  我一起工作的专业人员的历史输入。一些关于其
  行为方式的决定是基于此，以及如何在某些
  状态下仅通过一条与 Grbl 的串行通信线来保持 GUI 控制。一切都必须
  通过它，仍然必须发挥作用。因此，看起来 Grbl 是
  LinuxCNC 传真，因为它使用相同的 g 代码和定义（这
  也是 ISO 标准），但这并不是由于其中一些限制。

•     That said, it's clear that the ALARM handling in Grbl is bit
  

  令人费解并且可以清理，但是有一种方法可以解决
  它如何以这种方式结束的疯狂。

• Grbl 有两个 ALARM 状态。一个严重事件警报和一个正常
  警报。

• 关键事件 ALARM 是冻结 Grbl 的东西，就像硬
  限制一样，带有一个不与 GUI 同步的事件。发生这种情况时，
  GUI 可能仍在流式传输 g 代码。如果 Grbl 返回到其启动提示，
  此流式传输将导致 Grbl 将一大堆“错误：警报
  锁定”发送回 GUI。不完全干净。因此，这种冻结是为了
  强制 GUI 确认关键事件，转储所有传入的流
  数据（USB 不是 100% 同步的），并让 GUI 进入警报处理。
  RESET 退出此关键事件 ALARM 并使 Grbl 进入正常的 ALARM
  状态。

• 正常的 ALARM 不会冻结 Grbl，但它允许即时
  交互，同时锁定所有 g 代码命令和大多数 Grbl ‘$’
  命令。这允许 GUI 或用户与 Grbl 进行一些最小交互来
  临时更改某些设置，例如禁用硬限制、取消
  ALARM 并通过 g 代码命令手动移动机器，或运行
  归位循环。RESET 不会取消此警报。它只
  会将 Grbl 重新初始化为其默认状态。

• 为了清除一个正常的警报，Grbl 使用 $X kill alarm 或 $H homing
  cycle 命令。回想起来，这些命令不应该存在，但
  需要有一种方法让 GUI/用户在正常
  警报期间与 Grbl 交互。因此，引入了 $X。在 Haas 上，RESET 应该在技术上清除
  警报状态，如果可以的话。我想，$X 可能是
  清理的候选对象，但这需要对 Grbl
  接口进行大量重构，正如我已经多次提到的那样。

•     This is what I can do now:
  

• 安装编译时选项以在电源循环时始终发出警报。
  这是 Grbl 启用归位时的默认行为，因此 GUI 应该可以
  接受。此选项涵盖需要此行为的机器或用户，
  但默认情况下，不会启用此选项，以确保
  新用户入门绝对简单。

• 安装编译时选项以仅在硬限制 ALARM
  处于活动状态时触发它。确实，弹跳开关可能会继续触发硬
  限制 ISR，并最终可能正确读取引脚。然而，
  当硬限位开关被释放时也是如此，Grbl 最终将
  再次读取引脚作为触发。我仍然认为这没有真正的好处，并
  强烈建议用户使用软限制。在实践中，你
  永远不应该达到硬性限制。IMO，硬限制应该表现得很严厉，并且 100%
  保证机器会停止。我将
  使用此选项在 config.h 中对此进行评论。

•     This is what I consider as potential refactoring candidates:
  

• 软限制不应像
  现在 v0.9h 边缘分支那样引发严重事件警报。它可能应该进入一个正常的 ALARM，但是
  Grbl 的 g 代码解析器的编写方式以及它如何检查软限制使得这个
  改变有点困难。问题是 Grbl 应该如何在
  发生此警报时通知 GUI，以便它可以 100% 确定地停止流式传输。
  保持原样似乎更容易。

• 由于 RESET 引脚和 RESET 实时命令发出相同的
  命令，我认为将 RESET 引脚用作急停引脚是不正确的。
  这会使 RESET 实时命令复杂化。最好有一个
  专用的急停输入引脚，以保持分离和简单。问题是， 当使用 Arduino 硬复位引脚时
  ，是否真的有必要为此使用宝贵的输入引脚。

• 关键事件警报和正常警报处理：这肯定
  需要一些工作，但我现在想不出更好的方法来做到这
  一点。这是我们必须仔细考虑的事情。如果我们
  以任何重要的方式改变这一点，我们将不得不给 GUI 时间来更新他们的
  协议以保持兼容性。也就是说，这将
  安装在更高版本的 Grbl 上，比如 v1.0。

想法？

直接回复此邮件或在
#604（评论） GitHub 上查看。
< https://github.com/notifications/beacon/AJvJ0AvGRalxXryclB7f9DIIgXAtOyOqks5
nu2ADgaJpZM4DikjT.gif>

@chamnit我已经提交并将我的建议推送到https://github.com/poelstra/grbl/tree/wip/estop。

我已经使用 Chilipeppr 对它们进行了测试，它无需更改即可接受它们。当它激活时，它的“串行控制台小部件”上可以看到关于中止锁的反馈，但我不敢在它停用时花费更多字节来发送“中止解锁”消息。

我刚刚注意到你已经自己实现了一些，没想到这么快！谢谢。

我的实现与您的实现略有不同，因为当您没有连接中止引脚时，中止锁定选项是“透明的”，硬限制边沿触发也可以处理多个开关同时处于活动状态的情况（没什么大不了的对于硬限制，但同样的技巧可能对处理控制引脚有用）。
我还添加了 no-reset-on-critical-event 选项，它可以节省一些字节并且应该允许 GUI 仍然保持轮询状态（包括限制引脚状态）。

如果您愿意，我很乐意为您的边缘分支提供 PR。

@ashelly大概那时我们也有类似的想法。ABORT_LOCK 的作用几乎相同。

@LotusPack我实际上同意你的看法。我从来没有打算让这个线程像这样爆炸。我只是希望提供我刚刚所做的 3 次提交，希望对某人有用。以后可能还会有其他一些“琐碎的建议”，但只是作为“如果你喜欢就点击合并”的 PR，确实是为了让 Sonny 专注于重要的事情。

@poelstra： 谢谢。我有几分钟的时间来查看代码。

• 我开始热身于在上电初始化之前检查引脚的想法，但这并不能很好地捕获软复位。这取决于其他状态管理才能有效地工作。然而，目前，我仍然认为我们不应该为此使用软复位引脚，尽管它可能会节省一个引脚。如果我不能想出一个替代的解决方案，我最终可能会屈服于你的要求。
  • 由于我已经说过的原因，我认为自动重置严重警报不是一个好主意。主要是它产生了其他问题，例如流没有按时停止，并且在没有时会导致大量过度的反馈混乱。当 GUI 看到严重警报消息“ALARM: xxx”时，它同样容易发送复位。如果您担心 Grbl 在严重事件警报期间未报告其状态，那么在此期间让 Grbl 发送这些非常容易。我想我会添加这个，以便 Grbl 唯一不响应状态查询的时间是 Arduino 被主动禁用或关闭时。这应该使 GUI 更容易知道何时让用户检查急停或查看 Grbl 是否连接到 PC。

一般来说，这些变化，除了我昨晚添加的你的建议之外，是更多的补丁来创建你想要的行为。可能有更好的方法来做到这一点，它不涉及需要考虑所有这些编译时选项的 GUI。我认为将协议更改为可以捕获这些不同场景的单一标准化想法会更好。我将不得不考虑以后的版本。

我有点缺席讨论。
在 Avr 上，您可以测试重置原因：
unsigned char ResetSrc = MCUSR; // 保存复位源
MCUSR = 0x00; // 为下一次复位检测清除

… // 进一步初始化

if (ResetSrc & PORF)
cputs(“PWR RESET\n\r”);
if (ResetSrc & EXTRF)
cputs(“EXT RESET\n\r”);
if (ResetSrc & BORF)
cputs(“BOD RESET\n\r”);
if (ResetSrc & WDRF)
cputs(“WDT RESET\n\r”);

这允许测试它是 SW-Reset (WDT)、Hw-Reset、powerup 还是 BOD（
如果启用）。

格林威治标准时间 2015 年 2 月 25 日 3:50，Sonny Jeon通知@github.com ：

@poelstra： 谢谢。我有几分钟的时间来查看代码。

• 我开始热身于在
  上电初始化之前检查引脚的想法，但这并不能很好地捕获软复位。这取决于
  其他状态管理才能有效地工作。然而，
  目前，我仍然认为我们不应该为此使用软复位引脚，
  尽管它可能会节省一个引脚。如果我不能想出一个替代的解决方案，我
  最终可能会屈服于你的要求。
  • 由于我已经说过的原因，我认为自动重置严重警报不是一个好主意。主要是它产生了其他问题，例如
    流没有按时停止，并且在没有时
    会导致大量过度的反馈混乱。
    当 GUI看到严重警报消息“ALARM: xxx”时，它同样容易发送复位。如果您担心 Grbl 在严重事件警报期间未报告其状态，那么 在此期间
    让 Grbl 发送这些非常容易。
    我想我会添加这个，以便
    Grbl 唯一不响应状态查询的时间是 Arduino 被主动
    禁用或关闭时。这应该使 GUI 更容易知道何时
    让用户检查急停或查看 Grbl 是否已连接到 PC。

一般来说，这些变化，除了我昨晚添加的你的建议之外，是
更多的补丁来创建你想要的行为。可能有更好的方法来
做到这一点，它不涉及需要考虑所有这些
编译时选项的 GUI。我认为将协议更改为
可以捕获这些不同场景的单一标准化想法会更好。我
将不得不考虑以后的版本。

---

直接回复此邮件或在 GitHub 上查看：
#604（评论）

@cri-s： 有趣的。你知道这个复位源寄存器是否是所有 MCU 的标准功能吗？如果是这样，这将是让 Grbl 知道正确处理它们的好方法。

@chamnit看来这是一个标准的 atmega 功能。一个快速的 grep 显示几乎每个 avr-libc 支持的处理器都至少有一个 PORF，除了这些：

matthijs@grubby:/usr/lib/avr/include/avr$ grep EXTRF --files-without-match $(grep \#include.*io io*.h --files-without-match)                                   
io1200.h
io2313.h
io2323.h
io43u32x.h
io43u35x.h
io4414.h
io8515.h
io8534.h
io86r401.h
iom161.h
iom3000.h
iotn11.h
iotn12.h
iotn22.h

请注意，我排除了包含其他 io*.h 文件的 io*.h 文件，因为
这些文件可能会通过该其他文件包含正确的标志，而
不是自己定义标志。

@matthijskooijman: 谢谢，但我间接的意思是如果 ARM 有它。

啊对。那里没有经验:-)

是的，这是每个 MCU（微控制器）都有的功能。

刚刚用STM32F103C8测试过。

上电后设置 PINRSTF 和 PORSTF。
软复位后 PINRSTF 和 SFRSTF 被置位。

测试代码：

// 重置测试：

if (RCC->CSR & RCC_CSR_PINRSTF)
puts(“pin reset\n”);
if (RCC->CSR & RCC_CSR_PORRSTF)
puts(“POW 重置\n”);
if (RCC->CSR & RCC_CSR_SFTRTF)
puts(“软复位\n”);

// 上电：软复位
if (RCC->CSR & RCC_CSR_PORRSTF)
{
RCC->CSR |= RCC_CSR_RMVF;
哔(800, 40);
睡眠（4000）；
NVIC_SystemReset();
}

2015-02-25 14:57 GMT，Matthijs Kooijman notifications@github.com：

啊对。那里没有经验:-)

---

直接回复此邮件或在 GitHub 上查看：
#604（评论）

这是一个古老的讨论，但我有一个问题。

如何使用继电器，以便在按下 EStop 时，其中一个限位开关关闭？这将停止 GRBL 并通知 GUI 警报。

警报的文本将不正确（“警报：硬限制”），但除此之外，不是所有期望的行为都在那里吗？