@timryder: 从你在另一个线程中所说的来看，你的设置肯定有些奇怪。我想首先你需要尝试通过使用稳定的主版本来隔离问题并完全从你的系统的其余部分拔掉。所以只有你的电脑和arduino。使用我们的 repo、UGS 和/或其他东西中的 stream.py 脚本，使用不同的流协议对其进行测试。

好的，所以我用十几种不同的格式对它进行了极大的测试。

我正在使用 G-Code Sender 作为我的测试工具，我无法获得包中包含的示例脚本来编译和运行。我将已经编译好的 Grbl v0.9a Build 2013-03-19 从这个网站刷到Arduino Uno. 我使用了我的机器典型设置。

$0=640.0000（x，步长/mm）
$1=640.0000（y，步长/mm）
$2=640.0000（z，步长/mm）
$3=2400.0000（x 最大速率，mm/min）
$4=2400.0000（y 最大速率，毫米/分钟）
$5=2400.0000（z 最大速率，毫米/分钟）
$6=1024.0000（x 加速度，毫米/秒^2）
$7=1024.0000（y 加速度，毫米/秒^2）
$8=1024.0000（z 加速度，毫米/sec^2)
$9=80.0000（x 最大行程，mm）
$10=50.0000（y 最大行程，mm）
$11=200.0000（z 最大行程，mm）
$12=15（步进脉冲，usec）
$13=0（步进端口反转掩码：00000000）
$14=64（dir 端口反转掩码：01000000）
$15=0（步空闲延迟，毫秒）
$16=0.0200（结偏差，mm）
$17=0.0020（弧度公差，mm）
$18=4（n-小数，整数）
$19=1（报告英寸，布尔）
$20=1（自动启动，布尔）
$21=0（反转步进启用，布尔）
$22=0（反转限制引脚，布尔）
$23=0（软限制，布尔）
$24=0 （硬限制，布尔）
$25=1（归位周期，布尔）
$26=192（归位方向反转掩码：11000000）
$27=1200.0000（归位进给，mm/min）
$28=500.0000（归位搜索，mm/min）
$29= 100（归位去抖，毫秒）
$30=0.0000（归位牵引，毫米）

使用此配置并以 F40 运行机器，我还没有让它锁定。
$0=640.0000（x，步长/mm）
$1=640.0000（y，步长/mm）
$2=640.0000（z，步长/mm）
$3=1200.0000（x 最大速率，mm/min）
$4=1200.0000（y 最大速率，毫米/分钟）
$5=1200.0000（z 最大速率，毫米/分钟）
$6=512.0000（x 加速度，毫米/秒^2）
$7=512.0000（y 加速度，毫米/秒^2）
$8=512.0000（z 加速度，毫米/sec^2)
$9=80.0000（x 最大行程，mm）
$10=50.0000（y 最大行程，mm）
$11=200.0000（z 最大行程，mm）
$12=15（步进脉冲，usec）
$13=0（步进端口反转掩码：00000000）
$14=64（dir 端口反转掩码：01000000）
$15=0（步空闲延迟，毫秒）
$16=0.0200（连接偏差，mm）
$17=0.0020（圆弧公差，mm）
$18=4（n-decimals，int）
$19=1（报告英寸，bool）
$20=1（自动启动，bool）
$21=0（反转步使能，bool）
$22=0 （反转限制销，布尔）
$23=0（软限制，布尔）
$24=0（硬限制，布尔）
$25=1（归位周期，布尔）
$26=192（归位方向反转掩码：11000000）
$27=1200.0000（归位进给，毫米/分钟）
$28=500.0000（归位寻道，毫米/分钟）
$29=100（归位去抖，毫秒）
$30=0.0000（归位牵引，毫米）

有人愿意发表评论吗？

更新：

截至美国东部时间 6 月 5 日下午 1 点（同一天），我使用 M8 M9 在我的机器上运行了 100 个冗长的 gCode 循环来驱动我的工具输出，并且一旦我降低了我的最大速度和最大加速度的值，它就没有一次停止。

我没有改变任何其他东西。

任何人？只要最大速度很慢，我仍然可以跑得很好。有人愿意发表评论吗？

我绝对可以想象 grbl 的状态机代码中存在竞争条件。这会使它对时序问题敏感，因此依赖于最大速度等。
我自己已经看到了几个这样的问题。
但它们很难找到并修复。@chamnit似乎在努力追踪他们……

