Does anyone got an idea why Laserweb is stuck at 50% when processing my quite simple SVG file? I’m trying to do a Mill Cut on it but it always stops at 50%. A laser cut on the same SVG file works without issues.
Try an place a 0.5 value in the segments field
Just found in another post that SVGCleaner might help. Ran it and it totally removed the path. Can anyone tell me whats wrong with it? I’ve created is using Inkscape. Link: https://jmp.sh/yQ2nATW
@Ariel_Yahni_UniKpty Tried 0.5 and lots of other values. No success.
I just tried your file and could generate in milliseconds
@Ariel_Yahni_UniKpty That’s really strange. I’m using 4.0.990 / 4.0.301 and I can only “Mill Cut” this shape but not “Mill Outside” or “Mill Inside”. I’ve also tried it here online ( https://laserweb.github.io/LaserWeb4/ ) and it also gets stuck at 50% during the generation process. In addition I now inbetween had several other shapes which showed the same problem. I always made sure it’s a closed path in Inkscape. Did you do anything to the provided file before it worked for you? Thanks you!
Anyone can help me? I’ve the same problem with lots of other shapes as well. In between I’ve tried it with three different PCs and even with Edge (aww). The only thing I figured out now is that the gcode generation finishes when i use a larger tool:
Toolsize=10mm -> Completed after 15 seconds
Toolsize=8mm -> Completed after ~30 seconds
Toolsize=6mm -> Waited 10 minutes then cancelled it
I assume it’s calculated on the client side? My lw-comm-server is running on an Raspberry. Is this the bottleneck? Any help is really appreciated!
It could be a bottleneck, try with dxf. I’m not doing anything to that file
Thanks for the additional ideas but unfortunately they also did not help:
- DXF: All curves are missing
- GCODE CURVE LINEARIZATION FACTOR: I don’t have this value in my settings page although I’m on the latest version
- My browser is using 25% (one full core). The Raspberry is idle during the generation time, so it is definately the browser (client) part which is somehow in an endless loop.
Could please someone else try to “Mill Pocket” this SVG with Tool Size = 2mm… best using Chrome on Windows and a Rasperry?
Enabled debug logging and observed the Chrome console with the following result. My Windows PC memory usage is at 50% (8 GB of 16 GB used) while running tons of other stuff. Chrome itself is at 1175 MB. The shape I’m using is really not quite complex. Problem starts to appear with a tool size of 7mm while 8mm is still processed okay.
@Michael_Zeile The way gplus works no ne else will see this post unless someone specifically wants to see it.
Im sorry you are having a hard time getting this to work but its puzzling to me how fast it work on my side in windows and osx. FYI i prepare my svg in illustrator with no issues, also i use sketchup, rhino, fusion 360 for dxf files
@Ariel_Yahni_UniKpty I see. Actually this is the only occasion I ever came in contact with gplus I’ll keep on trying but even the Windows Application (not Raspberry + Chrome Browser) does not generate this shape. I assume it has something to do with the SVG. I’ll check other possibilites what you proposed. Thanks a lot!
@Michael_Zeile My advise is to use the binary installer for the frontend and connect to the server (Raspberry Pi) from there. This way you get the newest frontend version.
The frontend that is embedded into lw.comm-server is an older version and not realy maintaned.
@cprezzi Thanks for taking care of the issue! I’ve not thought about this combination yet. However I did already test the Windows version (using the binary installer). I once more gave it a chance and was doing a “Mill Pocket” operation on the SVG file (see here or on github). Result is that the path is generated after 45s using a 6mm tool diameter. With 4mm is did not complete at all and stopped after 1 hour (the maximum I guess). I’d not assume that the path is this much more complicated between these two different tool sizes. I’d be more than happy if you could try it for yourself. Thanks!