我在这里有点猜测，因为我没有直接使用 Marlin 的经验，而且我只是粗略地研究了代码。也就是说，基本的 Marlin 串行协议似乎是“发送一条线，等待‘ok’ACK”而没有大量缓冲。如果是这样，那么发送给 Marlin 的程序可能需要有很好的实时响应。JavaScript 并未针对实时进行优化，在 Pi 上运行它只会让事情变得更糟。
但我可能是错的…

我将尝试比较 octoprint 的逻辑与 cncjs 逻辑

Octoprint 主要是用 Python 编写的。我不确定 javascript 是否会实时变得更糟。我在 pi 零上运行 octoprint，gcode 没有速度问题（web ui 有点慢）。

除非 javascript 或 node.js 在 arm 上运行的方式有更糟糕的地方，否则我怀疑这就是问题所在。

我制作了CNCJS（左）与 OctoPrint（右）的比较视频。OctoPrint 更流畅（尽管我笔记本电脑上的 Repetier Host 更流畅！）这是在我的 Raspberry Pi2 上运行的。我今天有一个 Pi3B+，所以我可以再进行一次比较。

看起来 Marlin 支持提前缓冲一些动作（默认为 16）。我想知道 CNCJS 是否利用了这一点。也许SP_TYPE_SEND_RESPONSE在 CNCJS 中用于 Marlin 一次只发送一个命令并SP_TYPE_CHAR_COUNTING用于 Grbl 流前面一定数量的字符。@cheton这看起来合理吗？

OctoPrint历来也遇到过这个问题，而且他们没有灵丹妙药。似乎有很多挖掘和性能优化。我只是想确保 CNCJS 的基本流提前工作。

我还注意到一个关于 TinyG 规划器缓冲区的模糊问题。TinyG 还使用SP_TYPE_SEND_RESPONSE. 可能这些是相关的。

你好@johnboiles

你提到的是正确的。Grbl 和 Smoothie 控制器都使用字符计数协议，这将通过缓冲运动命令提供最佳性能。对于 TinyG/g2core 控制器，它不应该有明显的性能问题，因为它也利用了规划器缓冲区。

老实说，我很少有机会在运行 Marlin 控制器的连接机器上调整性能，如果有机会我想知道 Octoprint 如何实现他们的缓冲机制，那肯定有助于提高性能。

在进行更改以利用缓冲解决方案之前，您可以尝试注释掉this.queryPosition()和this.queryTemperature()，并检查它是否会影响性能。

https://github.com/cncjs/cncjs/blob/v1.9.18/src/app/controllers/Marlin/MarlinController.js#L720-L724

// M114: Get Current Position
this.queryPosition();

// M105: Report Temperatures
this.queryTemperature();

我试着了解一下 octoprint 是如何进行缓冲/发送的，但无法弄清楚提前发送命令或控制发送命令速率的逻辑在哪里。需要更多的研究。@cheton我们可以简单地使用 marlin 的字符计数流协议吗？

@cheton我会尝试删除this.queryPosition()并this.queryTemperature()查看它是否有所作为。OctoPrint 从不查询位置，但我认为它必须查询温度，因为它维护临时图表。

在 octoprint 的设置中有一个复选标记“支持固件自动报告温度，如果检测到”，Marlin 支持（如果配置）M155，它将自动广播温度：

http://marlinfw.org/docs/gcode/M155.html

看起来 Marlin 支持提前缓冲一些动作（默认为 16）。我想知道 CNCJS 是否利用了这一点。

也就是说，基本的 Marlin 串行协议似乎是“发送一条线，等待‘ok’ACK”而没有大量缓冲

我不记得我在哪里看到过这个，但我认为马林在它被存储在缓冲区中后立即以“ok”回应，而不是在它完成移动时。所以发送一个命令，等待“ok”然后发送下一个命令应该没问题，只要它完成得比机器移动的速度快。不过需要确认。

@jeffeb3谢谢你的想法！很高兴知道这M155可能比M105控制器感觉要发送它时更有效率。

我认为您对 Marlin 在存储后立即以“ok”响应的说法是正确的。我没有在 OctoPrint 中找到任何关于预缓冲行的特殊代码，也没有在OctoPrint/OctoPrint#450的讨论中找到任何关于它的提及，这对我来说表明利用缓冲移动不需要太多特殊处理。也许我们可以通过阅读马林密码来确定。

