开源改变世界!!

在 $C 模式下检测到错误后的错误状态 #759

推推 grbl 1年前 (2023-01-27) 116次浏览
关闭
jahnj0584 打开了这个问题 2017 年 9 月 11 日 · 20条评论
关闭

在 $C 模式下检测到错误后的错误状态#759

jahnj0584 打开了这个问题 2017 年 9 月 11 日 · 20条评论

注释

在 $C 模式下检测到错误后的错误状态 #759

将 grbl 设置为 $c。发送一个因错误 3 而失败的文件,或者它已经尝试解决的任何问题。
即使文件已完成,软重置仍然不会让我点击发送,因为它“正在流式传输”。如果您执行 $x 或软重置,它什么都不做。断开连接然后再次连接会让您返回,但点动控制被禁用。您必须重新启动程序才能解决此问题。
在 $C 模式下检测到错误后的错误状态 #759

在 $C 模式下检测到错误后的错误状态 #759
作者

是的,如果您将文件作为 $c 发送并且它有错误 33 或 20(或可能任何错误),这绝对只是一个问题。
该文件永远不会完成,因为错误,因此 GUI 始终认为它仍在流式传输文件。

在 $C 模式下检测到错误后的错误状态 #759
所有者

前几天我注意到这一点,当流由于错误而暂停时,grbl 处于Check我无法正确处理的模式。

在 $C 模式下检测到错误后的错误状态 #759 绕线器 添加了 漏洞 标签 2017 年 9 月 11 日
在 $C 模式下检测到错误后的错误状态 #759
作者
jahnj0584 评论了 2017 年 9 月 11 日 通过电子邮件
在 $C 模式下检测到错误后的错误状态 #759
作者

可以确认这发生在 Sep10 版本上

在 $C 模式下检测到错误后的错误状态 #759

这个错误一直存在很长时间。
唯一的解决方案是关闭 UGS 并重新启动程序
也希望看到此修复…

在 $C 模式下检测到错误后的错误状态 #759 绕线器 更改了标题 重启时没有点动控制器 在 $C 模式下检测到错误后的错误状态 2017 年 9 月 18 日
在 $C 模式下检测到错误后的错误状态 #759 winder 将此添加到 2.0里程碑 2017 年 9 月 27 日
在 $C 模式下检测到错误后的错误状态 #759 绕线器 提到了这个问题 2017 年 10 月 13 日
在 $C 模式下检测到错误后的错误状态 #759
合作者
布雷勒 评论了 2018 年 3 月 20 日  

我做了一些挖掘。

我将通信器添加到诊断面板以获取更多信息。并重现问题:

  1. 回家我的机器
  2. 归零
  3. 打开UGS测试文件自带的circle.gcode
  4. 使用“检查模式”
  5. 运行该文件并出现以下错误并将其关闭(在我的测试台上这是一个正确的错误,因为如果我尝试在 Z 上达到高于 0 的任何更高值,就会达到软限制):
    在 $C 模式下检测到错误后的错误状态 #759
  6. 单击控制台中的消息告诉我的“软重置”
  7. 点击“Unlock”,因为我们还处于报警状态,但是没有任何反应。控制台不显示正在发送的任何命令。
  8. 在我的自定义 UGS 诊断中刷新当前状态,可以看到通信器仍然暂停,即使我已经进行了软重置。
    在 $C 模式下检测到错误后的错误状态 #759

因此,如果我在 BufferedCommunicator 中添加暂停标志的重置,我现在可以进行软重置并继续:

    @Override
    public void softReset() {
        this.commandBuffer.clear();
        this.activeCommandList.clear();
        this.sentBufferSize = 0;
        this.sendPaused = false; // Add a reset of the pause flag
    }

这是预期的行为吗?

在 $C 模式下检测到错误后的错误状态 #759
所有者

@breiler我认为这只是问题的一个表象。诸如不受支持的 gcode 之类的错误也会导致流媒体暂停,但在这种情况下,不需要重置。

我在 UGS 中处理错误的方式并不理想。这个过程是:

  1. Communicator 类中的简单响应解析器检测到错误并暂停通信器。
  2. GUIBackend 还检测到有错误,并且必须假定通信器已暂停。
  3. GUIBackend 现在必须相应地更新控件状态。我不确定为什么我将检测放在 GUIBackend 而不是控制器中。

第 3 步在检查模式下无法正常工作。从您的屏幕截图中,您可以看到通信器已暂停,但控制器没有。这样做的主要原因是 UGS 依赖 GRBL 来指示它正在发送/空闲/等,并且这些状态不会在检查模式下更新。

我知道有几种方法可以改进:

  1. 添加 aControlState.COMM_CHECK并在意大利面条代码中使用它来处理这一系列事件。处理错误暂停的代码不是很好,它从流式​​传输暂停的BufferedCommunicator开始(在低级别完成以防止在错误后发送其他命令)。然后必须在其他几个地方检测暂停,例如GrblController:rawResponseHandlerAbstractController:commandComplete、 GUIBackend:commandComplete,可能还有其他一些地方。
  2. 添加communicatorPaused事件SerialCommunicatorListener或重新定义void rawResponseListener(String response);void rawResponseListener(String response, Boolean paused);. 通过这些更改中的任何一个,可以在控制器中更直接地处理通信器暂停。
在 $C 模式下检测到错误后的错误状态 #759
合作者

诸如不受支持的 gcode 之类的错误也会导致流媒体暂停,但在这种情况下,不需要重置。

我对我引发的软限制错误感到有些困惑。GRBL 告诉我必须进行软重置。在发送重置命令之前,控制器是否应该从暂停状态恢复?

