早期版本的 GRBL 对长行很敏感。UGS 中有一个命令处理器可以检查这一点，确保我们没有溢出任何缓冲区。默认值为 70 个字符，但您可能正在运行较旧的配置。

您可以简单地禁用此命令处理器或在以下设置中更改其值Command Length Processor：

谢谢。

正如我所说，我正在运行 2.07，这是我在报告此问题前几天下载的。每晚都有同样的问题。

在观察和报告问题之前，我已经将它的 CommandLengthProcessor 设置为 128。

禁用该选项并不能解决问题。

我正在使用 grbl_esp32，我知道它有一个 128B 缓冲区。

欧文

感谢您的反馈。

令我困惑的是这个值50让我相信它是以前版本的旧设置值。
但我想我已经找到了问题所在，如果在加载预处理器时出现任何错误，它将默认为值 50。

你能上传日志文件吗：https ://github.com/winder/Universal-G-Code-Sender/wiki/Configuration#log-files

好的，日志文件实际上位于 C:\Users\owen\.ugsplatform\2.0.7-SNAPSHOT\dev\var\log（与 Wiki 中所述不同）。

消息.zip

该日志不包含您打开文件时的日志行。您能否重试打开与 GRBL 的连接，然后打开一个文件。

好的，抱歉，我误解了……我以为你只是想要包启动。

如果我尝试在连接到 grbl_esp32 之前打开文件，则会出现此问题。如果这样做无效，则应禁用文件打开选项。

对于此测试，命令长度处理器被禁用（或应该被禁用）。

消息.zip

欧文

啊，好的，当它没有连接到机器时，默认的预处理器被加载，限制为 50 个字符。这样的默认规则是不必要的，所以我要删除它。

但是你在连接到机器后加载文件时不会出现这个错误，对吧？

我得去棚子里试试，现在是凌晨 4 点，所以要几个小时。

您是否注意到我已禁用该规则，因此此时也被忽略了。

我注意到这里的行为发生了变化。我确实喜欢文件重新加载按钮，但它消失了。如果 UGS 识别出某个文件已更新并提示重新打开它，这将是一个不错的功能。

我一直在使用 14 Jul nightly，它在窗口底部显示错误，但它加载并显示文件正常（再次连接到 grbl 之前）。

由于 grbl 有更大的命令缓冲区，也许它应该在您的列表中有自己的机器类型。

我将在几个小时后报告。

欧文

是的，我注意到您为 GRBL 禁用了预处理器。但它只会在连接到 GRBL 时加载这些设置，否则它会加载设置得有点低的默认设置。

我计划进行一些更改以更好地检测它所连接的 GRBL 变体，以启用 grbl_esp32 和 grblHAL 中的扩展功能。我希望我们可以在不在下拉列表中引入其他机器类型的情况下添加这些扩展，以便我们的用户更轻松。虽然我没有考虑过 CommandLengthProcessor，但我想知道程序是否有可能生成超过 70 个字符的行？我以前没有见过这个问题，所以我认为这些更改可以等待。

关于文件更改，这将是一个不错的功能。我将为此创建一个功能请求！

行。

这变得复杂和混乱？

我得到的图片是打开文件时，只有建立 grbl 连接才能正确处理它？如果这是真的，这是一个陷阱，除非 UGS 在打开 grbl 后重新处理输入文件（原样）？

日志.zip

因此，在连接 grbl_esp32 的情况下，它确实加载了……但状态行中出现了不同的错误，请参见 zip 中的屏幕截图。它抱怨一行上有多个速度命令，我只能看到一个速度命令，而且只有一个，但它使用了一个浮点数，也许 UGS 在点处拆分了它？

欧文

在使用该控制器的预处理器设置连接到任何控制器后，它将重新处理该文件。

为我加载的文件没有任何问题。我什至尝试停用命令长度处理器。

我无法解释你得到的错误。我记得大约一年前有一个类似的问题，它试图将某些评论解析为 gcode，但这个问题已经解决了。

当您应用了您的更改并测试它时，我可以得到一个夜间构建吗？

这只会解决在未连接时加载 gcode 文件的问题。如果您在连接后加载文件，则不会有任何不同。

我明白这一点，我看到了速度命令问题，而你却没有……尽管它似乎不会阻止文件加载。

谢谢……欧文。