cncdriver 只是说错误并停止发送 gcode。将不得不记录
这一点。
在我尝试使用其他流媒体程序之前，我认为这是 gcode 发件人的问题。
它与我过去使用通用
gcode 发送器记录的问题相同

收卷机/通用-G-Code-Sender#22

2012 年 11 月 19 日星期一下午 6:23，Sonny Jeon notifications@github.com写道：

将此移至新问题：

@whitetd https://github.com/whitetd

是否还有其他人在开始早期就掉线时遇到问题
？

我一直在重复这条线，它有效，但有点痛苦。使用
通用 gcode 发送器，与其他程序一起它会给出错误并
停止。

特里

你能详细说明它给出了什么样的错误？它在同一条线上吗？
您发送的 g 代码块是什么？它可以与
流脚本一起使用吗？

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/141。

嗯。。好。我个人从来没有遇到过跳行的问题，但我
一直只使用我们支持的流脚本。我没有尝试过任何
这些接口。我会尝试玩一个，看看是否能找到任何
问题，但这似乎是接口问题或 g 代码问题。你能给
我们发送一个错误的例子吗？这种情况多久发生一次？
它是在同一行还是在一定数量的
行上始终如一地发生？

2012 年 11 月 19 日星期一晚上 7:33，whitetd notifications@github.com写道：

cncdriver 只是说错误并停止发送 gcode。将不得不记录
这一点。
在我尝试使用其他
流媒体程序之前，我认为这是 gcode 发件人的问题。
它与我过去使用通用
gcode 发送器记录的问题相同

收卷机/通用-G-Code-Sender#22

2012 年 11 月 19 日星期一下午 6:23，Sonny Jeon notifications@github.com写道：

将此移至新问题：

@whitetd https://github.com/whitetd

是否还有其他人在开始早期就掉线时遇到问题
？

我一直在重复这条线，它有效，但有点痛苦。
使用
通用 gcode 发送器，与其他程序一起它会给出错误并
停止。

特里

你能详细说明它给出了什么样的错误？它在同一条线上吗？
您发送的 g 代码块是什么？它可以与
流脚本一起使用吗？

—
直接回复此邮件或在 GitHub<
https://github.com/grbl/grbl/issues/141&gt;上查看。

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/141 #issuecomment-10540666。

随机行，但仅在前 20 行的早期。图像显示
了通用 gcode 发送器，我将不得不走出车库并设置一个
小测试，以获取有关 cncdriver 错误的更多详细信息。没用过
这个脚本，试试。因为我看到其他人有同样的问题，所以我
懒得说什么，但没有看到任何解决方案。所以我想
我会检查。可能要到明天才能得到更多细节。

2012 年 11 月 19 日星期一下午 6:39，Sonny Jeon notifications@github.com写道：

嗯。。好。我个人从来没有遇到过跳行的问题，但我
一直只使用我们支持的流脚本。我没有尝试过任何
这些接口。我会尝试玩一个，看看是否能找到任何
问题，但这似乎是接口问题或 g 代码问题。
你能给
我们发送一个错误的例子吗？这种情况多久发生一次？
它是在同一行还是在一定数量的
行上始终如一地发生？

2012 年 11 月 19 日星期一晚上 7:33，whitetd notifications@github.com
写道：

cncdriver 只是说错误并停止发送 gcode。将不得不记录
这一点。
在我尝试使用其他
流媒体程序之前，我认为这是 gcode 发件人的问题。
它与我过去使用通用
gcode 发送器记录的问题相同

收卷机/通用-G-Code-Sender#22

2012 年 11 月 19 日星期一下午 6:23，Sonny Jeon notifications@github.com写道：

将此移至新问题：

@whitetd https://github.com/whitetd

是否还有其他人在开始早期就掉线时遇到问题
？

我一直在重复这条线，它有效，但有点痛苦。
使用
通用 gcode 发送器，与其他程序一起它会给出错误并
停止。

特里

你能详细说明它给出了什么样的错误？它在同一条线上吗？
您发送的 g 代码块是什么？它可以与
流脚本一起使用吗？

—
直接回复此邮件或在 GitHub<
https://github.com/grbl/grbl/issues/141&gt;上查看。

