注释
.png "树莓派 3 CPU 使用率 #747"){kind=avatar}
所有者
|
有很多关于处理 gcode 和将数据流式传输到 GRBL 的事情无法真正并行化。 Gcode 是一个大状态机，所以你不能在不先处理它之前的命令的情况下处理命令。由于 UGS 在流式传输之前预处理 gcode，这对于大型程序可能需要一段时间（尤其是在像 RPi 这样的较慢的机器上）。 同样，需要按顺序处理 GRBL 响应。虽然 UGS 事件系统的某些部分可以改进，但“命令完成”消息可能会发送到 20 个不同的 GUI 元素，因此在线程池中处理它们可能会很好地提高性能。我不确定为什么这会与 CPU 挂钩，与初始处理相比，流媒体应该是非常轻量级的。 |
.jpg "树莓派 3 CPU 使用率 #747"){kind=avatar}
作者
|
@winder这可能是 Raspberry Pi 的特定问题。也许与 JRE 有关？ 我在运行 64 位平台的 Windows 10 中打开了一个 80MB 的文件：
它在处理过程中使用所有四个核心。我看到 CPU 使用率在 50% 到 75% 之间，这是所有 4 个内核的总和。它最终产生了内存不足错误。 |
.png "树莓派 3 CPU 使用率 #747"){kind=avatar}
合作者
|
无法重现问题，关闭问题 |
我注意到在 Raspberry Pi 3 上使用 UGS 时，CPU 利用率似乎上限为 25%。
Pi 3 是四核。看起来 UGS 只使用 1 个 CPU 核心。当加载一个 11MB 的 Gcode 文件（600K+ 行）时，它将 CPU 固定在 1 个核心上，只有 1 个核心，加载文件需要几分钟（这是半可理解的）但我一直在帮助，但想知道单核是否使用是源头或至少是障碍。即使在雕刻过程中，它也在最大化 Rpi 的单个核心，感觉就像它受到限制并且可以更好地运行。
我在 Classic 和 Platform 上都看到过这种行为。
我打算用一个非常非常大的文件在我的 Windows 笔记本电脑上进行测试，看看我是否看到相同的行为。我尝试使用相同的 11MB 文件，但笔记本电脑处理能力的增强并没有真正让它退缩。
我曾尝试在网上搜索有关 Java 运行时设置的提示和技巧，但基本上一无所获。
我不知道这是否一定是错误、实际问题，或者只是在 Raspberry Pi 3 上运行的人为因素。