我还注意到同样的问题，即在我的大部分（如果不是全部）雕刻上，刨床缓冲区始终为零。

在运行 GRBL 1.1 的 CNC.js 中，如果规划器缓冲区为 0，则表示它已满，这是一件好事。在小文件上，我在规划器缓冲区上得到 0，一切运行顺利，但在大文件上，缓冲区在 14 和 15 之间跳跃，这意味着 GRBL 数据不足并导致它断断续续。

我已经在我的树莓派上使用 python 脚本“stream.py”测试了相同的 357,000 行文件，并且在整个时间内保持 CPU 使用率低于 5% 没有问题。

我刚刚更新到V1.8.8，仍然有同样的问题。

抱歉来晚了，这两周我一直很忙。下周我应该有时间调查 RPi2 上的大型 G 代码文件的性能问题。一旦我找到一些线索，我会及时通知你。

你好@mayhem2408,

我可以知道您的完整 Grbl 设置（$$），尤其是以下内容：

$100  X-axis steps per millimeter
$101  Y-axis steps per millimeter
$102  Z-axis steps per millimeter
$110  X-axis maximum rate, mm/min
$111  Y-axis maximum rate, mm/min
$112  Z-axis maximum rate, mm/min
$120  X-axis acceleration, mm/sec^2
$121  Y-axis acceleration, mm/sec^2
$122  Z-axis acceleration, mm/sec^2

我尝试了“ Zac – RIP – Y0-Y3.9.nc ”和“ Zac – RIP – Full.nc ”文件，但在状态报告中两者都无法达到 2000 毫米/分钟的进给率。规划器缓冲区也没有得到充分利用。

我忘记通过将$32 Grbl 设置值更改为 1 来启用激光模式。设置后$32=1，它可以达到所需的进给率。

几次尝试后，我遇到了同样的问题，即在 RPi2 上加载大文件（例如 Zac-RIP-Full.nc）时，规划器缓冲区和接收缓冲区都没有得到充分利用，但它从未发生在像 Windows 桌面或这样强大的机器上Mac 图书航空。

需要调查在 RPi2 上处理大型阵列时 CPU 功率可能会影响什么。

Zac-RIP-Full.nc（在 RPi2 上）

Zac-RIP-Y0-Y3.9.nc（在 RPi2 上）

https://gamealchemist.wordpress.com/2013/05/01/lets-get-those-javascript-arrays-to-work-fast/
推送和弹出不是恒定时间操作

Push 和 pop 不是恒定时间操作，而是花费与数组长度 ( O(n) ) 和内存碎片成比例的时间。

它可能与remain和sent数组有关，该数组包含完整 G 代码行的两个副本：

https://github.com/cheton/cnc/blob/master/src/app/lib/gcode-sender.js#L13