—
直接回复此邮件或在 GitHub 上查看<
https://github.com/grbl/grbl/issues/141#issuecomment-10540666&gt;。

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/141 #issuecomment-10540765。

我确定这不是 Grbl 问题……也许 Java 和 Python 处理 com 端口的方式有所不同。？python 脚本整天运行，没有问题。如果缓冲区设置为 127，Universal Gcode Sender 会出现一些问题，但我发现如果将缓冲区更改为 60，我将无法再重现该问题。从这里我猜它发送的速度很快，而 Grbl 内存不足或类似的东西。或者它没有发送线路。我将在 Will Universal Gcode Sender tracker 上将详细信息添加到我的错误报告中。

有趣的。感谢您确定原因。过去，在尝试使 XON/XOFF 流控制正常工作时，我在 USB 到串行转换方面遇到了一些问题。总之，USB 发送不同大小的数据包，通常为 64 字节。它可能会发送一个巨大的初始数据包并在进入流媒体之前截断某些内容。只是一个理论。

缓冲区设置在哪里？

2012 年 11 月 19 日星期一晚上 9:08，Sonny Jeon notifications@github.com写道：

有趣的。感谢您查明原因。
过去，在尝试使 XON/XOFF 流
控制正常工作时，我在 USB 到串行转换方面遇到了一些问题。总之，USB 发送不同大小的数据包，通常为 64
字节。它可能会发送一个巨大的初始数据包并
在进入流媒体之前截断某些内容。只是一个理论。

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/141 #issuecomment-10543104。

找到它，看起来它正在工作，设置为 64 并测试

2012 年 11 月 19 日星期一晚上 9:46，Terry White whitetd@gmail.com写道：

缓冲区设置在哪里？

2012 年 11 月 19 日星期一晚上 9:08，Sonny Jeon notifications@github.com写道：

有趣的。感谢您查明原因。
过去，在尝试使 XON/XOFF
流控制正常工作时，我在 USB 到串行转换方面遇到了一些问题。总之，USB 发送不同大小的数据包，通常为 64
字节。它可能会发送一个巨大的初始数据包并
在进入流媒体之前截断某些内容。只是一个理论。

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/141 #issuecomment-10543104。

公共静态最终 int GRBL_RX_BUFFER_SIZE=60

仍然无法正常工作。

2012 年 11 月 19 日星期一晚上 9:57，Terry White whitetd@gmail.com写道：

找到它，看起来它正在工作，设置为 64 并测试

2012 年 11 月 19 日星期一晚上 9:46，Terry White whitetd@gmail.com写道：

缓冲区设置在哪里？

2012 年 11 月 19 日星期一晚上 9:08，Sonny Jeon notifications@github.com写道：

有趣的。感谢您查明原因。
过去，在尝试使 XON/XOFF
流控制正常工作时，我在 USB 到串行转换方面遇到了一些问题。总之，USB 发送不同大小的数据包，通常为 64
字节。它可能会发送一个巨大的初始数据包并
在进入流媒体之前截断某些内容。只是一个理论。

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/141 #issuecomment-10543104。

呃…我不确定如何尽可能谨慎地表达这一点，特别是考虑到我对大多数 PC 编程语言的理解，特别是对 Java 的理解几乎为零，但是……尝试镜像 grbl 的内部缓冲区以找出它何时已满以及何时未满的机会（为什么它甚至需要该设置）？因为如果这就是它的作用，请原谅我，我需要长时间在合适的墙上撞我的头。

我们知道 Grbl 示例文件夹中的 python 脚本可以工作……或者至少它从来没有为我跳过一行 gcode。通常，对我来说失败的总是同一行，并且在 Universal Gcode Sender 中使用缓冲区大小会更改此行号。我有一个设置是我的文件刚刚工作，那是 60，我想这是一个巧合，只为这个文件修复了它。据我了解，python 脚本和 Jave 代码正在尝试做同样的事情 – 跟踪内部缓冲区并仅在有空间时发送。我想如果你发送到多行快速 Grbl 无法跟踪并跳过部分，如果你一次只发送一行并等待它会慢很多。

