FWIW, the gcode looks totally fine. It definitely starts and ends at the same place, and it turns the laser off after it stops.
If it was acceleration settings, I would think it would fail at all the corners on the square, not just the last one.
If this was Marlin, I would guess that the M5 is being performed before the movement is finished. This happens when you send M42 (and I think M106) to change the state of the pin. As soon as that’s seen on the incoming serial, it happens, even if there are three moves left in the planner. I thought grbl, especially with laser mode, was supposed to be better at this.
I wonder if you shouldn’t submit this as a bug to grbl, with the gcode and the image.
The overcut is a good workaround, but with different speeds, and more fickle material, it might be hard to tune right.
I wonder if you did a very small overcut, like 0.01mm, if it still would close the shape. That would indicate it’s some sort of hard logical mistake, and not a squishy, geometry/physics problem.
I searched the LB forum for “overcut” and apparently it’s a pretty new feature… here’s what the developer had to say:
“It only works for closed shapes - it cuts past the end, wrapping around to the beginning again, almost like doing a second pass, but only a couple mm of it (or however long you tell it to). Useful for thick materials where beam drag at the beginning of a cut is an issue.”
Which of course begs the question(s): What the heck is “beam drag”? and “Why the heck haven’t I seen this before?”
Alright… I can see that the beam cuts from top to bottom and it’s not instantaneous. So, I think he’s saying… the beam moves forward at some velocity and, simultaneously, the cut propogates from top to bottom. Okay, there’s a “lag” or “drag”…
But why haven’t I seen this before? Why just the first move? There’s also a “cut through” mode that allow setting a pause (ms) from beam turn on to physical move. I tried that, without success… why didn’t that work? I also started playing around a bit late last night (Merlot in hand… ) with manually editing/rearranging the cut order of the sides in the gcode file… and I’m pretty sure I was able to cut a perfectly closed figure. Why would that make a difference?
Okay, so I’m more confused than ever but I can cut my parts out… in a single pass PLUS OVERCUT. Time to get the daughter involved…
[attachment file=120181]
[attachment file=120182]
My mind is reeling a bit but I’m really impressed with Lightburn’s features… manipulating images, vectors, and all cuts in the same file, boolean operations, etc. There’s still a lot to learn yet but I’m pretty sure it’s going to do everything I need to do with it. Better go get some more Merlot…
This is pretty exciting to follow along with. Solid laser software is needed around here, so maybe at some point we can either make it work with Marlin, or find a board that works well with either Marlin or GRBL.
That’s exactly what the daughter is wanting to do. Probably not online… but she’s worn them to church several times and could have taken a dozen orders or more…
These took 14 minutes to do after I “boolean-ed” the mandala with the outline and tightened up the pair arrangement…
You might consider mirroring the designs, rather than duplicating and rotating. They are gorgeous, but those with symmetry OCD (like my wife and I) would want mirrored patterns, not duplicated… At least for some portion of the job runs.
Funny you would mention that… they were supposed to be mirrored but while playing with LB’s mirror functions I did both a horizontal and vertical mirror operation vs. a mirror and rotate. Noticed it when stacking a few up to go show my daughter…
OK, to confuse the matter further… delivered the little laser engraver to daughter and finally hooked up my FoamRipper (running Marlin on MKS GenL…) again. It also sports a 2.5 watt Eleksmaker laser, similar to the little machine I just delivered.
[attachment file=120252]
Loaded in the same “closed_shapes” LB project file I showed early in this thread. This time, however, I selected Marlin to be the target gcode player… and ran the job on FoamRipper…
GRBL (from before)… with UN-closed “closed figures”
[attachment file=120250]
Marlin… big difference
[attachment file=120251]
Lightburn was used to generate gcode for Marlin and Grbl… from the same project data. I’m pretty sure – I’ll try to test it later – I’d be able to profile cut those earrings in a single pass… WITHOUT OVERCUT. And explains why, using Marlin almost exclusively before, I’ve never seen this problem. Same/similar material (cereal-box chipboard), don’t think it’s “beam drag”, and the LB developer might never have had reason to put in the “overcut” feature if he’d only developed for Marlin-based machines.
Not sure what, if anything, this might be telling us… it’s late, I’m tired, and probably whistling in the wind. But maybe some of you clearer, smarter, heads can make head and tails of it… and tell me what we should try next, if anything. Maybe LB can be a candidate for that “solid laser software” recommendation Ryan says we need… if it can handle both Marlin and Grbl, is not too expensive ($40), and runs on Win, Mac, and Linux?
Here’s a simple 25mm square in both gcode flavors, unedited, from Lightburn. I’ll need to confirm these will result in different output… but here they are for comparison.
I’ll see how Marlin/FoamRipper handles the Grbl gcode – with M3/M5 edits for M106/M107 – in a bit.
Side-by-side, the Marlin (left) and Grbl (edited for Marlin on right) gcode… both run on FoamRipper/Marlin. And, as expected, the M8/M9/M2 gcodes were flagged as “unknown command” for this run… not a problem.
We know that the un-closed (bad!) Grbl results we’ve seen in previous run… all previewed properly in several different viewers (LB, Camotics, G-Code Q’n’dirty toolpath simulator, etc…), but burned badly. That’s why I wasn’t surprised at the results above. I now need to run the Grbl code on the daughter’s Grbl machine to confirm the bad results we’ve seen previously.
So – if it’s confirmed – it’s a Grbl firmware thing and/or the Grbl gcode output from LB? But I’d bet the Grbl gcode from other softwares, for this simple shape, would run fine on GRBL firmware… surely that would have been seen as a “bug” a long time ago, and fixed. So, it’s got to be the LB’s gcode generator/post-processor?
I dooubt this makes any sense so I need go check it out on the daughter’s machine… before I blow a “mental fuse”
I definitely think you should post this gcode and the results on the grbl and Marlin machines on the grbl issue tracker. It’s very possible they’ve never seen this issue before, and anyone who has, hasn’t reported it.
The nice thing for them is, it’s a really clear issue, and 10 lines of gcode to reproduce, so it should be quick for them to figure out what’s going on.
So it turns the laser on to half intensity, dwells (for a very brief moment, 0.05ms, or 50 microseconds), and then turns the laser off again before starting.
) with manually editing/rearranging the cut order of the sides in the gcode file… and I’m pretty sure I was able to cut a perfectly closed figure. Why would that make a difference?
At least for some portion of the job runs. 
