最初我只想使用 xon/xoff 或 rts/cts 流控制。我的计划是

$ cat myshape.gcode > /dev/usb-serial239847239

然后它就消失了。但我的实验一无所获。据我所知，我使用的串行适配器（主要是 FTDI）或 Mac OS X 不支持流量控制，这对我来说是整个考验。我很乐意被告知我对此错了。我个人认为更好的缓冲是要走的路。如果我们支持对 SD 卡的快速缓冲或类似的便利，我们可能根本不需要流量控制，因为我们总是能够吞噬输入。

我个人使用XON / OFF方法来控制串口上的流量，但是我立即遇到了这个问题，当缓冲区已满并发生XOFF时，我无法发送运行时命令字符作为feedhold，Reset和Status报告，所以我放弃了，我回到了起点，我只是在发送下一个gcode行之前检查了’ok’的返回。我认为在 Satus 报告中包含一个指示进程结束和缓冲区为空的标志会很有趣，因为流式传输代码的结束并不意味着移动的结束，我无法检查是否过程真的结束了，特别是当 gcode 的最后几行是轴长移动时。这是一个小视频，展示了一个用于控制 GRBL 和 Tinyg 的简单应用程序。 http://www.youtube.com/watch?v=li7HwmOskMM

我在 TInyG 上使用 XON/XOFF 插入字符时遇到了同样的问题，但它确实有它的用途。这是一种将文件简单地流式传输到设备的有用方法。一段时间以来，我一直在以这种方式使用 Coolterm (Mac) 运行带有 FTDI 芯片的 TinyG，它非常可靠（我会说完全可靠，但不知何故我会被证明是错误的！）。但是，如果你想注入实时命令，你真的需要控制发送方每次传输只发送一个 Gcode 块，或者 – 正如 Simen 建议的那样 – 有一个“无限”的高级缓冲区（比如大于任何实用的 Gcode 文件）。我不认为你可以同时拥有它。我的偏好是同意一个可以在响应行中轻松扫描的同步字符（例如 >）。

还要补充几个缺点。软件流控制仅限于字符传输，不能发送二进制数据，因为二进制数据总是有机会发送 XON/XOFF 位序列。这会阻止快速、高效的二进制模式状态报告，除非以 base32 或 base 64 ascii 字符串编码。仍然使用 ‘ok\n’ 响应也可以这样说。二进制数据也有可能触发这种情况，尽管这种可能性很小。

其次，我读到一些终端仿真器不会立即执行 XOFF 命令，并且可能导致缓冲区溢出，除非串行缓冲区非常大并且可以处理延迟。流量控制的处理方式可能因终端而异。Alden 使用 Coolterm 可能是个例外，而 Simen 的“socat”和管道则不是。尽管我对此也可能是错的。

因此，似乎有两种选择：实施具有所有缺点的 XON/XOFF 或更新并继续使用我们一直在使用的应用程序级流控制方案 (‘ok\n’)。

• 对于 XON/XOFF，二进制数据是不可能的，因此将数据压缩为 base32 或 base64 ascii 字符可能是最简单的方法，可以快速高效地报告状态，但需要一些 CPU 开销。可能需要进行测试以确保 XON/XOFF 与大多数终端仿真器可靠地工作，并且 grbl 没有缓冲区溢出问题。并且仍然需要一种方法来强制将运行时控制字符传输到不属于标准流协议的 grbl，但是用户可以使用任何终端来使用 grbl 没有运行时控制。（仍然有用）。
• 使用我们的应用程序级“ok\n”流控制，我们可能必须进一步开发和授权某种协议。如果是这样，我仍然在使用“ok\n”响应的阵营，因为它对新用户来说并不神秘。可以通过为接口创建一个标头来发送二进制数据，指示正在发送一个固定大小的二进制数据包。这种类型的协议非常简单且易于用户使用，您发送并等待直到“ok\n”，但存在延迟问题，并且串行读取缓冲区通常总是空的。如果我们继续使用这个协议，我们需要让用户轻松保持串行读取缓冲区满，就像使用 XON/XOFF 协议一样，这对某些人来说可能是一个挑战。

大家怎么看？正如奥尔登所说，我们不能两全其美。或者也许我们可以？

simen：一张SD卡肯定能解决所有这些问题。您所要做的就是将文件上传到 grbl，然后点击运行。就那么简单。我真的很想在某个时候看到这种情况发生。这个问题将不得不为 SD 卡屏蔽释放数字引脚 10-13，这些引脚被限位开关（我们可以将其减少到一个引脚吗？）和主轴控制引脚占用，并确保我们有足够的 RAM 和闪存来安装它（我听说 FAT16 库很大）。

sacidu93：非常漂亮的界面！我喜欢看到人们能够轻松编写自己的程序。在状态报告中包含缓冲区状态目前正在讨论中，并且可能很快就会进入 grbl。