好吧，事情就是这样（对不起，不能早点回复，没有时间测试东西）-恕我直言，这种功能重复通常是一个坏主意，也是一个非常非常脆弱的解决方案-如果两种算法都不是’ t 工作完全相同，它们可能会失去同步并且事情会中断（这通常只是软件更改的时间问题）；需要通过参数匹配缓冲区大小 – 正如已经看到的 – 这可能会不匹配等。简而言之，它不是一种强大而可靠的做事方式，而且我非常喜欢快速移动时的这些品质涉及金属，尤其是通过正确阅读此线程来见证后果。

但问题是 – 据我所知，为什么我们总是如此急切地试图填充 grbl 的缓冲区，只需在收到前一个命令的“ok”后一次发送一个命令即可完成完全相同的事情： grbl 在它“ok”之前不会等待命令真正完成，它会立即回复！我可以轻松地输入 3-4 个命令（在得到所有命令的“ok”回复之后），而第一个命令仍在执行！所以“缓冲饥饿”绝对不是我们应该归咎于需要流式传输的事情。

从理论上讲，也许如果第一个命令非常短（可能只有几步之遥），可以想象它会在下一个命令到达之前完成，但是 a) 这实际上不是一个错误，它只是次优 b) 首先移动往往是慢跑到入口点或慢速Z 轴馈送到材料上 – 在回复返回和发送下一个命令（基本上是毫秒）之前几乎不会完成执行的事情。在那之后，grbl 将连续缓冲尽可能多的动作，因为它可以在内部排队，即使是简单的命令-回复-命令-回复操作，也无需查看任何缓冲区大小。那么我们为什么不这样做呢？

至少，从这里看是这样的。现实检查，请。我错过了什么吗？

根据我使用 Grbl 的经验，大多数人不会对简单的调用和“确定”响应协议有任何问题，但在某些情况下这确实会成为问题。

例如，如果您使用激光切割机在曲线上移动非常高的进给率，则该曲线会分成非常小的线段。这有两个问题：（1）为了确保 Grbl 以绝对最快的速度移动，它需要将缓冲区保持在最大值，因为它在缓冲区结束时计划降为零。(2) 串行接口的延迟可能大到足以导致缓冲区不足。结果：您的激光切割机在饥饿时会启动和停止（颤抖）。破坏一部分。

保持缓冲区充满对于可重复和良好的零件非常重要。在金属轧机上，必须以预期的进给速度进行切割。否则，工具会因材料表面的加工硬化而磨损过快。基本上是把它擦死。

如果一切都是最优的，我们将对流信息进行某种自动流控制，但是 Arduino 的硬件流控制引脚被它们的复位和上传协议占用，并且他们摆脱了 FTDI USB 串行芯片，因为UNO，因此不再存在 XON/XOFF 软件流控制。

本质上，字符计数方案执行 XON/XOFF 流控制，但它是一方面。它也有效。可靠。如果我们要支持 Arduino 以外的硬件，我会确保安装某种类型的流控制方案。但是由于 grbl 是为 Arduino 构建的，所以我们必须做到这一点。

是的，我认为线转换的弧线可能是一个敏感点，但我想问题归结为这一点：串行延迟真的会高到使之前完全排队的（运动）缓冲区饿死运动块，如果串行缓冲区没有也抽满？这是一个实际观察到的现象吗？我们在这里谈论什么样的数字（馈送、距离、延迟）？

是的，它在某些情况下会饿死。有些人在半专业环境中为 2D 刀具 (Gerber) 应用程序以 50kHz 的步进频率和高进给率工作。即使它们以 115200 波特率运行，它们仍然存在传输信息速度不够快的问题。

在铣床上，您可能会遇到 Arduino 上的 Grbl 库存缓冲不足的情况，即在一些快速进给速率的材料（如 delrin 塑料）中铣削复杂的轮廓。这完全取决于它所驾驶的机器。大多数在 Grbl 上常见的桌面 CNC，您可能永远不会看到这个问题。在一个体面的更强大的金属厂，你可能会。

这一切都归结为 g 代码所基于的非常小的行的问题。很古老。大多数新生产的 CNC 不再使用这样的 g 代码，但它们使用贝塞尔曲线/矢量曲线来创建高速加工的刀具路径。因此，他们可以如此快速地加工东西，而不会出现缓冲不足的问题，从而可以向您出售诸如一体式 Macbook 之类的东西，每个订单由单个铝坯加工而成。