@timryder: 抱歉延迟回复。我一直在忙一些家庭事务。

您发现的这个问题是 v0.9e dev 应该修复的问题。像 v0.9a 这样的旧版本如果你用力和足够快地驱动它们并且 CPU 无法跟上并破坏规划器缓冲区，就会锁定。V0.9e 从头开始​​重新设计以完全缓解这一问题。

简单地说，只需将您的机器运行得更慢，即可使其在 v0.9e 之前的版本上运行。您运行的旧 grbl 版本非常接近其限制。此外，您还可以尝试在 v0.9e 之前提高波特率。它可能有助于修复您看到的部分或全部损坏问题。

@chamnit：抱歉，我不知道家庭问题，家庭是您的第一要务，所以我很抱歉。这么长时间以来，您一直以快速响应宠坏了我们。

我为此使用 0.9e，它似乎在更高的波特率下工作得更好，但它不断产生“线路溢出”错误，我似乎无法让它停止。所以我不得不将我的波特率降低到 9600，它摆脱了线路溢出错误。我从来没有为每个命令发送超过 80 个字符，大多数时候它们在 15-20 左右要少得多，因为我随时只发送 2 个轴。

我可以让系统运行得更慢，但我很乐意测试您希望我做的任何事情，以帮助解决问题。

更新：在 38400 波特时，没有其他变化。每当我向它发送特定命令时，我都会收到错误消息

发送：G20
接收：错误：预期的命令字母

发送：$H
接收：错误：预期的命令字母

有时在我发送 M8 和 M9 的周期中，我得到错误的数字格式。
我必须将它降低到 9600，否则它不起作用。

@timryder: 我想我之前在这个线程或另一个线程中提到过这个。您的设置有些奇怪。仅当串行数据传输超过 70 个字符而没有换行或回车符时，才会发生行溢出错误。这让我认为您的流式传输存在严重问题，并且损坏或无法正常工作。这可以解释你的很多问题，但不能解释所有问题。

我不能说你的控制器到底出了什么问题，因为它是自定义的。我所能做的就是告诉你尝试使用真正的 arduino 来解决这个问题。

真的不想成为这里的害虫，但我只想帮助你们找出问题所在，以便我们都能更好地享受这个美妙的工具！

这是在 Arduino Uno 上反复使用 stock build 0.9e 时 38400 的结果
。

编辑：我后来意识到，当我按“暂停”然后按“恢复”时，控制器实际上确实恢复了我的程序。不知道有没有用？

@timryder：出于某种原因，我认为您是构建自己的 arduino 并试图修复它的用户。我的错。

无论哪种情况，您都是第一个报告此类问题的人，这意味着其他用户没有此问题，并且这与您的计算机、arduino 和编译器的组合是孤立的。

其一，我看到你说你使用 atmel studio。我不使用 atmel studio，因为它只适用于 windows。我在 mac 上工作。其次，我们选择使用 arduino ide 的内置编译器，因为它是跨平台的，并且自始至终都是相同的编译器。我之所以提出这个问题是因为 arduino IDE 编译器有点旧。我无法告诉你什么样的变化会影响这种行为。据我所知，其他使用 atmel studio 的用户也没有报告过这个问题。

还有usb串口驱动​​。在过去，它们存在一些问题并且不兼容。不能告诉你我的头顶，但那里有一些点亮。

我认为这与您计算机的串行通信有关。所以再次请先研究这个问题并尝试模仿其他人的设置来隔离这个问题。我怀疑这是一个 grbl 问题，但在我们消除更多变量之前我们不能排除它。

我明白，你是对的，我确实构建了自己的硬件，所以没有问题。
我只是使用 make clean 重建 0.9e 代码 38400，使用 arduino IDE 的编译器制作 grbl.hex 命令行界面并将其加载到 Arduino Uno，它仍然在做同样的事情。

我在我的电脑上尝试了几种 USB 电缆和 3 个不同的 USB 端口。

不确定它还能是什么，程序似乎只是在 M8 和 M9 暂停，我必须先点击暂停然后再继续才能让它继续。当有大量直接的 G0 或 G1 时，它永远不会挂起，但它似乎总是停在 M8 M9 处。

您介意在您的设置中尝试使用此文件进行测试吗？
http://www.cmt-engineering.com/gCode_Coolant.txt

我保证这很安全。