实现 XON/XOFF 的一种优选方式是使用高水位线/低水位线方案。当缓冲区（比如说）90% 满时发出 XOFF，当它（比如说）5% 满时（在排空时）发出 XON。这允许系统滞后并通过引入滞后来防止系统抖动。这就是它在 TinyG 中的实现方式。

如果我们走 SD 卡路线，我会将其设计到 grblshield 上，这样您就不需要多个屏蔽。我们还应该为归位开关和任何其他硬件要求制定首选引脚排列。

我读过高水位线和低水位线方案，但不知道它的用途。那讲得通。谢谢奥尔登。

假设我们两者都做。保留标准的“ok\n”响应以指示块/行已被接收和解析。有没有办法在连接时自动配置 XON/XOFF 协议？如果是这样，用户或界面可以选择使用其中任何一个。

grblshield SD 会很棒。尽管如此，如果支持 SD 卡，这将需要与生产中的任何东西兼容，我认为使用数字引脚 10-13。西门你怎么看？咬紧牙关并鼓动更改引脚分配？

这是对上位的很多竞争。如果您假设保持低端口与 0.6 引脚相同 – 不破坏对 RX/TX、3 步和 3 dir 位的支持 – 那么需要为 SD 卡或 3 限制/分配高端口位归位开关和 2 个主轴控制（根据 0.6 引脚排列）。所以你得到一个或另一个，但不是两者兼而有之。我想这就是权衡。

我会使用 XON/XOFF（高水位线/低水位线方案）协议。如果客户认可它，那很好：我们为拥有许多不同终端的用户提供了尽可能快地流式传输 gcode 的能力。如果用户应用程序忽略了协议，那么什么都不会丢失。
也应该可以忽略 XON/XOFF 并使用使用“ok\n”协议或计算发送的字符的流脚本。
此外，只要 gcode 逐行发送，运行时命令仍然可以通过任意终端发送（这在不使用流控制时也是必需的）。
如果流脚本告诉串行驱动程序不使用流控制，它仍然可以注入运行时命令。
这实际上是我实现任何客户端的方式：使用无流量控制驱动程序并在程序代码中处理 XON/XOFF（但要注意客户端缓冲区）。然后，程序仍然可以在 gcode 流被 XOFFed/halted 时发送运行时命令。
我真正看到的 XON/XOFF 的唯一缺点是与二进制数据不兼容。但是二进制数据仍然可以在 128…255（第 7 位设置）范围内发送，这也可以清楚地将其标记为二进制。

@chamnit：我们需要为每个轴单独的限位开关，以便在同时归位 x 和 y 时知道哪个轴已经完成。
@chamnit和 alden：你确定任何 atmega 都有足够的闪存用于 grbl 和 FAT 库。也许我们需要考虑一个背负式的第二个 arduino，它可以处理 SD 卡和用户界面串行通信（也许还可以计算步数或读取位置反馈）。我想我在 youtube 上看到过这样的设置。此外，最好保留一些用于硬件点动和馈电保持输入的引脚。
@sacidu93: 你的应用程序的源代码是公开的吗？

我不确定您为什么要使用二进制文件。我知道那里有一些效率，但它真的值得麻烦和复杂吗？在采取这一步之前，我宁愿先对传输时间和周期预算进行一些分析。打包/解包处理将增加，代码大小将增加，而字符数和传输时间将减少（这也可能会在一定程度上减少周期）。您可能会发现没有它实际上有大量的时间和带宽，您可以避免复杂性。

使用 115,200 作为默认波特率也值得一看。当我看到这个时，这是一个明智的选择，xmega 实际上只有 328 的 2 倍。没那么多，其实。

我完全同意。纯文本协议实际上是自我记录的。对于二进制，人们将不得不处理字节顺序和诸如此类的问题。我也同意波特率。以这种速度运行 grbl 没有问题——我已经做过很多次了。我为该发行版停留在 9600 的唯一原因是，我相信它是许多系统的默认汇率。它通常适用于大多数人，而无需深入研究他们的人文件。

坚持使用 9600 很酷（例如，它避免了设置 Coolterm 的步骤）。我想看看 9600 是否支持状态报告预期的数据更新率。100 个字符的行（我敢肯定，过多）大约需要 100 毫秒来传输，将可实现的最大更新速率设置为 10 Hz。这可能就足够了。

就是说：如果您想将文件转储到 SD 卡上，您可能会想解决这个问题。115,200 开始看起来不错。

同意。我真正想做但从来没有做过的事情是通过使用 RX 引脚的中断功能在启动时自动检测波特率，然后要求客户端点击几个输入字符来“唤醒”grbl。那将是严重的0-conf。

Riley 在他编写的控制台中做了类似的事情。它适用于 TinyG 和 grbl。它击中电路板，直到得到响应，然后进行相应的配置。板载自动波特率会很酷。那里必须有一些 atmega 示例代码。

也同意了。服务于终端和 GUI 的纯 ascii 协议应该是首选解决方案。我只是想解决对 XON/XOFF 的担忧。