也许 CNCjs 会间歇性地停止足够长的时间以导致缓冲区欠载。垃圾收集可能导致这种情况，Pi 上运行的其他进程也可能导致这种情况。如果运行“top”，您可以查看是否有来自其他进程的干扰，以及正在使用多少内存。在我的设置中，Pi Zero 基本上只运行 cncjs——没有窗口系统或任何其他侵入性进程。
有人可能会问“为什么 OctoPrint 不会发生这种情况”。OctoPrint 的编写方式可能会减轻垃圾收集的压力，或使用较少的内存，或任何其他难以确定的因素。对我来说，CNCjs 代码看起来像是用“大机器”假设编写的，使用了可以想象到的每一个奇特的 JavaScript 功能。

@MitchBradley我还将尝试禁用我用来运行微型 Web 挂件的窗口系统，看看这是否有所作为。节点是单进程吧？我认为仍然应该有 3 个其他核心来运行这些其他东西。我还将在我的 Mac 上尝试 electron 应用程序以确保它消失（并排除代码错误）。

主要是为了我自己的理智，这里列出了我想做/尝试的事情：

1. 注释掉queryPosition和queryTemperature（@cheton的建议）
2. 在cncjstop中运行作业时查看
3. 尝试在 Pi3B+ 上运行
4. 尝试从我的 2.8GHz i7 四核 Mac 运行 Electron 应用程序
5. 在我的 Pi2B 上禁用窗口系统 + chromium + pendant 后尝试运行
6. 查看 Marlin 代码以确保它ok在将移动存储在缓冲区后返回（而不是在移动完成后返回）（@jeffeb3的想法）

如果有一个投注池，我想要 5。

哈哈。我们拭目以待！我完全可以看出 Node 的 v8 和 Chromium 的 v8 存在某种资源争用的可能性。

以下是目前的结果：

5. @MitchBradley这次你输了！杀死窗口系统（Xorg + openbox + chromium）没有任何区别
2. Node 在运行此作业时几乎不使用半个内核。我看到的最高 CPU 使用率是 50%s。

1.我们可能早该预见到这一点，但是@cheton是正确的。删除这两行使 CNCJS 的性能与 OctoPrint 相当?大多数 CNC 用户可能不需要温度报告。不幸的是，在 Marlin 中似乎没有位置自动报告（认为可以添加）。@cheton下一步是什么？我们是删除这些线条还是将它们放在背景或其他东西后面？
6.我认为 1 的成功证实了 Marlin 能够在没有任何特殊手持的情况下预先缓冲命令。

我仍然想测试 3 和 4。

我测试了 3（在 Pi3B+ 上运行），与 Pi2 没有明显区别。我将并排比较视频，看看是否有任何细微之处。

我测试了 4（2.8GHz i7 四核 Mac 上的 Electron 应用程序）。我不小心将控制器设置留在了 Grbl 上，Gcode 在 Grbl 模式下运行得很好。我将控制器设置切换为 Marlin 并遇到了同样的慢速 GCode 处理问题。不过，我还没有尝试过使用上述修复程序的 Electron 应用程序。我有兴趣将固定的 Marlin 控制器与 Grbl 控制器进行比较，看看它们的性能是否具有可比性。

1. 我们可能应该预见到这一点，但是@cheton是正确的。删除这两行使 CNCJS 的性能与 OctoPrint 相当?大多数 CNC 用户可能不需要温度报告。不幸的是，在 Marlin 中似乎没有位置自动报告（认为可以添加）。@cheton下一步是什么？我们是删除这些线条还是将它们放在背景或其他东西后面？

@johnboiles

如果您想尝试使用字符计数协议，请按以下方式更改发件人代码：

// Sender
this.sender = new Sender(SP_TYPE_CHAR_COUNTING, {
    // Take your own risk to set the buffer size.
    // I don't know actual implementation details in Marlin
    bufferSize: 128,
    dataFilter: (line, context) => { }
});

对于短期解决方案，我建议我们将它们放在一个设置后面，以便用户可以决定打开/关闭它们。根据您的测试，哪个因素会显着影响性能？queryPosition或者queryTemperature

@whimsycwd
与 OctoPrint 比较时，您是否遇到过类似的性能问题？似乎去除温度查询和位置查询会得到更好的结果。

将位置查询和温度查询的定时器间隔增加到一个合理的值可能会有所帮助。