我想也许我正在做而你们中的一些人可能没有做的唯一不同的事情是我使用 USBTiny 编程器通过 ICSP 引脚将 .hex 烧录到 Uno，而不是通过 USB 与引导加载程序打扰。但我看不出这会有什么不同。

只是为了支持 Sonny 的方式：我认为你的
董事会有问题。

您是否将控制器引脚连接到继电器？如果您
根本没有连接任何东西会怎样？例如，如果它只是您的
计算机和控制器（没有防护罩等）。

如果您遇到相同的问题，我很想知道是否将相同的十六进制加载到已知良好的控制器上。我的猜测（使用过许多
0.9 版本）是您不会看到相同的问题。

如果您想压缩并发送给我您的 hex 文件和用于测试的 NC 文件，
我很乐意将其加载到我的一个 arduino 上。( edward@shapeoko.com )

-爱德华

在 2014 年 6 月 10 日星期二上午 8:39，timryder notifications@github.com写道：

我明白，你是对的，我确实构建了自己的硬件，所以没有问题
。
我只是使用 make clean 重建 0.9e 代码 38400，
使用 arduino IDE 的编译器制作 grbl.hex 命令行界面并将其加载到
Arduino Uno，它仍然在做同样的事情。

我在我的电脑上尝试了几种 USB 电缆和 3 个不同的 USB 端口。

不确定它还能是什么，程序似乎只是在 M8 和 M9 暂停
，我必须先点击暂停然后再继续才能让它继续。
当有大量直接的 G0 或 G1 时，它永远不会挂起，但它
似乎总是停在 M8 M9 处。

—
直接回复此电子邮件或在 GitHub
#427（评论）上查看。

我想这是可能的。

这是我的电路板和设置的图片。你可以在这里看到我使用的是 FT232RL 芯片，并且有焊接跳线直接连接到 ATMEGA328p tx 和 rx 引脚。我移除了 1k 电阻，这些电阻通常位于我的电路板上，位于 FT232RL USB 转串行芯片和 MCU 之间。这可以防止除通过这些跳线外的任何其他方式接收串行数据。

我做了另一个测试只是发送一个？一遍又一遍地使用名为 See-It 的串行程序，结果如下。

在这里你可以看到几次 MCU 没有响应的地方？但是 2 和 3 在收到响应之前堆叠起来。随机在什么都没有的时候我得到了那个错误，很明显缓冲区中不超过 70 个字符……

我还在我的 FT232RL 串行芯片上直接焊接了一个从 TX 到 RX 的跳线，它用一个在所有波特率下测试的程序执行了环回测试，它工作得很好。

请提供任何帮助，我将不胜感激！

编辑：我意识到我在这个屏幕帽中有 XonXoff 流量控制，但我再次尝试关闭它，它仍然没有任何区别，相同的精确结果。

埃德，

请你下载并在你的板上测试。
http://www.cmt-engineering.com/grbl.hex

http://www.cmt-engineering.com/gCode_Coolant.NC

谢谢
( timryderhome@att.net )

当然可以。当我
今晚回来时，我会把这个 hex 放到我的一个 arduino 中。一旦我有一些信息，我会传递它。

-爱德华

在 2014 年 6 月 10 日星期二上午 9:51，timryder notifications@github.com写道：

埃德，

请你下载并在你的板上测试。
http://www.cmt-engineering.com/grbl.hex

http://www.cmt-engineering.com/gCode_Coolant.NC

谢谢
( timryderhome@att.net )

—
直接回复此电子邮件或在 GitHub
#427（评论）上查看。

@timryder: 好吧，我认为一种误解是 Grbl v0.9a 以后不会被使用。该分支（边缘）将被当前的 v0.9e dev 分支覆盖。v0.9e 是 v0.9a 的“更稳定”版本。这就是为什么字母后缀在字母表中更靠后的原因。

也就是说，请忽略来自 0.9a 的所有错误。不要使用它。如果您打算使用任何非 master 分支，此时只使用 v0.9e dev 分支。

同样，我想我之前已经说过，M8/9 问题仍在继续。尚未为此发布修复程序。除此之外，据我所知，v0.9e 应该没有其他主要问题。而且，如果我对您的帖子的理解正确，那么 v0.9e 不会像 v0.9a 那样出现速度和行溢出错误的相同问题。

@chamnit

你在之前的帖子中提到

（你发现的这个问题是 v0.9e dev 应该修复的问题。如果你足够快地驱动它们，像 v0.9a 这样的旧版本会锁定，并且 CPU 无法跟上并破坏规划器缓冲区。 V0.9e 从头开始​​重新设计以完全缓解这一问题。）