哎呀！很多评论要回复。。

Alden：首先，我不是引脚分配方面的专家，但是我们有什么理由不能开始将模拟引脚用作数字引脚？我从 Arduino IDE 了解到这很容易。不确定在 C 语言中开发的方式或内容。

对于微处理器来说，两倍的速度非常重要。这些 CPU 的开销并不大，而且执行速度通常快两倍。从我开发 grbl 的经验来看，328p 的性能限制是真实存在的，我已经多次遇到过它。获得一些额外的周期会很棒。

simen and alden：好吧，我不得不承认我不知道传输二进制文件究竟需要什么。我假设这意味着您所要做的就是按照接收者已知和预期的设定顺序和大小发送每个变量的 8 位字符部分。（或者像 Jens 状态那样对 ascii chars > 127 使用 7 位二进制打包，这基本上解决了二进制的这个 xon/xoff 问题。）如果是这样，这可以非常快速有效地完成。

另一方面，我最近一直在浏览print.c源文件。要打印整数值，您必须对每个基数进行模和除。因此，对于 base10 中的数字 94857，您有 5 个模数和 5 个除数。把这一切加起来，假设你有大约 10 个整数/浮点值，每个值需要以 20Hz 的速率发送，grbl 将必须计算 1000 模数和 1000 除以每秒才能以所需的速率打印这些值。这加起来真的很快。如果我们可以显着优化打印功能，那么我完全可以不包括二进制传输的能力（不一定集成）。只是重申一下，二进制传输只需要高速状态报告，而不是其他任何东西。

至于提高波特率，我也以更高的波特率使用了 grbl ，没有任何问题。我读过，但没有经历过唯一需要注意的是丢失最高波特率的数据位，如果其他中断延迟串行中断按时执行。在 115200 波特下，每个脉冲约为 8.5 微秒，步进中断处理占用最少 3 微秒。

Jens：引脚开始出现短缺，特别是如果包含 SD 卡支持（不确定它是否适合 grbl）并且如果循环启动、进给保持和中止控制用作引脚。将限位开关销降低到一个将释放两个。可以重新编写归位周期以一次移动一个轴以翻转每个限位开关以定位归位。

不确定忽略字符的 XON/XOFF 协议是什么意思。将其设为用户 EEPROM 设置以启用/禁用 XON/XOFF 流控制会更好吗？这将是直截了当且容易做到的。用户就不必让他们的界面脚本忽略这些字符。

