Universal-G-Code-Sender becomes unresponsive after ~250,000 lines#168
注释
如果你想要大量的 gcode 文件,你需要增加分配给 JVM 的内存量。您可以尝试修改启动脚本来执行此操作。 我相信 raspberry pi 在其默认 java 配置中没有硬件启用浮点,这是性能问题的很大一部分。 |
为什么?如果那样的话,您不需要缓冲多于几行。文件系统几乎与 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/ |
I like the pre-processor idea. |
将在#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 上无法使用,因为它会大量使用资源——它会立即减慢机器速度。