I am attempting to do a test mill pocket calculation on a svg that I created in Inkscape. However when I attempt to do it, the GCODE generation hangs at 50%. I have seen two other posts that discuss this in 2018 and 2020 and I was wondering if anyone else is still seeing this issue in 2024 on a simple shape (JSCUT worked fine on it.)
I’ll attach the SVG to this post if someone else could try it out and help me that would be greatly apprecaited!
Also note: I have attempted this GCODE generation on both the web based app and the linux appimage and both hang at 50%.
EDIT: I just noticed ‘mill pocket’ in your heading (oops, sorry!). I’ll update this asap.
The answer will be the same… but more so. Mill Pocketing is known to be slow and prone to running out of memory.
I’ll give it a go on my laptop, and I’ll be in dev mode and looking at the console as I go… (hurts performance but helps debug)
My first thought was to have a quick check of the SVG file, and there are no errors there (commendably short and all paths closed), so the issue is not there.
I can import it into LaserWeb (running in the browser of my fast laptop), it is slow to import. I can then generate both path cuts, and fill cuts for it. They are fairly slow to generate but get there in the end.
Did you wait to see if it completes? Even on my fast machine I had to click away the ‘wait for page to complete’ dialog a couple of times. I also have 8Gb of ram, which helps.
It is normal to see the progress go to 50% then stop. This is a limitation of the gcode generator; which runs in two steps and doesn’t report intermediate progress within them.
The TL;DR is that LaserWeb works internally using a canvas, it is used for the screen display and for generating gcode. The SVG file you are using is huge (340 x 350 mm); each of the curves in it needs to be mapped to the canvas and broken into many straight ‘segments’, this takes time for such a large image.
You can see this in in the way that the source image is under 2K in size. The generated line cut is 1.4Mb in size, and a fill cut (at 0.1mm) almost half a Gigabyte!
I dont’t have any magic fix for this; we are bumping into limits of how fast JavaScript (remember we are running IN the browser) can handle this stuff. There is a lot more I could say but the essence is that LW works better on smaller jobs.
I did let it run for a while (over an hour) and it still didn’t complete. Thank you for the information though and I’ll try and keep the sizes smaller when working with this tool.
