“Regular Expression Pattern Remover”配置中有什么吗？

http://winder.github.io/ugs_website/guide/troubleshooting/#gcode-program-stopped-working

我检查了一下，“Regular Expression Pattern Remover”配置中没有任何内容。我还做了一些进一步的测试。当我将脚本发送到机器时，该脚本似乎运行良好。只有当我尝试使用 $C 选项测试代码时才会出现错误。通常它是错误代码 20 或错误代码 1。（见下文）然后 UGS 程序挂断，我必须断开连接并重新连接到路由器以使 UGS 程序再次响应。问题并不总是出现在代码中的同一位置，并且（很少，可能一次或两次）脚本已在测试模式下成功完成。

示例：（
错误：20）在块中发现不支持或无效的 g 代码命令。
**** 暂停文件传输。****

（错误：20）在块中发现不支持或无效的 g 代码命令。
（错误：1）G 代码字由一个字母和一个值组成。找不到信件。
**** 暂停文件传输。****

（错误：1）G 代码字由一个字母和一个值组成。找不到信件。
行

您能否附上或通过电子邮件发送给我一个文件以重现该问题？

点击 winder picture 它会带你到他的 porfile
电子邮件在那里

@chamnit这个错误可能与在处理 G10 和更新 EEPROM 时发送 grbl 命令有关吗？我正在阅读代码，这部分特别引起了我的注意：

// However, this doesn't prevent issues with lost serial RX data during an EEPROM write, especially
// if a GUI is premptively filling up the serial RX buffer simultaneously. It's highly advised for
// GUIs to flag these gcodes (G10,G28.1,G30.1) to always wait for an 'ok' after a block containing
// one of these commands before sending more data to eliminate this issue.

我有一个可用的单步模式，但我不会为特定命令打开/关闭它。也许我需要为用户使用这样的自定义探测脚本？

糟糕，我现在在文档中看到它：

https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#eeprom-issues

是的。当您尝试在写入 EEPROM 时不断向 Grbl 发送命令时会发生这种情况。在这种情况下，G10。

@groberts22 @BusbyGTG4 P0.01在命令之后添加G10应该可以解决此问题，直到我可以获得更永久的修复为止。

@winder:G4命令无济于事。问题是 EEPROM 写入会关闭串行端口，因此 G4 命令将在 Grbl 读取之前被截断或完全丢失。

FWIW，大多数人都是临时设置工作坐标的。很少有人尝试用 g 代码来做这件事。如果他们这样做，它通常不是程序的一部分，但通常是设置工作的快速任务，就像这个用户正在做的探测一样。他们只需要在简单的流模式下运行它，直到您可以进行调整。

对我来说，该脚本以前有效，它只是在 Gcode 解析器为 G38.2 命令中断时开始中断。我对 G10 没有问题，我对 G38 没有在 G0 命令后运行有问题。虽然 EEPROM 问题令人担忧，但我认为这不是我的问题发生的原因。

@BusbyGT：如果 EEPROM 写入是问题所在，那么 G10 可以正常工作。以下命令（例如 G38 和 G0）可能会被截断。有关为什么会出现此问题的详细信息，请参阅 Wiki。也许它会变得更加清晰。

@chamnit我明白你在说什么。我的措辞可能不是最好的。

我的问题是 UGS 没有完全解析我的输入文件。回到 6 月，在 UGS 增强 Gcode 解析器之前，当 UGS 加载我的整个文件时，它完美地工作。现在，我什至不认为我的第三个 G38.2 甚至从 UGS 发送到 GRBL。这可能是一个竞争条件，现在 UGS 的其他变化使它开始出现。我将尝试使用 UGS Classic 进行更彻底的调查，因为它会弹出错误窗口。我认为 EEPROM 问题是一个需要考虑和解决的问题，但可能不是我的问题。如果我发现问题是 UGS 没有加载脚本而不是 GRBL 问题，我将重新访问我的其他问题报告。

@BusbyGT我能够解决这个问题并使用我正在处理的高级探测小部件对其进行测试——昨晚我注意到了这个问题并在之后延迟了 250 毫秒G10作为临时解决方法。通过修复，我不再需要这种延迟。我现在正处于许多其他更改的中间，所以我暂时无法将这些更改纳入每晚构建中。

