I have been experimenting with smoothieware to implement it into my K40 laser. My intention was to upgrade my Marlin controller because of speed limitations. With Marlin and its base64 encoded raster mode, I can feed reliably at about F4000 or about 65mm/s, but because of this speed, have to limit to laser power to about 20%. Increasing the feed speed would allow me to increase the power of the laser and finish jobs faster. However, out of GRBL, Marlin and Smoothieware, I have found smoothie to be the slowest at processing gcode for raster, and with no dedicated raster mode like marlin, I have been unable to run my K40 at speeds above about F2500 or approx 40mm/s.
I’ve love to hear other peoples real world experience with smoothieware and laser rastering because for me, unless someone can point me in the right direction as to what I am doing wrong, I will be going back to Marlin or GRBL and maybe even look at LAOS instead.
Imported from wikidot
Have you tried playing the files from the SD card ? If so were the results different ?
What program do you use to generate the Gcode and what program do you use to send the Gcode to the board ?
I am using laserweb4 to generate the gcode file, and saving onto an SD card to playing from there. I appear to be getting about 160 lines of gcode per second processed from the card. The exact same file to GRBL over USB/Serial is topping out at 350 lines per second. I tried the file to smoothie over serial on still got 160 lines per second, so the bottleneck is not USB or SD Card. I was hoping via the SD card to be pulling 1000+ lines per second, but I am not seeing it.
The Gcode has been optimised with no repeated G0/G1 commands when not needed and not repeating Y axis movement on each line when not needed. The lines are small and tight but smoothie just isn’t processing it quick enough, even of the SD card. I will try over the network next.
My intention is not to use USB as the pixel rate I am after isn’t practical over serial. Any other suggestions.
Here is the first 20 lines of gcode. There isn’t really must that can be done to make it smaller.
G21
G90
G1 F5000
G0 X45.71 Y0.05 S0.0000
X49.25
G1 X49.30 S0.0196
X49.40 S0.4078
X49.50 S0.9647
X49.60 S0.9882
X49.70 S0.6065
X49.80 S0.3490
X50.00 S0.3007
X50.10 S0.2915
X50.20 S0.2824
X50.30 S0.2627
X50.40 S0.2654
X50.50 S0.2863
X50.60 S0.4275
X50.70 S0.6196
X50.80 S0.6444
I have just tried fast-stream.py and found it was even slower. Only getting about 100 lines per second.
Mmmh that doesn’t match what we’ve seen elsewhere, not sure what’s going on then.
Smoothie is known to go over 1k lines/seconds, which is what you’d expect looking at the code and the processor.
One thing to note is LW4 is still very much experimental, I’m not sure their Gcode is that optimized for Smoothie ( for example it looks like your gcode has some lines removed but for Smoothie that’s actually bad ), and they have been refusing to talk to us about improving things unfortunately. Hope that’ll change at some point. Not saying that’s the problem, but certainly isn’t an ideal situation to be trying to improve things in.
I have an inkscape extension that can also output raster gcode and have been experimenting with it to optimise gcode for raster. What should the code look like to work best with smoothieware?
I have also tried the gcode generated from Visicut with is quite longer for each line. It also isn’t any faster at about 100 lines per second as well.
Is someone able to show me an example of what their gcode looks like that they can get 1000+ pixels per second rastering with? I’d like to try and optimise my file and see if it is any better.