哦，真的很好，我完全忘记了 div 和 mods。有一些特殊的函数可以同时做 div 和 mod，因为 mod 总是 div 的副产品。但是对于浮点数，这仍然是一些处理器负载。
float 到 ascii 的转换还有其他方法。可以使用存储的数字 10000、1000、100、10、1、0.1 等，然后从要转换的数字中减去它们，计算使结果为负数所需的减法，这就是相应小数位的十进制值 (如果需要，我可以尝试重新找到示例源代码）。但这仍然是嵌套循环，也许您对二进制传输的必要性是正确的。

通过“忽略”，我的意思是从输入流中过滤 XON/XOFF 字符，否则不对它们做出反应……但这需要对流脚本进行一些更改。最初我认为偶尔的 XON/XOFF 字符可以像任何其他 grbl 响应一样打印到控制台，但这可能会破坏“ok\n”协议……我想得太快了。

我已经使用模拟引脚作为数字 IO 没问题，同样的程序，模拟甚至不需要禁用或任何东西。

我为 TinyG 编写了一些高效的字符队列处理程序，只是为了看看我能推多远。事实证明，如果您从顶部到底部加载队列，您可以在零上进行测试以执行换行操作，然后它就变成了指针或索引加载。这是最有效的方法（我认为），因为减为零设置 Z 状态位，因此分支“免费”出现，没有其他操作。这符合“使用 C 编译器作为机器人来编写如果你不是那么懒惰的话你会编写的汇编程序”的理念。如果需要，您可以在 xio 模块中找到代码。

关于模拟 IO 的好消息。我没有看到那个。如果将开关和主轴移动到电路板的模拟侧，似乎可以支持所有功能。

首先，我不得不说这是一次很棒的头脑风暴会议。惊人的。

看起来集成 XON/XOFF 方案可能是一件好事，但可能是任何用户都可以切换的高级设置。（这导致我的下一个问题是设置的结构应该是什么样子，但这应该从另一个线程开始。）无论如何，我们似乎有一些关于如何使用 XON/OFF 传输二进制文件的选项，即 7 位高位 ascii Jens 建议的角色（顺便说一句好主意）。对于不需要运行时命令或将这些控件移动到引脚的用户，这将大大简化流式 g 代码到 grbl。而且，如果需要通过软件运行时命令，任何人都应该能够编写自己的特定流接口。此外，如果我们允许这种切换，这不会让当前用户陷入困境，他们仍然可以使用他们的标准和简单的“ok\n”调用和响应协议。

如果有人需要查看有关如何实现 XON/XOFF 的示例代码，我相信 Jens 在他的 fork、edge 分支、serial.c 中有一个开始。

* Alden: *模和除来自二进制数到字符格式的转换。看起来 TinyG 使用标准库来打印和转换字符。Simen 在 print.c 中安装了他自己的相同打印方案的精简版，主要是为了最小化闪存大小，但我相信它的运行方式与标准库相同。

这对模拟 IO 引脚来说是个好消息。是否有人反对将主轴启用和速度引脚移动到模拟 0 和 1，同时将限位开关引脚减少到引脚 9 上的一个？还可以在模拟引脚 2、3、4 和 5 上支持 cycle_start、feed hold、about 和 jogging（切换开/关）。这将用完除数字 IO 10-13 之外的所有引脚，这将是为 i2c、sd 卡、以太网接口或其他用户分配的引脚保留。

打印语义不同，但最终结果是相同的。TinyG 将 AVRGCC stdio 库用于串行，并在包含 float 库时受到打击，因此它可以支持格式化的打印字符串（“J Offset = %8.3f\n”之类的东西）。这对于 328s 来说是太多的代码膨胀，所以它在 Arduino 硬件上并不是一个真正的选择。

除非绝对必要，否则我仍然对采用二进制路线感到不安。我认为对打印例程进行一些测试是有必要的。不必在接收端处理二进制文件会很好。

较早前的一个小修正 – 以 115,200 次运行的 USART 大约每 86 微秒中断一次，而不是每 8.6 微秒，因为每个接收到的字符（通常是 8 位、1 个起始位、1 个停止位）都会发生一次中断，所以它没有它那么糟糕似乎。

奥尔登。
除非需要，否则我不打算安装二进制报告方案。可以这么说，这是一项提前计划并确保我们
不会把自己画到角落里的练习。我猜对大多数
人来说，基于字符的报道会很好。对于想要
非常快速和实时报告的人来说，二进制可能是可行的方法，
至少在 328p 处理器上是这样。

115,200 波特的时序仍然正确。
每个USART 中断的 10 位字符序列的每个位每 8.6 微秒发送一次。

2012 年 1 月 26 日星期四下午 6:53，Alden Hart <
reply@reply.github.com

写道：

打印语义不同，但最终结果是相同的。TinyG
将 AVRGCC stdio 库用于串行，并尝试包含
float 库，因此它可以支持格式化的打印字符串（“J Offset =
%8.3f\n”之类的东西）。这对于 328s 来说是太多的代码膨胀，
所以它在 Arduino 硬件上并不是一个真正的选择。

除非绝对必要，否则我仍然对采用二进制路线感到不安。我认为对打印例程进行一些测试是有必要的。
不必在接收端处理二进制文件会很好。

较早前的一个小修正 – 以 115,200 次运行的 USART
大约每 86 微秒中断一次，而不是每 8.6 微秒，因为
每个接收到的字符（通常是 8 位、1 个起始位、1 个停止
位）都会发生一次中断，所以它没有它那么糟糕似乎。

---

直接回复此邮件或在 GitHub 上查看：
#50（评论）

同意所有观点。也许我误解了波特计时问题。处理器不需要关心 8.6 uSec 位时序（这是正确的），因为 USART 会处理所有这些。然而，处理器将每 86 uSec 中断一次，并且如果一个更高优先级的中断正在运行，该中断所花费的时间超过了串行字符的丢失时间。但这不是应该关注的情况，因为步进计时器进出的方式比这少。听起来我同意你的观点，但在细节上争论不休。不管。只是我脑子有问题。

我想现在是对这次讨论进行总结的好时机：

• 将 XON/XOFF 流控制安装为可切换设置，无论是在编译时还是在 EEPROM 中（将讨论如何）。这将为用户提供一个更简单的界面，用于流式传输 g-code sans 运行时命令。更高级别的用户可以并且应该编写自己的高级界面。’ok\n’ 和 ‘error:’ 协议将保持不变。
• 更高的波特率可用作编译时设置，并且可能需要高于 9600 波特才能获得快速状态报告。这也可以作为 EEPROM 设置使用（将开始关于设置的新讨论）。如果我们可以将其作为自动配置来执行，那就更好了。
• 返回给用户的数据，即状态报告，将仅采用 ascii 格式。暂时不会正式支持的二进制数据可能会被打包到更高的 ascii 字符集中以避免流量控制问题。

如果有人对这些观点有任何异议，请让大家知道。否则，我们会将这些要点作为目标并继续前进。在其他线程上仍然需要解决的其他事情是引脚重新分配以供未来使用和开发以及如何处理高级设置。

大家好。我是新来的，但已经潜伏了很长时间。我自己一直在玩一些想法。不要劫持线程，但我已经有一大堆 ATMega32，所以我一直在使用它，并进行了一些小的改动。（基本上是一个新的#include 到 config.h 映射寄存器，因此不需要 grbl 核心更改）如果有人感兴趣，我可以发布它。

回到主题，我前段时间用 Mega32构建了这个http://sensi.org/~svo/motori/ 。（我不是作者/设计者）它还使用了 RTS/CTS 握手并且代码可用。

我的偏好是进行硬件握手。

嗨nm156。劫持没问题。Grbl 是一个社区，开源的努力，所以评论和想法被张开双臂接受。能够创建一个简单的配置文件来移植到 atmega32 真是太好了。至少对我来说，在 grbl 代码库稍微固化之前，我不打算开始移植到其他硬件平台/CPU。但是，我总是留意那些在时机成熟时会让人们更容易的事情。

硬件握手会很好，但据我了解，Arduino Uno USB 端口没有此功能，只能进行软件流控制。仅将 RX/TX 引脚引出并使用其他数字引脚进行硬件控制是可行的，但我认为这超出了当前开发路径的范围。

Chamnit 是对的：在 arduinos 上，RTS 和 CTS 没有正确接线。原因之一是 RTS 用于通过 USB 为 ISP 重置 atmega，无需任何进一步的用户交互。这是 arduinos 的一个很好的特性，恕我直言，这是即使在 avrgcc 程序员中也能取得成功的原因之一。当然，这并不意味着 grbl 应该是一个只有 arduino 的项目，相反！但是 arduino 可能会一直保持 grbls 的“大本营”。因此，在适当的时候，我们将不得不开始弄清楚如何设置定制/移植框架，可能是预处理器驱动的，就像 mm156 为 atmeag32 所做的那样。
顺便说一句，非常好的绘图仪。

对不起，伙计们，我应该先检查一下 Arduino。我使用 AVR 和 WinAVR 已经有一段时间了，但从未使用过 Arduino 的东西。我完全同意你的看法，拥有广泛的标准化基础是该项目非常重要的一部分。

在过去的几天里，我一直在玩 grbl 中的 XON/XOFF 流控制。我不得不说，除了问题，我什么都没有，也许与 Simen 最初的运气相似。（可能与使用 Mac 有关，但我也尝试了 Windows XP 虚拟机）。尝试了几个程序（屏幕、CoolTerm、PuTTY）和旧的 Mac 电脑，在发送一个曲线繁重且快速的 g 代码程序后，所有结果都不同。大多数时候，终端程序没有暂停传输并溢出 grbl 的缓冲区。XP 虚拟机上的 PuTTY 表现“最好”，但有时仍会失败。

至于高低水印，我使用的设置是 96 字节 HIGH 和 32 LOW 以及 128 字节缓冲区。我也试过 256 字节。我知道 Alden、stephanix 和 Jens 对此没有任何问题，但我似乎无法弄清楚为什么我没有取得任何成功。Jens 和 stephanix 等的 XON/XOFF serial.c 源代码已被使用，但都存在相同的问题。任何人都可以对此有所了解吗？

我确定问题出在客户端。串行编程很棘手，快速谷歌搜索表明，即使是“好”的程序也有其弱点。
我知道 java rxtx 也有点问题。但也许它有助于进行一些低级调试。您可以在 MATLAB 中使用 java 代码，从而对串行端口进行低级命令行控制。或者您使用python api，但我不确定它为您提供了多少访问低级别设置（例如发送缓冲区大小）的权限。
祝你好运

我也开始得出这个结论。但是，在谈话的早些时候，听起来任何终端程序都应该能够正常传输。我猜不是。几天前，我正在研究 CoolTerm 的保存文件。结果发现有一个默认为 256 字节的 TX 块大小隐藏参数。将此更改为 1 字节有所改善，但并未解决文件传输问题。这似乎支持了这个论点。

所以，如果不是所有的标准终端程序都可以很好地使用 grbl 的流控制，那么包含它有什么意义吗？听起来它确实需要一个特殊的低级接口才能真正利用它。如果我们确实包含它，我们是否甚至需要有一种方法来打开和关闭它？我的意思是，如果用户只是通过简单的调用和响应与 grbl 通信，并且 XON/XOFF 流控制的高水位线（比如 96 个字符）设置为大于 g 的任何单行的长度-code，他们应该永远不会看到返回的 XOFF 字符，也不会看到 XON。

这是关于 XON/XOFF 的状态更新。我无法成功地让 XON/XOFF 流控制与标准终端程序可靠地工作，主要是因为无法控制它们在系统和程序之间的内部工作方式。但是，我已经能够获得一个非常强大的 Python 流式处理脚本，该脚本几乎可以稳定地处理我扔给它的任何东西，尤其是在高进给率下。它在不使用内置 pySerial 流控制的情况下处理低级串行通信。

我还将低水位（XON 标志）标记设置为 80 个字符，将高水位标记设置为 110。80 个字符的标记在那里，因此传统的调用和响应在没有流控制字符的情况下仍然有效，但我可以改变这一点。

所以，我的问题是：有没有人有理由让我不包括这个？我是否应该将此作为编译时选项仅用于高级用户测试？我很难决定如何处理这个问题，因为这改变了很多事情，我仍然不确定这是否是正确的方法。

我在 GRBL 的早期版本中尝试过 XON/XOFF。GRBL 中的串行通信模块进行了一些修改，我使用 .NET 框架 4.0 在 PC 端制作了一个小客户端。结果，它不能正常工作。即使我尝试了 Coolterminal 和其他程序，它也没有像我预期的那样工作。所以我使用应用程序流控制。从主机程序发送 G 代码后，我的主机客户端等待“OK”。在我从 GRBL 收到正确的“OK”消息之前，不会发送任何 G 代码。

另一个问题是在主机程序中。主机程序应检查每个字节。不是基于字符串的操作。
例如，当我们发送“G0 X10 Y20 Z30”时，在某些情况下，发送缓冲区保持“0 Z30”，因为 GRBL 控制器不会生成对齐的 XON/XOFF。当我们在低级别处理 XON/XOFF 时，主机程序和 GRBL 中的情况都会变得复杂。所以最好在更高级别实现 XON/XOFF 以与一个完整的 G 代码行对齐。
这可能无法有效地使用缓冲区。但是如果你在许多不同的波特率和缓冲区大小下测试很多 GRBL，你就会知道它的差异可以忽略不计。

因此，不仅对于控制器端，主机程序应该关心所有情况。因此，由于 XON/XOFF 软件流控制，主机程序变得复杂。

商业 DNC 软件通常使用硬件流控和 XON/XOFF 软件流控。
他们使用 RS-232C 或 RS485。USB 串口不同于原来的 RS-232。

有趣的。很高兴知道我不是唯一一个有问题的人。我
一直怀疑可能有某种中间缓冲区
阻止 xon xoff 流正确移动。经过一番挖掘
，我开始认为是
arduino uno 上的 atmega8U2 USB 转串行芯片导致了问题。看起来它有一个小的 8-64
字节数据包缓冲区。不能肯定地说这是正确的，但
我肯定会更多地研究这一点。

2012 年 2 月 21 日下午 6:38，pauljay
reply@reply.github.com
写道：

我在 GRBL 的早期版本中尝试过 XON/XOFF。GRBL 中的串行通信模块进行了一些修改，我使用 .NET 框架 4.0 在 PC 端制作了一个小客户端。结果，它不能正常工作。即使我尝试了 Coolterminal 和其他程序，它也没有像我预期的那样工作。所以我使用应用程序流控制。从主机程序发送 G 代码后，我的主机客户端等待“OK”。在我从 GRBL 收到正确的“OK”消息之前，不会发送任何 G 代码。

另一个问题是在主机程序中。主机程序应检查每个字节。不是基于字符串的操作。
例如，当我们发送“G0 X10 Y20 Z30”时，在某些情况下，发送缓冲区保持“0 Z30”，因为 GRBL 控制器不会生成对齐的 XON/XOFF。

因此，不仅对于控制器端，主机程序应该关心所有情况。因此主机程序在 XON/XOFF 软件流控制中变得复杂。

商业 DNC 软件通常使用硬件流控和 XON/XOFF 软件流控。

---

直接回复此邮件或在 GitHub 上查看：
#50（评论）

好的。我想我已经找到了罪魁祸首。它是 Arduinos 上的 USB 串行仿真器芯片，Uno 上的 atmega8U2 和旧版本上的 FDTI 芯片。数据包存在问题，以及它们如何以及何时从 Arduino 发送到计算机以及从 Arduino 发送到计算机的时间。Arduino 328p CPU 以设定的波特率与 USB 芯片通信，但一旦到达 USB 芯片，它就有自己的发送和接收缓冲区来与用户的计算机通信。在定时器结束后，两个芯片在完整或不完整的数据包中传输大约 64 字节的数据包。Uno 的等待时间为 4.1 毫秒，而 FDTI 芯片的等待时间要长得多，为 8-16 毫秒。

这意味着 XOFF 字符可能会卡在 USB 芯片缓冲区中并被延迟足够长的时间而无法被终端程序识别，这将继续发送字节并溢出 Arduino 串行接收缓冲区。最重要的是，（如果我理解正确的话）USB芯片上还有一个接收缓冲区。我认为 USB 协议将 64 字节数据包发送到 Arduino USB 芯片，然后以串行波特率发送到 Arduino 328p CPU。

因此，简而言之，XON/XOFF 字符可能会在 USB 串行仿真器芯片中延迟，而计算机一次将继续发送多达 64 字节的数据包。

这里有一些链接供参考：UNO 串行延迟，Teensyduino

看起来 XON/XOFF 可能不是要做的事情，这也许是 Arduino 人决定不在他们的 IDE 中支持这个的原因。我让它工作的唯一方法是明确地等待一个字节写入 USB 串行仿真器，然后写入 Arduino，然后再继续写入下一个字节。这可能是海市蜃楼，可能不适用于所有平台。大家对此怎么看？

很不错的侦探作品！所以如果我没看错的话，当 XOFF 卡在 FTDI 的 TX 端时，arduino 的 RX 端可以接收大约 16 – 20 个字符（9600 波特）。这假设主机立即停止传输，但它不会。所以考虑到传输和主机延迟，假设还有 16 毫秒（我只是在这里猜测 – 它必须被测量，并且可能会因发射器及其缓冲方案而异）。这意味着高水位线需要至少比缓冲区限制低 40 个字符，然后才会开始丢失字符。或者如果您处于 USB 数据包级别，则可能是 40 到 64。这有意义吗？

1. 认为
   USB芯片的行为是合理的，但我真的很想知道为什么以前没有人遇到过这个问题。特别是对于 Uno 板，可能会有补救措施，因为执行 USB 通信的 atmega8U2 正在运行开源的 LUFA ( http://www.fourwalledcubicle.com/LUFA.php )。atmega8U2 的 ISP 引脚是可访问的。因此，理论上，应该可以破解 Uno 板以启用 XON/XOFF 流控制。但这项事业的成本效益比值得怀疑。（尽管对于某些人来说可能仍然是一种选择）。
2. 恕
   我直言，是时候想出一个替代方案了。虽然我没有使用过，但我认为 Chamnits 字节计数脚本既快速又安全。也许有效地使用 grbl 只需要使用特殊的 IU 或脚本。
   —> RIP 百变终端程序，RIP XON/XOFF？？？

詹斯，你可能是对的。我仍然会在 TinyG 中保留 XON/XOFF，但它的实用性似乎正在减少。

逐块同步具有能够轻松插入恐慌字符的额外优势：
！用于进给
~ 用于循环开始
X 用于中止

我尝试了串行缓冲区大小和高水位线的各种排列。似乎没有什么能完全摆脱这个问题。它变得越来越好，越来越少，但似乎并没有完全消失，至少在所有标准终端程序中是这样。随着主机驱动程序的变化以及终端程序的不同，我可能会说这个解决方案并不适合所有人。

Jens：我有点想知道为什么人们以前没有遇到过这种情况，但是在快速搜索“USB 串行延迟”之后，显然人们遇到了。这个问题会出现在任何实时并涉及快速和即时串行通信的情况下，例如将 g 代码流式传输到 grbl。在我为 Arduino 看到的所有 XON/XOFF 流控制中，似乎人们编写了特殊的低级接口，就像我已经开始工作一样，让它们工作。

您绝对可以在 UNO 上重新刷新 atmega8U2 芯片，但这并不是每个人都知道或愿意做的事情。我不能说您也不会遇到 USB 协议本身的一些问题。也许这是限制的实际来源。

也许发送和响应是唯一绝对可靠的解决方案，因为您绝对知道 grbl 和计算机之间没有任何额外的字节。它可以像我们一直在做的那样通过“ok”响应来完成，或者像 XON/XOFF 使用一些特殊字符来完成（但不是按照它的预期用途。）

Simen，看来我们又回到了最初使用您的解决方案的地方。关于从这里去哪里的任何想法？

我会说收工，然后睡一觉。值得探索。想想我们现在对 XON/XOFF 了解多少！遗憾的是 cat file.gc > usb_port 的梦想没有实现，但也许就是这样。

听起来不错。我认为仍然有一个用于非 USB 用户界面的 XON/XOFF 实用程序，例如用于无头控制的第二个 Arduino。所以，我想我将把它作为一个编译时选项集成，只有在官方不支持它的规定下，但可能会在某些 UI 场景中使用。我会清理代码并在这个周末推送它。

多么令人难以置信的侦探作品！

只是一个疯狂的想法：是否有可能通过在 XON 之后悲观地发送 XOFF 并尝试让客户端一次发送“单个数据包”来“涓流加载”数据？如果数据包大小为 64，我们还应该将 grbl 的串行缓冲区增加到 80 左右，以使这种疯狂的方案有任何工作机会。

这显然是非标准的，并且工作的机会很小，但是如果您准备对其进行测试，可能值得一试吗？

不幸的是，我已经尝试过它，以及其他一些类似的东西，但似乎没有任何东西可以始终如一地或非常有效地工作。Coolterm 具有字符延迟功能（以及 pySerial），可以将每个字符的传输延迟一些 ms 时间段。如果延迟足够高，它会起作用，但会导致 grbl 计划器中的缓冲区不足问题。

我一直在与 Alden 离线谈论他在 TinyG 和 XON/XOFF 流控制方面的成功。我认为这是硬件上的差异，但似乎他使用的是 Arduino Duemilanove 使用的 FTDI RS232RL 芯片。我已经阅读了芯片上的数据表，显然它支持 XON/XOFF 握手（无论这意味着什么）。这可能意味着如果 FTDI 正确管理流量，Duemilanove 可以执行 XON/XOFF。我只有带有 Atmega8U2 的 Arduino Uno，根据其数据表不支持 XON/XOFF 握手。

有人有 Duemilanove 来测试这个理论吗？

我有 2 个带有 FTDI 芯片的 Duemilanoves。我可以给你发一份，或者我可以进行测试。

胡说八道，

我今天要尝试 XON/XOFF，但我只是在想，如果问题是 XOFF 没有在合理的时间内设置，因为它正在等待 FTDI 芯片的缓冲区填充，你能不能用 65 个 XOFF 字符来强制 FTDI 芯片的缓冲区填充并立即发送？我不认为主机控制程序关心或计算它接收到的 XOFF 字符的数量，只是一旦它有一个 XOFF，它会在恢复传输之前等待一个 XON 字符。

只是一个想法……
布鲁斯

我想你可以，但它真的会消耗应该用于状态报告的传输带宽，并且需要 grbl 上的大接收缓冲区，这是我们负担不起的。我对此进行了深入研究（可能比我想要的更多），但一切都表明这是 Arduino Uno 及其他设备中的 Atmega8U2 USB 串行转换器芯片的问题。带有现已淘汰的 FTDI 芯片的旧 Arduinos 应该可以工作，我会确认 Alden 的 Duemilanove 板何时到货（感谢 Alden！）。

我确实确认了 LUFA 的 atmega8U2 固件不管理该芯片的中间 USB 串行缓冲区中的 XON-XOFF 流控制字符。在 LUFA 开始在他们的库中进行这种管理并成为 Arduinos 的标准之前，我认为 XON/XOFF 流控制不会成为 grbl 的标准接口，因为库存的 Arduino 不支持它。虽然，有多种方法可以解决这个问题：获取一个 FTDI 分线板/电缆并完全绕过 atmega8u2 芯片，直接连接到也绕过 atmega8u2 芯片的 Arduino 的 RX/TX 引脚，或者只使用字符计数’/scripts/stream.py’ 流脚本中的方案与使用 XON/XOFF 流控制本身一样有效。

再说一次，我可能完全错了，我的设置或 Arduino 出了点问题，但我没有遇到任何与此相矛盾的东西，除了旧 Arduinos 上的 FTDI 芯片应该可以工作。当我拿到板子并测试它时，我会发布我的结果。

只是一个更新。我看了看我的 Arduino 克隆，它确实有一个 FTDI USB 芯片。XON/XOFF 仍然不起作用。我使用的是 Windows Hyperterm，只是爆破了一个 G 代码文件，它从未停止过文本。我在 Hyperterm 中使用 XON/XOFF 协议，除了我的归位例程分支外，我还在使用您的最新版本（带有 xon/xoff 的边缘）。

我计划进行更多测试，但看起来 XON/XOFF 可能会破产……

Bruce
PS 我正在使用的 Uno 克隆来自 OSEPP。它使用FTDI FT232RL芯片。不知道这是否有帮助。

HyperTerm 对我也不起作用。这就是为什么我改用似乎有效的腻子。但老实说。我没有进行任何有意的压力测试。

Bummer .. 我确实记得当我在 Windows 端进行试验时，PuTTY 确实倾向于工作得更好。Coolterm 是 Alden 使用的，还有一个 Windows 版本。XON/XOFF 确实在从 grbl、USB 串行适配器、Windows 环境设置和终端程序本身的各个级别上看起来都非常敏感。

在我上次推送的 XON/XOFF 版本中，它有一些通用设置，我在这里和那里更改了逻辑以进行实验。如果您仍然有一些动力，请尝试将 if 语句更改为 (flow_ctrl == XON_SENT) 用于 XOFF 和 (flow_ctrl == XOFF_SENT) 用于 XON 例程。您还可以尝试使用高水位线和低水位线以及缓冲区大小（注意这一点。您可能需要通过暂时将规划器缓冲区减少到 16 来释放内存空间。）。

祝你好运。我认为奥尔登的 Duemilanove 明天或周六应该会在这里。所以我坐在我的手上，可以这么说，直到它进来。

成功！苦乐参半。我刚刚收到了 Alden 的 Duemilanove，XON/XOFF 与它完美配合。（我不得不快速将芯片从我的 Uno 移植到 Duemilanove，因为我无法立即让它闪烁。也许与引导加载程序有关。）据我所知，它似乎可以正常工作，没有任何明显的问题，但我m 仅通过示波器查看它，并具有足够安全的缓冲区大小和水印。无论如何，这几乎证实了我对 Atmega8U2 是问题的怀疑，因为 FTDI 芯片的工作方式完全不同。日日夜夜。

有问题并且知道它是什么比没有问题但不知道它是什么（等一下）比有问题但不知道它在哪里（不，不是它……）更好，而不是结知道你有问题你知道我在说什么吗？【我明天早上再试试。这是一个漫长的一周……]