注释
.png "Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168"){kind=avatar}
|
如果你想要大量的 gcode 文件，你需要增加分配给 JVM 的内存量。您可以尝试修改启动脚本来执行此操作。 我相信 raspberry pi 在其默认 java 配置中没有硬件启用浮点，这是性能问题的很大一部分。 |
.png "Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168"){kind=avatar}
|
为什么？如果那样的话，您不需要缓冲多于几行。文件系统几乎与 Pi 上的 考虑到 gcode 发送器所做的事情的简单性——文件和 在 2014 年 6 月 9 日星期一上午 10:58，Will Winder notifications@github.com
Andrew L. Sandoval [image: qrcode] http://mormon.org/me/72HW/ |
|
UGS preprocesses every line of gcode to do things like truncate extra decimal precision and remove whitespaces. This process could be streamed, but I decided to process them all at once so that errors could be reported. Also the commands are displayed in a table, and the visualizer stores a lot of vertex data which is based on the length of the gcode file. |
|
Understood, and that is a great thing to do, but it should be a FWIW, the Universal GCode Sender has worked fine for many things, and to a On Mon, Jun 9, 2014 at 11:30 AM, Will Winder notifications@github.com
Andrew L. Sandoval [image: qrcode] http://mormon.org/me/72HW/ |
.jpg "Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168"){kind=avatar}
|
I like the pre-processor idea. |
winder added planned-enhancement future-enhancement and removed planned-enhancement labels 2015 年 2 月 25 日 winder changed the title .png "Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168"){kind=avatar}
|
将在#302中解决 |
在性能良好的 Windows 8.1 PC 上使用通用 GCode 发送器时，一切运行良好，直到发送了大约 250,000 行 gcode。在此之后，程序变得有点反应迟钝（点击需要很长时间才能处理）并且 GRBL 的进给速度太慢以至于最终产品最终被严重损坏（特别是在使用激光时，因为 GRBL 等待时移动太慢了对于一个新命令，它会深深地刻录当前位置。）
我已经测试了几次，看到这种情况在大约 253,000 行之后一直发生。PicLaser Lite 将很容易地生成一个文件，其行数是小图像的两倍。
通过 Grbl Controller 3.0（在 Windows 上）运行相同的 GCode 工作正常。
看起来这可能是资源泄漏——这是因为 Java（蹩脚的）垃圾收集可能不在开发人员的直接控制范围内。
附带说明一下，通用 GCode 发送器在 Raspberry Pi 上无法使用，因为它会大量使用资源——它会立即减慢机器速度。