无论如何，每当运行任何复杂的曲线程序（很多线段）时，填充 Grbl 上的规划器缓冲区和串行读取缓冲区总是一个好主意。在某些时候，我一直在考虑创建 Grbl 的高速加工版本，但那是下线了。

感谢您的详细解释。当然，在所有条件相同的情况下，缓冲更多总是更好，但我想知道串行缓冲区完成的额外缓冲有多大的区别真的很重要——毕竟，正是这样：一些额外的缓冲超出了队列运动块，不是从根本上消除问题的东西 – 它只是在一定程度上有所帮助。毕竟，没有保证访问延迟的本地存储，整个代码都被缓冲，没有什么可以保证规划器在适当的情况下不会饿死。这是数量而不是质量的差异，这就是我询问实际数字的原因。如果您说这是通过流媒体解决的实际观察到的问题，

我想知道保持“流式”样式提要有多难，但通过在“ok”回复之后包含剩余的可用缓冲区空间来使其更加健壮。发送将遵循与现在类似的逻辑，但它不必猜测缓冲区大小，并且永远不应该去同步；一个人会先发送一个空行，然后接收一个“ok”加上可用空间量（=此时缓冲区的完整大小）；在那之后，一个人会发送尽可能多的东西（就像现在一样），然后等待当前可用空间量的“ok”，填满等等。

这可能看起来像附加（比如“ok:128”），或者它可能会通过以稍微不同的方式发送命令（比如，以特殊字符为前缀）来提示，在这种方式中手动输入的命令和旧版客户端甚至都看不到额外的数据。

你好白！

请试试这个，让我知道这是否也为你解决了这个问题。

转到 SerialCommunicator streamCommands 方法并
在 nextCommand 之后添加这个 25ms 尝试睡眠块…在我这样做之后我没有得到问题

• 也许某种多线程和java的竞争条件以及
  如何处理OK？

在我的文件第 313 行：

             // Load the next command.
             if (this.commandBuffer.hasNext()) {
                 this.commandBuffer.nextCommand();
                 try
                 {
                     Thread.sleep(25);
                 }
                 catch ( Exception e )
                 {
                     e.printStackTrace();
                 }
             }

2012 年 11 月 20 日上午 1 点 26 分，whitetd 写道：

公共静态最终 int GRBL_RX_BUFFER_SIZE=60

仍然无法正常工作。

2012 年 11 月 19 日星期一晚上 9:57，Terry White whitetd@gmail.com写道：

找到它，看起来它正在工作，设置为 64 并测试

2012 年 11 月 19 日星期一晚上 9:46，Terry White whitetd@gmail.com写道：

缓冲区设置在哪里？

2012 年 11 月 19 日星期一晚上 9:08，Sonny Jeon
notifications@github.com写道：

有趣的。感谢您查明原因。 过去，在尝试使 XON/XOFF 流控制正常工作时，我在 USB 到串行转换方面遇到了一些
问题。总之，USB 发送不同大小的数据包， 通常为 64 字节。它可能会发送一个巨大的初始数据包并 在进入流媒体之前截断 某些内容。只是一个理论。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/ /issues/141 #issuecomment-10543104。

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

@blinkenlight: 如果我们有流量控制，这将解决所有这些问题。我确实安装了 XON/XOFF 软件流控制作为其板上具有 FTDI USB 串行芯片（Duemilanove 或更早版本，Seeeduino）或使用某种 FTDI 电缆的用户的编译时选项。我已经在 Duemilanove 上试过了，它工作得非常完美。您几乎可以使用任何串行终端程序并上传文件。基本上和你问的一样。它在缓冲区接近满时发送一个标志，另一个在接近空时重新开始流式传输。

主要问题是，当我发现用 UNO（不带 FTDI 芯片）将我的头撞到墙上时，USB 协议做了一些奇怪的事情。它来回发送难以在流式基础上管理的数据包。因此，数据流可以是异步的。这就是我们必须执行此调用和响应协议的原因。它消除了这个问题。（我认为 FTDI 芯片有某种内部缓冲区来处理这些事情，然后再将其传递给 328 芯片。）字符计数也有效，因为您保证 Arduino 串行读取缓冲区永远不会被 USB 数据包溢出。

无论如何，我不确定在“ok”末尾添加可用的串行缓冲区大小会使事情变得容易得多。如果您查看 stream.py Python 脚本，执行字符计数方案非常简单，并且如前所述，它非常坚如磐石。

