开源改变世界!!

Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168

推推 grbl 1年前 (2023-01-26) 67次浏览
关闭
alsliahona 打开了这个问题 2014 年 6 月 9 日 · 6条评论
 Closed

Universal-G-Code-Sender becomes unresponsive after ~250,000 lines#168

alsliahona opened this issue on Jun 9, 2014 · 6 comments

注释

Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168

在性能良好的 Windows 8.1 PC 上使用通用 GCode 发送器时,一切运行良好,直到发送了大约 250,000 行 gcode。在此之后,程序变得有点反应迟钝(点击需要很长时间才能处理)并且 GRBL 的进给速度太慢以至于最终产品最终被严重损坏(特别是在使用激光时,因为 GRBL 等待时移动太慢了对于一个新命令,它会深深地刻录当前位置。)

我已经测试了几次,看到这种情况在大约 253,000 行之后一直发生。PicLaser Lite 将很容易地生成一个文件,其行数是小图像的两倍。

通过 Grbl Controller 3.0(在 Windows 上)运行相同的 GCode 工作正常。

看起来这可能是资源泄漏——这是因为 Java(蹩脚的)垃圾收集可能不在开发人员的直接控制范围内。

附带说明一下,通用 GCode 发送器在 Raspberry Pi 上无法使用,因为它会大量使用资源——它会立即减慢机器速度。

Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168
所有者

如果你想要大量的 gcode 文件,你需要增加分配给 JVM 的内存量。您可以尝试修改启动脚本来执行此操作。

我相信 raspberry pi 在其默认 java 配置中没有硬件启用浮点,这是性能问题的很大一部分。

Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168

为什么?如果那样的话,您不需要缓冲多于几行。文件系统几乎与 Pi 上的
RAM 一样快,即使在
Windows/Linux 上也没有慢到需要缓冲整个文件(特别是因为现代
操作系统也会缓冲文件 I/O)。

考虑到 gcode 发送器所做的事情的简单性——文件和
具有某些 UI 的设备之间的 I/O,它不应该需要很多资源——并且
不应该能够挂住 CPU。

在 2014 年 6 月 9 日星期一上午 10:58,Will Winder notifications@github.com
写道:

如果你想要大量的 gcode 文件,你需要增加
分配给 JVM 的内存量。您可以尝试修改启动脚本来
执行此操作。

I believe the raspberry pi doesn’t have hardware enabled floating points
in its default java configuration, which is a large part of the performance
problem.


Reply to this email directly or view it on GitHub
#168 (comment)
.

Andrew L. Sandoval
sandoval@netwaysglobal.com

[image: qrcode] http://mormon.org/me/72HW/

Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168
Owner

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.

Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168
Author

Understood, and that is a great thing to do, but it should be a
pre-processing step with the results going to a temporary file. Doing so
would make it usable in lower memory situations. Obviously I can’t dictate
to you how to write your program. I recommend considering this as a change
for a future version. In the meantime I will explore other options and if
necessary will write my own.

FWIW, the Universal GCode Sender has worked fine for many things, and to a
large degree it sets the standard in free gcode senders.

On Mon, Jun 9, 2014 at 11:30 AM, Will Winder notifications@github.com
wrote:

UGS preprocesses every line of gcode to do things like truncate extra
decimal precision and remove whitespaces.


Reply to this email directly or view it on GitHub
#168 (comment)
.

Andrew L. Sandoval
sandoval@netwaysglobal.com

[image: qrcode] http://mormon.org/me/72HW/

Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168

I like the pre-processor idea.

Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168 winder changed the title Universal-G-Code-Sender becomes unresponsive after ~250,000 lines damaging end product… Universal-G-Code-Sender becomes unresponsive after ~250,000 lines 2015 年 3 月 31 日
Universal-G-Code-Sender 在大约 250,000 行后变得无响应 #168
所有者