@109JB：这似乎与文件大小与此问题无关，而是它允许更多时间通过以发现罕见的随机错误。在将任何内容写回 GUI 时，串行写入代码有一个 wait-if-full 语句。因此，就 Grbl 源代码的编写方式而言，这毫无意义。

但是，我最近确实发现了在结构中放置易失性变量的问题。在这种情况下，volatile 是未定义的，所以当闪存和内存接近极限时，真正奇怪的事情开始出现在最近的开发版本中（默认的主版本似乎没问题）。例如，状态报告只会打印乱码值、偶尔出现随机软重置、g 代码解析器状态未正确更新等。我上周发布了一个修复程序。如果您还没有更新，您可能会在启用 Grbl 的 echo 时遇到这个问题。

谢谢。我确实在我加载的先前版本中的 $I 请求中看到了一些奇怪的字符，并且我加载了一个新版本。我看到的是带有一堆 ?????? 的版本响应。在右括号之前。

我刚刚对当前加载的版本运行了一个 $I 请求并得到了这个：

[0.9j.20150930:4G0]

这对于版本响应是否正确？最后的 G0 看起来像我的 $N0 的尾端，它是：

$N0=G90G20G54G0

@109JB: 陌生又陌生。这也不应该发生。如果您发送一条$I=命令来清除 $I 构建信息字符串，N0 是否会被截断？这意味着 EEPROM 映射由于某种原因关闭。

其次，您还在使用 Arduino Nano 吗？您最终是否将引导加载程序更新为 Optiboot？我想知道它是否与引导加载程序和剩余闪存空间有关。

$N0 不会被截断。看起来不错。我只是尝试了几件事。首先，我决定在 Arduino IDE 串行监视器中尝试它，以消除我的 GUI 的可能性。当然在 IDE 上，它会自动执行软重置。然后我运行 $I 得到与上面相同的结果。然后我发送一个 $N0= 来清除它，然后再次运行 $I。同样的结果。然后我执行了硬重置，并运行 $I 得到相同的结果。我检查了 $N0，grbl 报告它现在是空的，$N1 也是。

我仍在使用 nano，但我从来没有抽出时间为它做 optiboot 加载程序。我将下载最新的 grbl 并重新刷新并再次检查。我会回来报告的。我还将检查 IDE 对所用闪存空间的说明。

我下载并重新刷新，这就是我现在从 $I 后面跟着 $N 并关闭回声得到的结果。

Grbl 0.9j [‘$’寻求帮助]
[0.9j.20150930:4G0]
ok
$N0=
$N1=
ok

然后我使用 Arduino IDE 完全清除 EEPROM 并重新刷新 GRBL。这似乎已经纠正了它，因为现在从软重置后的 $I 开始，我得到：

Grbl 0.9j [‘$’寻求帮助]
[0.9j.20150930:]
好的

我讨厌我的 $N0=G90G20G54G0 字符串并重新运行 $I，现在一切看起来都很好。

什么会导致此 eeprom 数据像这样损坏？
:

不确定这是怎么发生的。这个 EEPROM 字符串一直保留在那里，直到被覆盖或清除，所以它可能在过去的任何时候发生过。有可能之前的 $N0= 写入命令在 EEPROM 中写入了错误的位置，可能是通过我谈到的这个错误，也可能是其他原因。或者，Grbl$I=4G0在某个时候以某种方式收到了命令。也就是说，我没有在 Grbl 中安装太多正确的输入检查，因为它们占用了太多的闪存空间。尤其是 $Nx 和 $I 命令。这些并不经常使用，一旦设置，用户通常不会弄乱它们。