我认为中间立场是在 grbl 中实现一个运行时命令，它只返回 Rx 缓冲区大小的编译时设置，以便 Python 脚本可以动态适应，而开发人员不必记住在两个地方更改该数字。

嗯，这是个好主意@csdexter. 我可以安装一个“$S”命令来打印所有与接口相关的编译时系统设置。启用 XON/XOFF 流控制、RX/TX 缓冲区大小、g 代码行大小、规划器缓冲区等。这将使接口更容易适应每个构建。

@chamnit：是的，我今天偶然发现并阅读了旧的 Xon/Xoff 讨论。只是为了澄清一点，我想指出一些关于此的事情。

首先，软件流控制并不是真正要在应用程序级别完成的事情——换句话说，终端客户端不应该与它有任何关系（除了提供它作为一个选项）——这样的延迟将是可怕的. 在过去的 DOS 时代，它可能会像这样工作 – BIOS 调用等等，但现在它肯定是在 win32 上的串行设备驱动程序中在低级别处理的，如果 Linux 会有所不同，我会感到惊讶；同样，终端与它无关，只是通过 IOCTL 调用启用它。PC 上实际 UART 芯片的第一次迭代（如 8250 和 16450）对它没有任何支持（因此它是在软件中处理的），后来最流行的芯片版本 16550 也没有。 – 然而，后来的型号 16650，包括在硬件级别上对 Xon-Xoff 的支持，这意味着它在收到 Xoff 时立即停止发送。显然，这对任何合作伙伴设备都非常有效，无论它有多么小的缓冲区。不幸的是，似乎很少有主板使用这个版本的硬件，或者我被告知。当然，所有这些只有在使用实际的板载 RS232 端口而不是 USB 仿真端口时才有意义。

232 FTDI 芯片从最早的版本开始所做的非常相似：虽然它们确实有自己的内置 Rx/Tx 缓冲区（BL/BM/BQ 版本上为 328 / 128 字节，RL 上为 256 / 128 字节，模型 Arduinos 使用）这会使延迟进一步复杂化，它们还具有上述对 Xon-Xoff 的硬件级支持，这意味着它们一旦看到 Xoff 就会立即停止向 Arduino 填充更多数据，这就是为什么它们在我们的案例中工作。还需要记住的是，在这种情况下，任何 PC 端软件缓冲区设置都无关紧要（除非可能会增加更多延迟），因为 Arduino 直接处理 FTDI 芯片及其缓冲区，而不是 PC 上的软件缓冲区。

无论如何，关于我的想法 – 不幸的是，它显然也行不通，对此感到抱歉。任何带有“ok”的缓冲区信息在它离开 Arduino TX 缓冲区并到达客户端时都会过时 – 这可能已根据先前的回复采取行动并同时开始发送内容，从而使稍后收到的迟到的数据无效“好的”。所以，不，再一次 – 对不起。并且非常清楚 – 我并不质疑客户端中的特定实现可以像现在这样完美地工作。当然可以。我坚持这一点的原因是它非常依赖于特定的实现，或者说直白点，仅在特定情况下才会出现的错误很容易出错（或稍微错误） – 特别是在保持特殊字符计数等复杂情况下。这就是这个主题甚至存在的原因 – Universal Sender 中的当前实现很有可能 99.5% 是正确的，除非它不是。这就是为什么我想要一个清晰明了的方案，它更容易做对，很难出错，不需要特殊情况。我的建议是针对这样的解决方案，除了……见上文。

不幸的是，我认为仅仅拥有关于缓冲区规格的可查询信息（虽然显然是一个积极的步骤）并不能解决根本问题，但我也不能声称有任何简单的解决方案。不过，这仍然是我希望看到解决的问题，并且由于我曾经考虑过在某些时候搞砸某种客户（希望也是通用的），只是利用我碰巧有一个事实基于 FTDI 的 grbl 对此没有多大帮助。哦，好吧，我想，一个人可以做梦（而且，哦，亲爱的，对不起所有这些废话）……

用词没有问题。:) 无论如何，关于 XON-XOFF 流控制的应用程序端，你是对的。机器或其终端程序响应速度不够快可能存在许多问题。而且，就我的调查而言，LUFA 也没有 XON/XOFF。可能是因为你说的问题。他们不想处理它。

