注释
.jpg "提早掉线。 #141"){kind=avatar}
|
cncdriver 只是说错误并停止发送 gcode。将不得不记录 2012 年 11 月 19 日星期一下午 6:23，Sonny Jeon notifications@github.com写道：
|
.jpg "提早掉线。 #141"){kind=avatar}
|
嗯。。好。我个人从来没有遇到过跳线问题，但我 在 2012 年 11 月 19 日星期一晚上 7:33，whitetd notifications@github.com写道：
|
|
随机行，但仅在前 20 行之内。该图显示 2012 年 11 月 19 日星期一下午 6:39，Sonny Jeon notifications@github.com写道：
|
.png "提早掉线。 #141"){kind=avatar}
|
我确定这不是 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写道：
|
|
找到了，看起来它正在工作，设置为 64 并正在测试 在 2012 年 11 月 19 日星期一晚上 9:46，Terry White whitetd@gmail.com写道：
|
|
公共静态最终 int GRBL_RX_BUFFER_SIZE= 60 仍然无法正常工作。 在 2012 年 11 月 19 日星期一晚上 9:57，Terry White whitetd@gmail.com写道：
|
.png "提早掉线。 #141"){kind=avatar}
|
嗯…我不确定如何尽可能小心翼翼地表达这一点，特别是考虑到我对大多数 PC 编程语言，尤其是 Java 的理解大致为零，但是…是 Winder 的 Universal Sender有机会尝试镜像 grbl 的内部缓冲区来弄清楚它什么时候满了，什么时候没有（为什么它甚至需要那个设置）？因为如果那是它的作用，请原谅，我需要长时间地用头撞在合适的墙上。 |
|
我们知道 Grbl 示例文件夹中的 python 脚本可以工作……或者至少它从未为我跳过一行 gcode。通常它总是对我失败的同一行并且在 Universal Gcode Sender 中播放缓冲区大小会更改此行号。我有一个设置是我的文件刚刚工作，那是 60，我想这是一个巧合，只为这个文件修复了它。据我所知，python 脚本和 Jave 代码都在尝试做同样的事情——跟踪内部缓冲区，只有在有空间时才发送。我想如果你发送多行到快速 Grbl 无法跟踪并跳过部分，如果你一次只发送一行并等待它会慢很多。 |
|
好吧，事情是这样的（抱歉，没能早点回复，没时间测试东西）——恕我直言，这种功能重复通常是一个坏主意，而且是一个非常非常脆弱的解决方案——如果这两种算法不是如果工作方式不完全相同，它们可能会失去同步并发生故障（这通常只是软件更改的时间问题）；需要通过参数匹配缓冲区大小 – 正如已经看到的那样 – 这可能会不匹配等。简而言之，这不是一种健壮可靠的做事方式，我非常喜欢快速移动时的那些品质涉及金属，尤其是通过正确阅读此线程见证了后果。 但问题是——为什么我们总是如此急切地尝试将 grbl 的缓冲区填满，据我所知，只需在收到前一个命令的“确定”后一次发送一个命令就可以完成完全相同的事情： grbl 不会等待命令实际完成才“确定”-s 它，它会立即回复！我可以轻松地输入 3-4 个命令（在一个接一个地得到所有命令的“ok”回复之后），而第一个命令仍在执行！因此，“缓冲区不足”绝对不是我们应该为流式传输的需要而责备的事情。 从理论上讲，也许如果第一个命令非常短（可能只有几步之遥），可以想象它会在下一个命令到达之前完成，但是 a) 这实际上不是错误，它只是次优 b) 首先移动往往是慢跑到入口点或缓慢的 Z 轴进给到材料上 – 几乎没有东西会在回复返回和发送下一个命令之前完成执行（基本上是毫秒）。在那之后，grbl 将连续缓冲尽可能多的移动，因为它可以在内部排队，即使是简单的命令-回复-命令-回复操作，也无需观察任何缓冲区大小。那我们为什么不这样做呢？ 至少，从这里看起来是这样。请现实检查。我错过了什么吗？ |
|
根据我使用 Grbl 的经验，大多数人不会对简单的调用和“ok”响应协议有任何问题，但在某些情况下这确实会成为问题。 例如，如果您使用激光切割机以非常高的进给率绕着一条曲线移动，则该曲线会被分成非常小的线段。这有两个问题：(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:128”），或者可能通过以稍微不同的方式发送命令（例如，以特殊字符为前缀）来提示，其中手动输入的命令和旧客户端甚至看不到那额外的数据。 |
|
你好 whitetd！ 请试试这个，让我知道这是否也适合您。 转到 SerialCommunicator streamCommands methode 并
在我的文件第 313 行中： 在 2012/11/20 01:26, whitetd 写道:
|
|
@blinkenlight: 如果我们有流量控制，这将解决所有这些问题。我确实安装了 XON/XOFF 软件流控制作为编译时选项，供在其板上（Duemilanove 或之前的 Seeeduino）或使用某种 FTDI 电缆的用户使用 FTDI USB 串行芯片。我已经在 Duemilanove 上试过了，效果非常好。您几乎可以使用任何串行终端程序并上传文件。这基本上和你问的是一样的。它在缓冲区快满时发送一个标志，在缓冲区快空时发送另一个标志以重新开始流式传输。 当我发现用 UNO（没有 FTDI 芯片）将我的头撞到墙上时，这个问题的主要问题是 USB 协议做了一些奇怪的事情。它来回发送难以在流式基础上进行管理的数据包。因此，数据流可以是异步的。这就是我们必须执行此调用和响应协议的原因。它消除了这个问题。（我认为 FTDI 芯片有某种内部缓冲区来处理这些事情，然后再将其传递给 328 芯片。）字符计数也有效，因为您保证 Arduino 串行读取缓冲区永远不会被 USB 数据包溢出。 无论如何，我不确定在“确定”的末尾添加可用的串行缓冲区大小会使事情变得容易得多。如果您查看 stream.py Python 脚本，您会发现执行字符计数方案非常简单，而且如前所述，它非常可靠。 |
.png "提早掉线。 #141"){kind=avatar}
|
我认为中间立场是在 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 缓冲区并到达客户端时都会过时——这可能已经根据先前的回复采取行动并同时开始发送内容，从而使后来接收到的迟到数据无效“好的”。所以，不，再一次 – 抱歉。并且要非常清楚——我不是在质疑客户端中的特定实现是否可以像现在这样完美地工作。当然可以。我坚持这一点的原因是它非常依赖于特定的实现，或者直截了当地说，只在特定情况下出现的错误很容易出错（或曾经有过轻微的错误）——尤其是在保持特殊字符计数等复杂性的情况下。这就是这个主题存在的原因——通用发件人中的当前实现很可能 99.5% 是正确的，除非它不是。这就是为什么我想要一个清晰明了的方案，它更容易正确，很难出错，而且不需要特殊情况。我的建议旨在提供这样的解决方案，除了……见上文。 Unfortunately, I think that merely having queryable information about the buffer specs (while clearly being a positive step) does not solve the underlying issue, but I can’t claim to have any easy solutions either. It’s still a thing I’d like to see solved though, and since I’ve entertained the idea of botching up some sort of client (hopefully also universal) at some point, simply taking advantage of the fact that I do happen to have an FTDI-based grbl wouldn’t help much with this. Oh well, one can dream, I suppose (and, oh dear, sorry for all that verbiage)… |
|
No problem on the verbage. Anyhow, it seems that there is a possible solution to the Universal Sender, which involves a short delay, but not sure if the solution is 100% reliable. Just know it’s better. Perhaps, the serial interface is the problem in general. i2c/twi is much more controllable and immediate, but there doesn’t seem to be a readily available interface on computers and would require additional hardware. Or, we can just jack up the serial baud rates to 115200 and see how we do with the simple call and response method. Alden Hart told me today, their experiences with higher baud rates seemed to have fixed this issue, but the TinyG runs on an XMega with twice the CPU power and larger planner buffer. |
.png "提早掉线。 #141"){kind=avatar}
将其移至新问题：
@whitetd
还有其他人在一开始就掉线有问题
吗？
我一直在重复这条线，它起作用了，但有点痛苦。使用
通用 gcode 发送器，与其他程序一起使用时会出错并停止。
特里
你能详细说明它给出了什么样的错误吗？是在同一条线上吗？您发送的 g 代码块是什么？它适用于流媒体脚本吗？