通常：您可以通过修改 BAUD_RATE 的值来更改 config.h 中的波特率。但我猜你偶然发现了另一个我也注意到的未解决的问题。关于这个有一些封闭的问题，直到现在似乎还没有解决这些通信问题的方法。至少对于我在这里看到的问题（也是），我可以确认降低通信速度不会改变任何东西。

我可以确认，降低通信速率实际上会导致以前运行无故障的 GUI 出现问题。我回到 115200 波特。bCNC 页面上的许多人都认为 CP2104 可能有问题，但我发现这不太可能，因为他们似乎在 CH340G 和 FT232RL 上遇到了这类问题。

您应该能够毫无问题地将其降低到 9600。旧版本的 Grbl 以这种速度运行，并且从那时起串行代码没有太大变化。

关于通信问题，还没有一组明确的案例说明问题是什么。报告的那些似乎彼此无关或孤立。人们无法提供我可以重现的可靠测试，以便我可以对其进行故障排除。因此，解决问题仅限于缓慢且低效的问题帖子，这很快就会令人沮丧。

也就是说，我玩过 CP2104 没有问题。有许多外部源可以影响连接和数据传输。例如，如果 USB 电缆没有用于降低 EMI 的铁氧体磁芯或靠近 EMI 源，则 USB 串口和主机之间的数据传输可能会失败。通常，除了 Arduino 之外，没有其他任何动力来运行这项工作，并且最好断开与所有设备的连接，这通常会消除 EMI 作为一个因素。

我仍在尝试编译所报告的通信问题，因此请提供您的 Grbl $$ 设置、$i 构建信息输出、您正在运行的操作系统，以及有关如何编译 Grbl 以及使用哪个版本的 Arduino IDE 的详细信息。谢谢！

我在没有立铣刀的情况下运行了 gcode，但在电机开启的情况下程序随机停止。然后我在电机关闭的情况下运行 gcode，这次它随机停止在代码中的不同点。我在 OpenCNCPilot 上运行了相同的代码，它在所有功能都打开的情况下顺利完成。我不认为 EMI 是个问题，因为我的电缆被屏蔽了，末端停止信号必须通过低通滤波器，然后是施密特触发器。

我也不认为 CP2104 是原因，但我打开这个问题只是为了排除这种可能性，因为 bCNC 的人似乎认为这是来源。虽然如果您查看 CP2104 数据表并对波特率进行一些计算，会有 0.16% 的误差，但这完全在可接受的 1% 误差率范围内。

可以这么说，我按照书本编译了 grbl。首先将grbl里面的文件夹添加grbl-master.zip到librariesArduino sketches文件夹下的文件夹中。然后我在 Arduino IDE 中打开grblUpload.ino文件，编译它然后上传到 328P。使用 IDE 版本1.8.6。

$$输出是：

$2=0
$3=1
$4=1
$5=1
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=1
$22=1
$23=3
$24=300.000
$25=1425.000
$26=250
$27=2.000
$30=12000
$31=0
$32=0
$100=80.000
$101=400.000
$102=400.000
$110=3000.000
$111=2200.000
$112=1000.000
$120=200.000
$121=200.000
$122=100.000
$130=725.000
$131=190.000
$132=15.000

$4=1因为我的东芝驱动程序需要一个高电平有效使能信号。

$i输出是：
响应：[VER:1.1f.20170801:]

@classbproject: 你在运行Windows吗？此外，OpenCNCPilot 可以工作并且在 .net 上运行的事实表明 bCNC 的 python 串行库可能有问题。我记得过去 pyserial 库存在一些问题，但记不清具体是什么了。我很确定您必须使用特定版本才能正常工作。这是很久以前的事了。一些新版本的 pyserial（可能依赖于操作系统）可能是罪魁祸首是可行的。

@classbproject：另一种检查方法是使用另一个使用其他串行库或用不同语言编写的 GUI 进行测试。UGS 是用 Java 编写的，不确定它的串行接口使用什么，但值得一试，看看问题是否不会在那里发生。