如果您有 java 编译器，则更改在GrblCommunicator.java. 我会尽快将其纳入夜间构建。

    private boolean temporarySingleStepMode;
    private final static String EEPROM_COMMAND_PATTERN = "G10|G28|G30|\\$x=|\\$I|\\$N|\\$RST=|G5[456789]|\\$\\$|\\$#";
    private final static Pattern EEPROM_COMMAND = Pattern.compile(EEPROM_COMMAND_PATTERN, Pattern.CASE_INSENSITIVE);

    /**
     * When a command is sent, check if it is one of the special commands which writes to the EEPROM.
     * If it is temporarily setSingleStepMode(true) to avoid corruption.
     */
    @Override
    protected void sendingCommand(String response) {
        // If this is an EEPROM command switch to single step mode temporarily.
        if (EEPROM_COMMAND.matcher(response).find()) {
            this.temporarySingleStepMode = !this.getSingleStepMode() || this.temporarySingleStepMode;
            this.setSingleStepMode(true);
        } else if (this.temporarySingleStepMode) {
            this.temporarySingleStepMode = false;
            this.setSingleStepMode(false);
        }
    }

正如我在#769中提到的，我的问题现在与此无关。这是 UGS 中的 Gcode 解析错误，没有完全加载探测脚本，也没有发送最后一个 G38.2 文件。现在我知道了这个问题，我将更正我的脚本并在下次使用该机器时重试。

@BusbyGT：同样，当 EEPROM 写入时，串行端口在 Grbl 内部禁用。UGS 可能正在正确发送 G38.2 命令，但在接收到它们时并未从串行 RX 硬件寄存器中获取它们。当 EEPROM 写入完成时，一两个字符可能已发送到 Grbl，被覆盖并丢失。这就是我所说的截断的意思。

您收到的错误类型正是当此 EEPROM 问题发生并且 GUI 流送器未正确处理时发生的情况。一行中丢失了一个字符，Grbl 报告了一个错误，因为该字符破坏了命令，刚好足以引发错误。

EEPROM 问题不是可以解决的问题，也不是 AVR 处理器工作方式所固有的问题。该问题已得到详细记录，并且针对使用字符计数协议的 GUI 提供了建议的解决方法。一旦 Will 解决了问题（看起来他已经解决了），这个问题就会消失。

@chamnit关于 EEPROM 写入，我 100% 理解并同意您的看法。我不是在怀疑或争论 EEPROM 写入和 GRBL 的行为。我毫不怀疑 Will 会解决截断问题。然而，这里讨论的截断问题不是我的问题。我误以为是，但我错了，合并了两个最终不相关的问题。我的探测文件（我不是这个问题的原始报告者，而是问题#769）在 UGS 拒绝并且不发送到 GRBL 的命令中有一个空格（“G91 G0 Y-0.625”是命令）。“-”和“0.625”之间的空格会导致 UGS 错误地处理我的探测脚本，导致命令不会发送到 GRBL。

@BusbyGT您现在只是在 UGS 解析器中发现所有粗糙的边缘，我们应该很快就会弄清楚它们。我应该对最近的解析器更改更加小心，因为有多个变量使得这个问题比它本来应该更难排除故障。

一如既往，像这样的挑战只会让 UGS 变得更好。解析器有一堆新的单元测试来帮助防止将来出现这些类型的回归，更准确的解析器应该支持更高级的转换——比如平移/旋转/裁剪/拆分。

最终修复了 EEPROM 问题特别好，副作用是您应该能够将设置存储在 gcode 文件中并流式传输它们以进行备份/恢复类型的操作。恢复是一个非常罕见的操作，我从来没有打扰过，但这些探测脚本似乎更常见，所以它最终进入了我的 TODO 列表（尽管看起来这不是你的脚本的问题）。

@BusbyGT @groberts22 这些更改现在在夜间构建中。带有额外空间的原始文件现在应该可以使用了。还启用了为使用 EEPROM 的命令自动切换到发送-响应协议的代码。