class GCodeSender extends events.EventEmitter {
    name = '';
    gcode = '';
    remain = [];
    sent = [];

如果这是根本原因，应该很容易解决性能问题。

我通过在解析 G 代码命令时删除不必要的正则表达式来减少文件加载时间，从而提高了性能。加载速度将比当前版本快 10 倍。

$32=1；激光模式
$100=80；X轴每毫米步数
$101=80；Y轴每毫米步数
$102=80；Z 轴每毫米步数（未在我的钻机上使用）
$110=10000；X轴最大速率，mm/min
$111=10000；Y轴最大速率，mm/min
$112=500；Z 轴最大速率，mm/min（未使用）
$120=1500；X轴加速度，mm/sec^2
$121=1500；Y轴加速度，mm/sec^2
$122=100；Z 轴加速度，mm/sec^2（未使用）

我所有的雕刻都是使用新的 M4 模式而不是 M3 完成的。但这不会影响流。

我刚刚尝试了 V1.8.12，但在处理较大文件时仍然存在速度问题。

性能增强的代码改动仍在本地开发中，将在1.8.13或1.9.0发布。

对于在 node.js 应用程序上进行性能调试的一种方法，这可能值得一读。

• http://techblog.netflix.com/2014/11/nodejs-in-flames.html
• https://www.dynatrace.com/blog/how-to-track-down-cpu-issues-in-node-js/

@cheton 我读过 shift() 方法在大型数组上可能非常慢。我打算看一下代码，看看是否可以使用单个数组和一个索引变量来代替具有移位和推送的两个数组，这意味着大型数组一旦加载就不必更改。我会等待你的下一个版本，看看它是如何进行的。

@cheton我还读到如果你 reverse() 数组然后 pop() 离开数组的末尾，它会更快，但我还没有测试这个理论。

正如您所说，我使用单个数组 ( this.lines) 和索引变量 ( this.sent) 重构了字符计数流协议的当前实现。时间复杂度为 O(1)，在处理大型数组时应该会快得多。

[STREAMING_PROTOCOL_CHAR_COUNTING]: () => {
    if (this.transmitDataQueue.length > 0) {
        const dataLength = this.transmitDataQueue.shift();
        this.transmitDataLength -= dataLength;
    }

    while (this.sent < this.total) {
        const line = this.lines[this.sent];
        this.transmitLine = this.transmitLine || stripLine(line);

        if (this.transmitLine.length + this.transmitDataLength >= this.transmitBufferSize) {
            break;
        }

        const gcode = this.transmitLine;
        this.transmitLine = ''; // clear transmitLine

        this.sent++;
        this.emit('change');

        if (gcode.length > 0) {
            this.transmitDataLength += gcode.length;
            this.transmitDataQueue.push(gcode.length);
            this.emit('gcode', gcode);
        } else {
            this.ack(); // Ack for empty lines
        }

        // Continue to the next line if empty
    }
}

还对gcode-parser、gcode-interpreter和gcode- toolpath进行了显着的性能改进。它将加快加载时间至少比早期版本快 5 倍。

我的基准测试表明，在 Mac Book Air ’12 上将 10MB 的 gcode 文件渲染到 3D 视图中的时间将从 40 秒减少到 5 秒。

@cheton我已经从大师和WOW那里下载并手动安装了1.8.13。有什么不同。Raspberry Pi 与时俱进，并有空闲空间。CPU 使用率现在仅在 20-30% 之间，并且 Planner 和 Serial 缓冲区仍处于满状态。
V1.8.12 上的完整文件需要 2h:43m 才能完成。
V1.8.13 上的完整文件耗时 43 分钟，这与 stream.py python 脚本相同。

加载和渲染时间的改进是巨大的。
V1.8.12，Load 耗时 1m:33s，Render 耗时 2m:00s，总耗时 3m:33s。
V1.8.13。加载耗时 0 分 16 秒，渲染速度很快。总计 0 米：16 秒。
那快了 13 倍多。

做得好。很棒的工作。

@cheton我虽然我会用我的一些较大的文件来锻炼它。下一个是 650,000 行和 12Mb。它的加载和渲染时间为 33 秒，流式传输没有性能影响，将 Raspberry Pi CPU 保持在 20-30%，缓冲区已满。
所以我虽然让真正压力测试这个东西。1,885,791 行 gcode 和 35Mb。
这次 Google Chrome 说 Aw… Google chrome 内存不足。
所以我在 19.1Mb 下尝试了 998,996 行。它已加载并且 Raspberry Pi 流式传输正常，但 Google Chrome 一直没有响应。我猜这是 Chrome 的限制，您对此无能为力。

您可以尝试关闭G 代码小部件吗？此小部件在加载大型 G 代码文件时也可能会消耗大量内存。

更好的解决方案是使用所谓的延迟加载机制而不是一次处理所有行，这将节省浏览器中的大量内存。

已在 1.8.13 中修复。

对于大文件支持（即 >20MB），我将创建另一个问题以供将来增强。