是的，运行 Windows 10。我安装了最新版本的 pyserial。真的不知道那是什么。似乎还有两个版本的 bCNC – 一个由 Harvie 开发，一个由原始开发人员开发。我相信 Harvie 版本比原始版本稍微领先一点，因为它不需要某些库来显示数据，例如自动调平器探测点等。我尝试了两者，但都失败了。

我会尝试使用 UGS 并返回报告。不确定 UGS 1.0.9 中使用的是什么，但 UGS 2 nightlies 为您提供JSSC 和 JSerialComm选项，但 CP2104 仅适用于 JSerialComm。选择 JSSC 后，它不会检测到设备。

以 9600 运行不会导致 GUI 轮询状态过快的问题吗？

@langwadt: 肯定会的。当以 9600 波特率运行时，状态报告轮询大约为每秒 1 次，而不是现在每秒 10 次左右。它肯定需要减少。

人们无法提供我可以重现的可靠测试，以便我可以对其进行故障排除。

请参考我的（已关闭）问题，在那里我给了你一个序列，它至少会导致内存泄漏损坏 $$ 值，并且可能还会破坏通信。

@oxygenic：是的，有一个序列，但没有任何其他细节，即测试设置、通信细节、其他外部因素，如接线、我可以流式传输的程序，它将重复显示问题的案例等。我已经要求这个次数。但是，如果您想更多地讨论这个问题，我们可以在新线程或您的旧线程中进行。不要劫持这个，因为它似乎与您的问题无关。

我不能给你不存在的东西：这个问题不可重现可靠，它是随机的。所以可能是时间问题？在这种情况下，我当然不能施展任何魔法来使其安全地重现，一个随机的 bug 保持随机并且总是难以调试。

其他一切都是标准的，G 代码序列可以在错误报告中找到，该设备是一个普通的原始 Arduino Nano，没有任何连接，来源是 GIT 中的最新 GRBL 版本或我的禁用版本EEPROM 访问（对此没有影响，两者都会发生）。通信是用 115200 或 57600 波特完成的，这也没有区别。因此，您可以使用简单明了的默认设置和此 G 代码序列。

好的，所以我尝试使用 UGS 1.0.9，它运行良好。事实上，我运行了 4 个作业，它们都在 115200 波特率下完美运行，没有任何故障。

@classbproject： 行。这似乎证实了 bCNC 出了问题。这可能是与您的计算机（操作系统、Python 版本、外部任务）不兼容、串行驱动程序问题或 bCNC 中的错误。

bCNC 人员可能会要求提供更多证据。还有另一个 GUI 使用名为 CNCjs 的 nodeJS 驱动程序。如果可行，这将为他们提供确凿的证据。但是，Node 的安装不是很简单或漂亮。除非他们要求或愿意采取额外步骤，否则我会推迟。

否则，我会认为这件事已经结束，因为我们已经回答了最初的问题并且似乎已经证实它不是 Grbl。让我知道无论如何都会发生什么。我正在密切跟踪串行通信问题，因为最近出现了一些随机相关的问题。

@oxygenic
我测试了你的序列，但没有遇到任何问题。
请获得一些批准的 gui，如 UGS 等，并用它测试你的 grbl 设置。如果您可以重现该问题，请发布您的确切设置和步骤，以便可以重现该问题。
如果您不愿意这样做，请停止在每个线程中抱怨并接受当前状态。

@Schildkroet

我测试了你的序列，但没有遇到任何问题。

你多久尝试一次？如前所述，有时它会在几次循环后发生，有时您需要尝试 >100 次才能看到问题。

请获得一些批准的 gui，如 UGS 等，并用它测试你的 grbl 设置。如果您可以重现该
问题，请发布您的确切设置和步骤，以便可以重现该问题。

我不使用任何 GUI，而是直接通过串行控制台/脚本发送序列，然后通过检查“空闲”信息等待它完成：

• 序列的总长度小于 128 字节，因此肯定不会导致串行缓冲区溢出
• 命令总数小于 14，因此肯定不会导致命令缓冲区溢出
  那么 GUI 到底有什么区别呢？

如果您不愿意这样做，请停止在每个线程中抱怨并接受当前状态。

我不会“在每个线程中”抱怨，但我评论明显的事情 – 当有人声称没有关于特定问题的可用报告时，我认为当这不是真的时让我给出答案是非常公平的！