在 $C 模式下检测到错误后的错误状态 #759
所有者

GRBL 有不同类别的错误。当达到软限制时,GRBL 决定状态不再有效并且无法恢复。所以你是正确的,必须重置 GRBL 才能继续。UGS 在非检查模式下也不会真正处理这种情况,您可以继续尝试慢跑,并且会不断收到错误弹出窗口。

然后是不太严重的错误,如解析错误或无效的 gcode 命令。在这些情况下,GRBL 可以通过跳过命令来恢复。在许多工作流程中,这很常见,例如,我使用的一个 CAM 程序输入了换刀命令 ( M6 T102),这会导致 GRBL 出错。检查错误后,我将单击播放按钮并恢复程序。

在 $C 模式下检测到错误后的错误状态 #759
合作者

就这样我明白了。=)

因此,通过始终暂停 Communicator 并让 Controller 知道,我们可以让 Controller 决定错误的严重性。有些需要重置,有些可以像在 skip 命令中那样处理。

在 $C 模式下检测到错误后的错误状态 #759
所有者

这是一个棘手的问题。以下是有关错误处理线的一些背景信息:Grbl-v1.1-Interface#g-code-error-handling

控制器现在实际上没有意见。它只是根据通信器是否暂停来更新其状态。使事情变得更复杂的是,在某些情况下,通信器即使在不需要时也会暂停(即程序中的最后一个命令或手动命令)。

主要思想是,当发生错误时,程序会停止,并且应该为用户提供足够的上下文来决定接下来会发生什么。

在 $C 模式下检测到错误后的错误状态 #759
合作者

我会看看它是否尝试从您描述的通信器创建一个新的暂停事件。

但是,我的 PR 仍然是正确的,对吗?软重置应该重置通信器的内部状态?

在 $C 模式下检测到错误后的错误状态 #759
所有者

我认为你是对的,我会合并到那个 PR

在 $C 模式下检测到错误后的错误状态 #759
合作者

所以我对此进行了深入研究。

我认为在使用检查模式时最好使用单步执行。我认为因为控制器比响应处理更快,所以当发生错误时它已经开始发送下一个命令。当我们通过暂停机器来处理错误时,它开始报告已经流式传输到控制器的消息的所有错误。

我认为部分解决方案是,当我们在检查模式下启动流时,控制器应该切换到单步执行,而当退出到正常模式时,它应该使用在设置中选择的步进模式。

我想知道 enum ControlState,如果感觉这更像是一个CommunicationState并且非常干净。我相信我们缺少的是一个 ControllerState,它应该具有应用程序 GUI 应该处理的所有状态:JOG、RUN、HOLD、DOOR、ALARM、CHECK 等。这样其他控制器的实现者就更容易知道它们的状态类型需要支持。在我们的例子中,我们知道在 CHECK 状态下,这种特定类型和版本的控制器需要单步执行。

应用程序的其他领域将从中受益。我们有几个地方可以查看状态字符串以确定控制器所处的状态。例如TinyGController:getStateAsString,它有自己的一组与MachineStatusPanel.

在 $C 模式下检测到错误后的错误状态 #759
所有者

我同意所有这些。拥有HOLD/ALARM特别是会简化很多脆弱的代码,这些代码会检查诸如COMM_IDLE && isSending. 像这样的更改可能会面临很高的回归风险,因此需要逐步完成。isSending完全删除像和这样的标志是可能的isPaused

另一个复杂性是 UGS 仍然支持手动管理 GUI 状态的旧版本 GRBL。此模式切换为handlesAllStateChangeEvents()

    /**
     * Indicator to abstract GUIBackend implementation that the contract class
     * will handle ALL state change events. When this returns true it means
     * things like completing the final command in a stream will not
     * automatically re-enable buttons.
     */
    Boolean handlesAllStateChangeEvents();
在 $C 模式下检测到错误后的错误状态 #759
合作者
布雷勒 评论了 2018 年 3 月 24 日  

你是对的,现在不是做这么大的改变的时候,应该逐渐增加。

现在,正如您所指出的那样,要使这项工作进行很多更改。它现在应该在发生错误时暂停并将此事件发送到 GUIBackend。当进入检查模式时,我们切换到单步执行,当我们进入“正常”模式时切换回来。

我现在计算缓冲通信器中的所有命令(活动、缓冲、下一个命令)。注意到我们经常在缓冲区中有剩余内容时挂起。

请看一下代码。要重现该问题,您可以使用此 gcode:

G00 X22.375 Y54.9375
M3 S80
G01 X21.5625 Y54.9375
M5
G00 X21.125 Y54.9375
M3 S80
G01 X20.875 Y54.9375
M5
在 $C 模式下检测到错误后的错误状态 #759 布雷勒 提到了这个问题 2018 年 3 月 24 日
在 $C 模式下检测到错误后的错误状态 #759
合作者

我已经使用 GRBL 0.9j 对其进行了测试,问题似乎也已解决。

在 $C 模式下检测到错误后的错误状态 #759
合作者

@jahnj0584这些更改现在应该在夜间构建中可用。如果您有时间,如果您能确认问题已经解决,我将不胜感激。

这个被引用了2018 年 3 月 26 日
在 $C 模式下检测到错误后的错误状态 #759
作者

今晚我完成这项工作后,我会检查一下。

在 $C 模式下检测到错误后的错误状态 #759 breiler 自己分配了这个 2018 年 4 月 4 日
在 $C 模式下检测到错误后的错误状态 #759
合作者

我正在关闭它,因为我无法再重现它。