This was an option in earlier versions of Luban and then was removed. Users shouldn’t have to modify Gcode or use earlier versions that aren’t compatible with the 10W laser.
Change the method to Fill. Then it disappears.
Hm, seems so, although I generally still use Luban 3.15.2 on the rare times I actually use Luban to generate GCode. I do hate Luban 4+, (I mainly use Lightburn and Luban only for sending the file wirelessly to the machine).
I will note though; unless you really care about the built in library in Luban 4+ (the presets similar to the above screenshot), there’s no difference in the generated gcode between the 1.6W and 10W laser. Just make sure you set your power and speed properly. As far as GCode goes, S255 is the same full power, be it 1.6W or 10W. There’s no real “compatibility” issue with the 10W laser, unless you use the camera function (I would guess, I never use it or did any real tests with it and old versions). Do your layout, do your settings, generate the gcode, send to machine and it should be good. The machine itself knows the offset for the 10W laser vs 1.6W.
It does appear to do multipass. Although there is no “passes” field for Fill engraving, it always does 2 passes. Yet I only want one pass. I have to watch the print and stop it manually after it completes the first pass, otherwise it will continue on to the second pass. Another seemingly bug.
It’s not a bug. There’s a problem with your image file and how the object has been created. It’s not seeing it as a single line or solid object. It’s doing both the inside and outside of it.
-S
1 Like
Hmm, I won’t dispute that it could be a file issue, but why would a “Fill” do the outside?
Turns out there were crop mark in the corners that were lines (not fills) albeit 0.001mm in width. But regardless, it seems strange that it would go back and re-fill the already filled objects.
Anyways, that was it, thank you for the answer.
Update, I’ll retract my previous statement. There is definitely some issue with Luban. I create a new path using the same SVG and settings 4 times, and each time Luban adds the previous path(s) (and hence an extra print pass) to the output. Thus the g-code file size grows geometrically (as seen in the screenshot) …
Now it turns out that Luban combines all existing/visible tool paths when creating a new one. Not sure wether this is considered a bug or is intended behavior. But at least now I know what was causing the multiple (unwanted) passes.
So you have to turn off the visibility of previously created paths when you create a new one (unless you do want multiple passes as the OP requested). So it wasn’t an issue with the SVG after all.
That is intended.
It’s so you can set up multiple passes/objects/shapes within the same gcode file.
-S