您的理论是正确的，专业机器就是这样工作的，但是我们使用的固件不支持这种模式。

这是#99大爆炸中涉及的主要思想之一。该线程的一些要点：GRBL 可以处理比仅使用 gcode 的其他像素率高得多的像素率；从它的角度来看，协议更改是不必要的。关于 Smoothie 的真正瓶颈在哪里似乎存在分歧；它可能有帮助，也可能没有帮助，这取决于谁是对的。无论如何，没有人挺身而出完成已经在 smoothieware 中开始的工作，我们也不愿意最终支持它，因为它最终将只是 Smoothie。GRBL 不需要它。TinyG，如果它沿着这条路走下去，将使用一种完全不同的基于 json 的数据格式。

我们知道 GRBL 和 Tiny G 目前的粗略速度是多少毫米/秒吗？

再次阅读最后一个线程，我会说问题来自加速生成

我们比 GRBL 做了更多的处理，所以我对 grbl 在这方面可能更快并不感到惊讶。由于我们添加了新的运动控制，每刻加速，因此对于收到的每个 gcode，计算都更加密集，因为我们需要完全预先计算步进时间数据，以便我们可以获得 100,000 步/秒的最大速率。

如果我回想一下我们使用 laserweb original 和 laserweb2 的第一个激光切割机原型，我们的光栅化速度比今天快。这也是在新的运动控制系统之前。

刚刚读到 tiny G，他们似乎在运动控制方面做了类似的事情？

如果 Tiny G 目前以与 smoothie 相似的速度光栅化，那么问题在于我们实际上发送了 0.1mm 长度的矢量路径，而控制器无法处理它。

我会尝试刷新旧版本的 smoothie ware，看看它是否比当前版本更快。

以下是两个主要的速度因素：

• 步进中断/s
• 块/秒

你在一个上走得越高，你就必须在另一个上走得越低，否则你会口吃。mm/s 和像素分辨率是固件性能的间接衡量标准，这很不幸，因为这些才是用户真正关心的。

grbl-328: 步进中断/s 是可变的；旋转最快的电机的每一步都有 2 或 3 次中断（1 次长，其他短）。2 或 3 因数取决于配置。

grbl-lpc：步进中断/秒是可变的；旋转最快的电机的每一步都有 1 次中断。grbl-lpc 的最大步进率为 200 kHz。

smoothie：我不知道步进中断率是固定的（比如 LinuxCNC）还是可变的（比如 grbl）。smoothie 的最大步进率为 100 kHz。

Tiny G：上次我听说他们还在研究激光支持。我不知道他们有没有。

对于通过 USB 使用普通 gcode 的激光光栅，grbl-lpc 目前保持着 79,000 步/秒，1666 块/秒的记录：https: //plus.google.com/101442607030198502072/posts/G9q5ois38RF

https://www.youtube.com/watch?v=TopGs-yLI_E差不多一年前！当您建造激光切割机并玩得开心时，时间过得真快；）

但是看看开始和 14 秒，这两个光栅比我们现在可以做的要快得多。
因此，这应该是 5 月/6 月左右的固件，在 laserweb 2 或 windows 上使用 pi 3 驱动，USB 不确定现在记不起来了。
我明天会用相同的 g 代码和不同的固件制作一些电影，我也会加载一个 pi，LW4 可以在 pi 上工作吗？如果它的驱动程序在操作系统上，那么我们应该看到改进吗？
@arthurwolf运动控制器改什么版本？

@FabCreator运动控制在几个月内发生了变化，最初进行了一次重大重构，但此后随着它的进一步工作，发生了许多其他变化。
对这些问题有很多猜测，他们很困惑，因为人们似乎一开始倾向于认为他们已经找到了罪魁祸首，并坚持下去，然后很难看到一些新的证据出现在那之后。

我们在与我相关的 Smoothie 问题中所做的是采取一种非常科学的、基于证据的方法，尝试一次只仔细测试一件事（非常重要），以慢慢消除可能的原因，直到我们找到真相。

