Hi! I’m loving using LaserWeb 4 on a Elekslaser engraver. I’m finding that SVGs with curves (even simple curves) are super slow though, but if I use the ‘Flatten Beziers’ tool in Inkscape they’re fast.
Is there a setting somewhere that’d allow me to choose the tolerance that SVG curves are converted with in LaserWeb4, so that I can get much faster processing?
thanks!
try the segment field, that will ignore any path bellow that size
Thanks - I did find that one already, and it’s made a massive difference to the actual laser cuts - it’s now super smooth when cutting. However, the slowness comes in the software even when clicking ‘Add Document’ - before I get to specify any of the cutting parameters. Obviously gcode generation is slower too - but ‘segment’ doesn’t help a great deal there.
In settings theres another option under gcode to increase the thread count, try 4 in there
Thanks - i’ll give that a try. I guess that’ll make it max 4x faster though? Do you know if there’s a way to manually specify the settings (as JSON?) on Linux? It looks from https://github.com/LaserWeb/LaserWeb4/blob/ad6c85f89923ff81e640e0555aafbe438969ad52/src/lib/lw.svg-parser/parser.js#L23 like it might be possible to set settings.traceSettings.resolution (or one of those) to make it parse SVGs into lines at a slightly lower quality
I was just exploring this issue. From what I’ve read it has something do with the communication speed in which laserweb functions. This is what I found on Reddit explaining it:
"I think smoothieware can only process a single command at a time. By this I mean the control software sends a command, waits for smoothie to send a response, and only then can send the next command.
Grbl on the other hand has a 127 byte input buffer, so while the first command is being processed several more can be sent. By having the next commands ready to go, there is no delay in the controller when it is ready for the next command.
Laser engraving is particularly troublesome for the send-response protocol because those gcode files have many thousands of tiny commands which each incur that small delay, and that delay can leave unwanted burns in your project."
I’m not sure how accurate this is but I too have this issue and it’s driving me nuts. I love smoothie but it’s a pain now that my projects have grown beyond the stock size of the k40.
@Chuck_Comito I think he was reffers to the time it takes the gcode to be generated.
I supposed he might have been. I guess either way we’re experiencing the same issues with that as well . Slow to load (slow computer), slow to engrave/cut round objects in lw4 (My other issue).
I haven’t seen many cases of slow loading that could not be fixed by making some changes to the original files. Havent seen any slow cutting at all in any situation
The only time i have seen that movement in my case was when each path is made from many tiny paths and that is directly related to very slow gcode generation.
Can you send me that file?
I’m not sure if i have that one but I’ll take a look. Either way it happens on almost all my files. I’ll dig something up and post it.
yeah i understand, it could be in your workflow, for example it happens to me with dxf
Hey @Ariel_Yahni_UniKpty , here’s a link to what I think that file was: https://www.dropbox.com/s/clpkg6kjp6qyi52/So%20I%20can%20Kiss%20copy.svg?dl=0
@Gordon_Williams , I didn’t mean to hijack your question. Ariel is one of the best though and I’m sure he will end up helping both of us…
Took me about 1.14. how long does it take you?
Do you get behaviour like the video while cutting?
I’m assuming you mean loading the file took 1.14 seconds or that’s how long it took you to generate the gcode? Loading this file takes me upwards of 30 seconds. Generating the gcode can take 10 minutes on that file. When cutting it behaves as it does in the video I posted in the other thread.
I meant generating 1 minute. Will check the other one tomorrow.
Yeah, generation takes a long time. I should mention that the layers are inside cut, outside cut, etc.