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

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

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

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

我做了一些挖掘。

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

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

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

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

这是预期的行为吗？

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

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

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

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

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

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

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

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

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

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

就这样我明白了。=)

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

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

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

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

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

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

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

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

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

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

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

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

我同意所有这些。拥有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();

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

现在，正如您所指出的那样，要使这项工作进行很多更改。它现在应该在发生错误时暂停并将此事件发送到 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

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

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

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

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