可以想象，在您的情况下，您从未遇到过驱动程序问题，因此您所看到的速度差异可能与其他一些因素有关。然而，看到我们为驱动程序/主机问题找到的证据有多强大，我真的认为它应该是您搜索中的第一个嫌疑人。如果你能排除它的原因，那就太好了，然后你就会知道更多，并且可以对付下一个嫌疑人。

要确定您是否有与主机驱动程序相关的问题，请尽可能严格地执行以下实验： 

• 在特定操作系统上进行切割
• 然后使用完全相同的机器、计算机、gcode、主机程序、固件等进行切割，但使用另一个操作系统（只更改操作系统，没有其他更改，如果您看到差异，可以确定这是罪魁祸首）
  如果您无法在同一台计算机上运行两个操作系统，您可以尝试使用不同的计算机，但是无论结果如何，您的实验都不太好并且您还没有真正查明问题所在。

要确定您的问题是否是宿主程序（Gcode 发送方）的问题，请执行以下操作：

• 使用您常用的主机程序进行剪辑
• 然后使用完全相同的机器、计算机、gcode、操作系统等进行剪辑，但使用 Jim 的脚本发送 Gcode。Jim 的脚本及其说明可在Smoothie problem with streaming raster gcode over USB  Smoothieware/Smoothieware#1096（评论） 再次强调，请尝试尽可能严格地进行实验，仅更改 gcode 发送方，而不更改其他任何内容。

对于驱动程序比较：与 Smoothie 一样，grbl-lpc 将自己呈现为 USB CDC 设备，但与 Smoothie 不同的是，它不是 USB MSD。

@arthurwolf我有另一个测试给你：

• 使用您常用的主机程序和板上的 smoothieware 进行剪辑
• 然后使用完全相同的机器、计算机、gcode、操作系统等进行切割，但在板上使用 grbl-lpc

这将显示 smoothieware 的性能是否优于 grbl-lpc 的证据。

@cprezzi甚至不需要做这样的测试，很明显 grbl 效率更高（它没有 Smoothie 的所有奇特功能和模块化计算），它会比 Smoothie 更快。
但这不是重点。

众所周知，Smoothie 在驱动程序和 gcode 发送器的正确组合下，速度足以正确地进行光栅雕刻。grbl-lpc 可以做得更快的事实不是这里的主题。

主题是，对于某些用户，Smoothie 不能充分工作，而对于其他用户，它可以，并且这种差异已被指出为驱动程​​序和 gcode 发送方法的差异。

这不是关于“雕刻效果好”和“雕刻效果更好”之间的区别的讨论，而是关于雕刻效果不佳而无法实用的用户，我们的研究清楚地表明了造成这种情况的原因.

@arthurwolf速度限制@FabCreator说的是不依赖于他的机器，我们都可以重现那个限制。

你声称瓶颈是操作系统驱动程序和主机软件，但如果 grbl-lpc 在相同的 pc、操作系统、驱动程序和软件上更快，那么瓶颈一定是 smoothieware。

我不是说这是事实，但我会对此进行测试。

@cprezzi也许司机@arthurwolf参考的不是主机驱动程序，而是复合 USB 的 LPC 实现。

@cprezzi这取决于@DarklyLabs 的操作系统，并且通过仔细的实验​​证明了这一点。
另外，您说这不取决于机器/操作系统/驱动程序@FabCreator但我看不到在哪里进行了实验证明。

关于你声称 Smoothie 是瓶颈因为它使用 grbl-lpc 更快，你陷入了不断破坏这些对话的同一个陷阱：忽略多个因素可能导致问题的事实，并试图找到一个单一的问题.
让我再说一遍：是的，grlb-lpc 会比 Smoothie 快。这并不意味着您发现了问题，正如我们之前所说，使用正确的驱动程序/发送系统多次证明 Smoothie 足够快。不如 grbl-lpc 快，但这不是这里的抱怨。这个话题不是关于谁更快，而是关于用户甚至无法以任何实际速度进行雕刻。

到目前为止，唯一可证明的原因已被证明（经过大量仔细的实验​​/推论）与 gcode 发送方法和驱动程序有关。

