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

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

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

@ashelly:@chamnit完美地解释了它（第三颗子弹）:)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

@cri-s我的限位开关没有以任何方式连接到我的 EStop，我也没有尝试将硬限位用作 EStop。所以恐怕我跟不上你？

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

关于你的三个建议：

• 启动重置时挂起：这可能是个好主意，但这需要所有 GUI 考虑此状态。尝试使用现有状态或机制来向后兼容可能会更好。
• 在重置/中止期间防止循环启动：不能那样做。如果可以，Grbl 总是执行它发送的所有内容。这是最近在 v0.9h 中更改的。它依赖于 GUI 来管理流式传输的“周期开始”。这样做是为了大大简化 Grbl 的状态机，并且能够不受流式传输和慢跑命令的影响。
• Not reset Grbl when reset goes from active to inactive:我不确定你的意思。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 软复位后，我的物理急停仍然有效。此时它可能不再是真正的“紧急”状态，因此我们可以将其称为正常的“停止/禁用”状态。然后我希望能够与 Grbl 通信（例如验证 GUI 确实看到了正确的状态，即：禁用/EStop’ish），所以现在我可以安全地通过按下我的物理开始按钮来删除 EStop ，从而让 Grbl 控制我的步进器。

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

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

@poelstra：将您的物理紧急停止按钮连接到 Arduino 复位引脚将完成您想要的一切。当您释放时，Grbl 会重新启动到它的通电状态。正如您所提到的，当您的物理紧急停止处于活动状态时，Grbl 运行没有潜在的问题。

正如您的长篇文章所说明的那样，软件紧急停止要棘手得多。没有一个干净简单的解决方案，它可能会涉及对 Grbl 操作方式的大量更改。您仍然可以让 GUI 在他们这边做您需要的事情。Grbl 唯一不报告其状态的时间是出现严重警报（硬/软限制）时，并且 Grbl 明确指出存在警报及其原因。我发现那里没有问题。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在这一点上，如果我打开盒子备份并进行自定义修改，我可能应该分析一下我是否可以在 E-Stop 按钮被锁定时以某种方式至少降低主轴功率。（当我看到它时，我的步进器启用情况到底是什么……）

我想要的是能够以“软件闪光灯”的形式执行此操作。

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

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

@chamnit Yup, that’s exactly what I was thinking! (Plus only triggering abort/reset and limits when they go from inactive-to-active, and preventing exit of the alarm state as long as abort/reset is active.)