The produced gcode right from the LB already had the bug in it (second picture above), even before send it to the laser board, so I tend to believe that the laser system does not have any contribution in this situation.
I don’t understand why, if this is an issue with the GCode, the version plotted by the other software shows more lines than your final output. For example, in the upper loop of the L, there are 3 lines that shouldn’t be there in the preview, but only one of them appears in the cut file. The o is similar - I count 4 lines off the right side of the o connecting to the p in the plotted GCode version, but only one appears in the final cut. I don’t see why they’d be different, or why you’re the only user having this issue.
The second image was also generated with Lightburn. I just opened the gcode file, that was previous saved with LB, with a gcode reader to see the output. And the gcode already has the error lines.
This test was to remove from the equation any posible problem with the hardware not turning off the laser when it should. Actually the machine is doing exacly what is coming from the gcode.
Did you enable that in the first place? If you hover over the button, it says it requires a specific version of Smoothieware. It’s not a bug - it would be emitting gcodes that aren’t supported by the version of Smoothieware on your board.
looking to the gcode, what a found different was some rows (14 rows) with additional 0:0 like this:
Original: G1X-3.2S0.07
With the option enabled: G1X-3.2S0.07:0:0:0
By the way, where can I find more information about this clustering stuff and the compatible firmware version?
Thanks for the clarification Oz. At least we now know what are the side effects of having that option enabled without the proper firmware to support it
Extra question: where is this option?
Added “move laser to” controls - automatically jog the laser to the center, corner, or side of a selected object