你需要设身处地为@FabCreator，他们不在乎谁能打破雕刻速度的世界纪录，他们在乎的是眼下他们根本无法雕刻。这已经针对我一直提到的问题进行了精确定位，一旦这个问题不是问题，谁更快并不重要。

可悲的是，除了 pi 之外，我没有双启动设备或其他操作系统，

@arthurwolf如果它是一个驱动程序问题那么它应该是可以修复的然后我们的速度类似于 GRBL？
我在 smoothieware#1096 中看到最终速度只有 80-100mm/s？

80-100mm/s 远非“雕刻精美”。也许对于激光二极管机器但对于 CO2 激光器，我们的目标是 500-1000mm/s

如果目前光栅雕刻的最佳情况是最大 100mm/s，那么修复驱动程序并不是真正的解决方案，我们应该专注于一个完全不同的高速光栅解决方案。

@FabCreator一旦所有其他问题都得到纠正，grbl-lpc 可能会更快，它的开销更少。但是有一个与驱动程序和 gcode 发送方法相关的已确定瓶颈，无论发生什么都
需要修复，即使我们决定采用更紧凑的数据发送方法，它仍然是一个问题。

我很欣赏 GRBL 和 smoothie 工作方式的不同，从配置文件到加速配置文件调制等等，它很棒。为什么我们的机器里有冰沙板:)

但是，虽然我们不希望超过 trotec 雕刻速度，但能够像 DSP 控制器一样快速雕刻是必不可少的。

驱动程序可能是一个问题，需要以任何一种方式修复，但即使它以最佳方式工作，光栅化仍远未达到合理的速度。

@FabCreator我们同意这一点，即使我们解决了驱动器/gcode 发送瓶颈（我认为应该首先发生），我们仍然希望提高速度。
期望像 Trotec 一样的速度实际上并不是那么不合理，并且有一些方法可以实现，但它需要使用 Gcode 之外的其他东西进行传输，并使用当前 Gcode 解释器的其他东西来生成步骤。
我们很清楚完成这项工作需要做些什么，但目前还没有志愿者准备好做这项工作。

@arthurwolf我没有说其他操作系统的性能不快，但你真的想说你的客户改变操作系统以获得更快的速度吗？那不是一个选择。

请仔细阅读。我并没有声称 grbl-lpc 更快，我只是说如果是这样的话……

@cprezzi我不想告诉任何人更改操作系统，但为了继续前进，如果操作系统驱动程序是问题的一部分，我们需要承认这一点（例如在文档中以便用户意识到该问题。更改操作系统是一个选项一些用户，如果他们不知道它可以帮助他们就不会这样做）并考虑我们可以做些什么来解决它，如果有的话。

此外，不仅仅是操作系统驱动程序，实验表明它还与 Gcode 的发送方式有关，例如，在完全相同的设置上，@DarklyLabs 在将 laserweb 的 gcode 发送器与 Jim 编写的脚本进行比较时发现雕刻速度发生了巨大变化. 这是一个非常重要的数据点，不容忽视，这表明如果 laserweb 开始使用这种新方法发送 gcode，用户体验可能会得到显着改善。
这不仅是实验所显示的东西，也是完全理解和解释过程的东西。如：我们知道有改进的余地，我们知道如何改进。

关于你声称 grbl-lpc 更快，我不在乎你是否这样做：这无关紧要，我自己说这很可能（假设所有其他因素都被删除），所以这里没有什么可反对的。

@arthurwolf你真让我生气。
Jim 的脚本不是智能新方法，它只是一个简单的“将整个文件推送给驱动程序并忘记其余部分”！没有“实时”反馈或命令，什么都没有！那只是将所有可能减慢过程的因素都排除在外，这与您的“正确测试方法”相去甚远。

你只是想把责任归咎于你以外的一切！这是非常不专业的…

如果你不想让我们不高兴，就不要像老师那样和我们说话了！我经常解释为什么你的数据与真正的解决方案无关，但你似乎不明白。所以我已经不在乎了……