我假设这是针对您已修复的 M8 M9 问题。我已经对它进行了大量测试，并且发现了一些发现。当电机速度较低时，问题似乎不会发生。我在该线程开头的帖子只是重申，如果我保持低速度，我根本没有看到问题（M8 和 M9）。实际上它似乎更多地与加速度有关。因为当 M8 和 M9 发生时我的大部分动作都很小，机器在此期间从未达到峰值速度，所以在我的程序中打开 M8 M9 时它保持在加速减速配置文件中。因此，当我降低速度时，它根本不会挂在 M8 M9 上。

第 2 期我在较高波特率下遇到“线路溢出”，这实际上可能是我的 MCU。我在我的硬件上做了一个环回测试，它看起来很好但是当我写一个小程序来将串行 RX 回显到 TX 并将其闪存到 MCU 以测试我的所有硬件时，如果字符串太长有时我偶尔会得到一些奇怪的数据。我会对此进行更多调查。

@timryder：v0.9e 中规划器和步进器界面的重新设计与此 M8/9 问题完全不同。如果您查看问题线程，它通常被称为不受保护的规划器，这是由规划器缓冲区不足和第一个/当前规划器缓冲区块同时被重写和执行引起的。v0.9e 没有这个问题。

如果您正在努力驾驶 v0.9e，您可能也会遇到与 M8/9 不同的问题。这“可能”是由新的步进中间缓冲区不足引起的。它只在其中存储 50 毫秒的运动，如果发生太多其他事情，它会破坏 Grbl。虽然在我的测试中，我从来没有遇到过问题，但也许你是出于某种原因。

尝试两件事看看它会改变什么：

• 增加 ACCELERATION_TICKS_PER_SECOND。此参数定义加速斜坡中有多少个恒定速度步长。您可能会超过每秒 100 次的默认值。
• 将 SEGMENT_BUFFER_SIZE 增加一或两个块。这将增加步进段缓冲区中的时间量，这也与 ACCELERATION_TICKS_PER_SECOND 相关联。每个段缓冲区等于 1/ACCELERATION_TICKS_PER_SECOND，因此您可能需要同时调整两者。请记住，此设置会占用大量内存，因此您可能会很快用完。作为补偿，您可以将规划器缓冲区大小减少一两个块以释放足够的内存。

问题 2：我确实记得串行波特率计算可能很挑剔。根据计算的执行方式，数字舍入可能会导致主机和 Grbl 出现一些同步问题。我没有像你那样在 38400 波特率下测试过它，但是 115200 波特率是如何工作的？我认为在 serial.c 中有一些替代方法可以计算波特率，但我近期没有时间研究它。

@timryder: 是否有关于您奇怪的通讯问题的最新消息？

我想我知道是什么导致了 9e 上的 M8/M9 问题。我一直在为 9e 更新模拟器，并且我已经看到类似的锁定试图运行 M3 主轴。

只有当您发送串行命令的速度快于 grbl 可以跟上时，才会出现此问题。它与以下事实有关：主循环在清空传入串行缓冲区之前不会设置 CYCLE_START，但主轴和冷却液命令会阻塞，直到规划器为空。事件的顺序是这样的：

以空闲状态启动。
发送运动命令后立即发送冷却命令。
protocol main loop调用protocol_execute_line运动命令。
这到达mc_line，它向规划器缓冲区添加一个块并将状态设置为“QUEUED”。
返回时，protocol main loop在缓冲区中找到更多字符并调用protocol_execute_line主轴命令。
这调用coolant_run了一个protocol_buffer_synchronize。

这就是它卡住的地方。Grbl 还没有处于 ‘CYCLE’ 状态，并且有一个当前块，所以它进入等待循环。但protocol_execute_runtime永远不会从 QUEUED 状态变为 CYCLE 状态，因为没有设置“EXEC_CYCLE_START”位。

我能够通过在“coolant_run”和“spindle_run”的开头添加“protocol_auto_cycle_start()”来修复它。

我的代码中也有这些。:-)

@ashelly: 啊，谢谢你的解释。这个周末我有一些时间，然后我打算解决这个问题以及其他一些事情。我一直在考虑如何从整体上解决这个问题，而不是补丁。可能会重新组织代码以在以后消除此类问题，或者在下一次使它变得非常明显。