谢谢你快速的回复！我想将所有这些参数与 EEPROM 分开，EEPROM 也可以通过命令 $$ 列出。

并在此函数的末尾添加
if(store)
到 write_global_settings();

我认为对于我的特殊情况，删除对 write_global_settings() 的调用就足够了，因为我的应用程序可以确保始终在开始时设置参数。

@oxygenic: Grbl 没有 $1000+ 设置。这是一个自定义模组。请参阅此 wiki 摘录，了解如何处理 EEPROM 写入。我还建议你不要经常写设置。它会更快地烧掉你的 EEPROM。

@oxygenic出于好奇，为什么您需要不断更改 $ 设置。您是否在不同机器上使用相同的控制器？

@chamnit没人说 RGBL 有 1000 美元以上的设置！？无论如何，这个问题已经解决了@cri-s希望这也是 GRBL 稳定性问题的解决方法。

@mayhem2408我尝试这样做是因为 EEPROM 访问似乎有问题，并且可能会导致串行通信出现问题 – 当它们按照 wiki 中的描述在握手中完成时也是如此。不幸的是，这个问题很少发生，所以我只能尝试不同的东西，然后等待很长时间。（重新）配置这些设置取决于用户，所以我不能确定他从不修改它们。

@oxygenic： 是的@cri-s给你一个定制来改变 Grbl 的行为。我想稍后向人们说明，EEPROM 问题是众所周知的，并且是 AVR 运行方式所固有的。根据我的经验，当您通过 wiki 中推荐的方式流式传输到 Grbl 时，Grbl 非常稳定。当您说“Grbl 稳定性问题”时，尽量明确表达清楚。这不是一个完整的故事，Grbl 已经稳定了相当长的一段时间。

@oxygenic您是否尝试过在每次写入 EEPROM 后放置一个 G4 驻留。这可能会减慢通信速度。
@chamnit100%同意。这不是“稳定性问题”。大多数人将他们的加速度设置为机器可以处理的最高值并将其留在那里。这是所有 CNC 控制器的工作方式。我还没有看到可以动态改变加速度的控制器。甚至没有商业控制器。我想这也会让计划者头疼不已。

@mayhem2408抱歉，不，我不知道这种可能性——下次 EEPROM 补丁不起作用时我会尝试。

它肯定与过高的加速度值或类似的东西无关，我正在接近默认值工作并且我不会在 G 代码序列期间更改这些值。

我什至不确定我的问题是否真的与 $ 命令有关，正如我所说的，我很少看到这些通信问题，只是试图排除可能的原因。

@oxygenic简单明了的 $ 命令不应放在 Gcode 文件中。这不是它的设计方式。您是否可能运行高每毫米和高进给率。这可能会导致不稳定，因为 GRBL 以每秒约 30000 步的速度最大化。你能发布你的 $ 设置吗？

@mayhem2408请参考我最初的错误报告：我没有在两者之间发送 $-commands，当我使用它们时，我严格按照手册的规定进行握手。我还使用带有原始 USB 芯片的原始 Arduino。

我看到的最新效果是这样的响应，其中两个状态消息相互重叠：

<Run|MPos:55.000,57.000,<Run|MPos:55.000,57.000,59.000|Bf:15,128>
59.000|Bf:15,128>

@oxygenic我询问您的 $ 设置的原因是检查您是否在 GRBL 的限制范围内运行。如果您没有即时更新 $ 值并且遇到稳定性问题，那么 EEPROM 不是您的稳定性问题。如果每毫米运行非常高的步数并且高进给率将导致稳定性问题。在某些情况下，我遇到过 EEPROM 损坏。我有一个激光装置，每毫米运行 160 步，最大进给速度为 30,000 毫米/分钟。这对 GRBL 来说太高了。原来我以大约 11,000 毫米/分钟的速度最大化 GRBL。关于您最初的帖子，我没有看到 GRBL 在以正确的方式完成时因更新 $ 值而变得不稳定。

ch340 的问题众所周知，但许多原始 arduino 上的 16U2 也可能存在问题。区别在于16u2可以固定而ch340不能。

https://github.com/grbl/grbl/wiki/Known-Bugs#usb-to-serial-transmission-errors

@109JB我不使用 CH340，只使用原始的 Arduinos。当我放下 USB 芯片并直接通过串行接口通信时，问题变得更加严重。

@oxygenic如果您已将 USB 排除为问题，那么它一定是您的配置。您可以与我们分享您的 $ 设置吗？

@mayhem2408 “错误”的设置真的会导致串行通信出现问题吗？这就是我所说的错误。

这些是我当前的轴相关设置：

$ 0 = 10
$ 1 = 75
$ 100 = 300.000
$ 101 = 300.000
$ 102 = 300.000
$ 110 = 600.000
$ 111 = 600.000
$ 112 = 600.000
$ 120 $ 120 = 10.000
$ 121 = 10.000
$ 122 = 10.000 $ 122 = 10.000
$ 130.000
$ 130.000
$ 130.000

限制为 5000（指定为 GRBL 最大值的一半），因为控制应用程序确保不超过实际限制。所有其他值都接近其默认值。也许我应该提到我不使用规划器，我发送一个运动命令并等待它完成，然后我发送下一个命令等等。

第510章（评论）

状态报告几乎不可能重叠，因为它是在 1 个函数内打印的（tx 队列溢出除外）。

因此，可能是您的应用程序存在多线程问题等，并且混淆了接收到的消息。

使用经过验证的应用程序来测试行为。如果仍然出现，请在出现错误的地方发布您的程序，以便重现。

@Schildkroet它是另一个 MCU 上的单线程应用程序，它肯定没有线程问题，并且接收函数是从一个不在 ISR 中的位置调用的。无论如何，感谢您提供反馈，但我原来的问题已经得到解答。

@oxygenic与其说是错误的设置，不如说是错误。它的设置超出了 GRBL 的限制。例如，您的每毫米步数 300 意味着您可以安全运行的最大进给是 6000。您的最大进给设置远低于该值，所以这不是问题。

@cri-s : The EEPROM write function in Grbl was taken directly from Atmel’s software framework from what I recall. I don’t see much reason to change it just for non-standard use cases, when they might create more risk in causing other EEPROM issues by turning them off.