无论如何，Universal Sender 似乎有一个可能的解决方案，它涉及短暂的延迟，但不确定该解决方案是否 100% 可靠。只知道这样更好。

也许，串行接口是一般的问题。i2c/twi 更加可控和即时，但计算机上似乎没有现成的接口，需要额外的硬件。或者，我们可以将串行波特率提高到 115200，看看我们如何使用简单的调用和响应方法。Alden Hart 今天告诉我，他们在更高波特率方面的经验似乎已经解决了这个问题，但是 TinyG 在 XMega 上运行，CPU 功率是两倍，规划器缓冲区更大。

我看到的当前字符计数方案的一个问题（在为 grbl 开发 GUI 时）是发送到 grbl 的所有命令都以“ok”回复。如果您只流式传输 gcode，这不是问题，但如果您开始混入“！”、“~”、“？” 和其他命令（$ ..）到这里，你也会得到这些命令的“ok”。然后，您必须非常小心地编写字符计数系统以跟踪 Arduino 上的内部缓冲区，以免错误地认为可用空间多于实际可用空间。我对此的解决方案是假设如果我在发送这些运行时命令之一后获得 OK，则该 OK 不是表示 RX 缓冲区中有更多可用空间的响应，而是运行时命令的重播。

顺便说一句，我没有看到该线程的第一篇文章中描述的任何问题。

“ok” 应该出现在每个 g 代码命令或 ‘$’ 命令之后。我这样做是因为这些命令都存在并在执行之前存储在串行缓冲区中。因此，响应应该告诉接口该命令何时从串行缓冲区中清除。运行时命令 ‘!’,’?’,’~’ 不应该响应任何 ‘ok’ 而不是状态 ‘[]’ 消息。如果 grbl 与此不一致，我将不得不立即修复它。

@VingTor: 奇怪，我还没有看到任何特殊字符的“ok”。您确定您不会以 ‘?\cr\lf’ 或类似的形式发送它们…？

我真的应该更详细地阅读 grbl 代码……你是粗略的权利。我使用相同的任务向 grbl 发送不同的命令，并且总是添加一个“\n”，不应该在这些运行时命令中添加粗略的（确认我的检查 serial.c）。看来我明天还要重写……

没问题！每当你发现它们时，请继续报告任何这些怪事。它有助于巩固代码及其背后的一些推理。

谢谢马库斯，到目前为止看起来不错，将进行更多测试

特里

2012 年 11 月 23 日星期五上午 8:00，Markus Schulz notifications@github.com写道：

你好白！

请试试这个，让我知道这是否也为你解决了这个问题。

转到 SerialCommunicator streamCommands 方法并
在 nextCommand 之后添加这个 25ms 尝试睡眠块…在我这样做之后我没有得到问题

• 也许某种多线程和java的竞争条件以及
  如何处理OK？

在我的文件第 313 行：

// Load the next command.
if (this.commandBuffer.hasNext()) {
this.commandBuffer.nextCommand();
try
{
Thread.sleep(25);
}
catch ( Exception e )
{
e.printStackTrace();
}
}

2012 年 11 月 20 日上午 1 点 26 分，whitetd 写道：

公共静态最终 int GRBL_RX_BUFFER_SIZE=60

仍然无法正常工作。

2012 年 11 月 19 日星期一晚上 9:57，Terry White whitetd@gmail.com写道：

找到它，看起来它正在工作，设置为 64 并测试

2012 年 11 月 19 日星期一晚上 9:46，Terry White whitetd@gmail.com
写道：

缓冲区设置在哪里？

2012 年 11 月 19 日星期一晚上 9:08，Sonny Jeon
notifications@github.com写道：

有趣的。感谢您查明原因。 过去，在尝试使 XON/XOFF 流控制正常工作时，我在 USB 到串行转换方面遇到了一些
问题。总之，USB 发送不同大小的数据包， 通常为 64 字节。它可能会发送一个巨大的初始数据包并 在进入流媒体之前截断 某些内容。只是一个理论。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/ /issues/141 #issuecomment-10543104。

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

—
直接回复此邮件或在 GitHub 上查看 https://github.com/ /issues/141 #issuecomment-10663435。