I wonder if the M5 is getting muddled with the G1X0 and it’s treating the final point as a place to end up at zero power. Although, I would guess it would be more of a mess than just the last few mms.
What if you added a dummy command at the end:
[scode]
; LightBurn 0.9.07
; GRBL-M3 (1.1e or earlier) device profile, absolute coords
G00 G17 G40 G21 G54
G90
; Cut @ 1000 mm/min, 100% power
M8
M5
G0X0Y0
M3
G1Y25S1023F1000
G1X25
G1Y0
G1X0
G1X0 F100; dummy, do nothing command.
M5
M9
G1S0
G90
; return to user-defined finish pos
G0 X0 Y0
M2
[/scode]
You mentioned that your engraver is an Eleksmaker. Mine is very similar. Is yours using the small arduino nano based controller? I’m wondering if it’s a hardware issue between the arduino nano and the control board for turning the laser on/off. Maybe there’s a mirosecond delay from the time the board gets the ‘on’ signal for the laser to the time the laser actually fires.
The over-cut might be a software solution to a hardware issue.
The only other option to help narrow it down would be to use another piece of software to generate the Gcode and see if the device behaves the same.
Now that I think about it, I’m not so sure… if it was a hardware issue, wouldn’t you see it all over the piece? Not sure… hrm. It’s all quite interesting.
I’ll crank mine up this weekend and see if I can reproduce the issue. I have some foam board I think I can test this with. It should easily cut all the way through it.
OK… just got back from spending a few quality hours with my daughter… what fun! We’ve been learning how to design and engrave/cut custom designed earrings and pendants. The CNC stuff is all new to her but she’s picked up on it all very quickly
As expected, the burns from that simple 25mm square gcode file were bad on the little Grbl machine.
[attachment file=120323]
The problem, I believe, is with the beginning of the burn… the 3 leftmost squares are burned in one orientation, the rightmost with the workpiece flipped. The cut starts in bottom-left corner and proceed “north” with a delay before burning actually starts. It then continues clock-wise and terminates with full burn right up to bottom corner, where the cut began.
[attachment file=120324]
I think David is right… I need to generate some Grbl gcode from another software and try it on that machine.
I am going crazy. I can picture in my head the image of it failing to finish and not failing to start.
I don’t know why my brain thinks it saw that. How about just adding a dwell to the start of the gcode, after turning on the laser? I mean, I guess you’ve already got a workaround, and we’ve got a good hypothesis as to why.
Something like this might work:
[scode]
; LightBurn 0.9.07
; GRBL-M3 (1.1e or earlier) device profile, absolute coords
G00 G17 G40 G21 G54
G90
; Cut @ 1000 mm/min, 100% power
M8
M5
G0X0Y0
M3
G4 P1 ; Added this to “dwell” here for a moment. P is in milliseconds, so you may have to adjust depending on how long it takes to turn on the laser.
G1Y25S1023F1000
G1X25
G1Y0
G1X0
M5
M9
G1S0
G90
; return to user-defined finish pos
G0 X0 Y0
M2
[/scode]
NOW I’m really confused. I went to the Openbuilds site and used their online OpenbuildsCAM to create some gcode for the same 25mm square… and got the same crappy result.
[attachment file=120338]
Don’t remember how to insert inline code, so have attached the file. It can’t get any simpler.
[attachment file=120339]
It’s easy to believe that my little machine could be at fault… but the LB developer would never have seen cause to add an “Overcut” feature if it hasn’t been observed elsewhere. So I really don’t know what’s going on…
I’m pretty sure the “cut-through” function adds in the delay you are advocating trying… and I’ve tried that. And I think that is primarily to allow time for the burn to propagate all the way to the bottom of thicker material before moving forward. But here we’re really not interested in burning through the material… we’re only asking the beam to get started before movement begins. And it’s not…
I was starting to think LB was at fault… but now I don’t think they are. And I don’t think Grbl is at fault… using 0.9j version. And Marlin doesn’t have a problem with it at all. So, as I said… NOW I AM REALLY CONFUSED
I’ll try it in the morning. It’s after dark, raining, and getting cold… the front is coming through. I know the files are different but do you see any similarity in this file and the one with “cut-through” code in it? Maybe it’s me, but the LB-generated gcode really looks “cluttered” and harder to follow…
The open build code is so well commented. The LB code also does more than one command per line and doesn’t include spaces betweeb things like G1 and X25.
The cut-through code had a dwell in it, but it was really short.
Alright… sucked it up and trudged back up the hill to my daughter’s house. Intended to just run two quick tests… wound up staying a while and trying many more things… enough that I’m getting the sequence of things all mixed up in my head… and having a hard time remembering what I did to what…
In short, your code works… with an appropriate delay. I think you had G4 P200… I think I shortened it to G4 P2.00 and it worked better. Those runs are the 2 on the far right…
[attachment file=120395]
I also remembered trying the cut-through mode and different start pauses… with no success. So looked at the “cut-through” gcode again from earlier in this thread and thought there needed to be an M3 prior to all the cut-through delays. So I edited in that file that first M5 (which really isn’t necessary for this simple test) to be M3… and that worked… those are the left upper-most 2 runs… after that I don’t remember what I did…
But I think we know the required sequence of things… turn on laser, dwell/pause for a time, and then move. But I think LB’s generated gcode is so muddled up and it appears all the G4 dwells put in for cut-through purposes are occurring before the M3 commands they’re supposed to effect… and as a result it doesn’t work.
BTW I did edit the Openbuilds code to change M4 to M3 (grbl 0.9j doesn’t have M4 dynamic laser mode) and remove any/all Z moves (I don’t move Z while lasering…) and it simplified things quite a bit. Also the 4 G1 lines all specified all axes (X, Y, and Z) and I removed the redundant values… leaving only the one changing. So it would up looking much neater and cleaner than it did before the edits… but even the unedited OB code was far cleaner than the LB code. The comments in the OB code were there in the original gcode however… so good on them.
[attachment file=120399]
I’m tired and my head hurts. I’ll take a look again tomorrow… and try to be more systematic about it.
This original code is turning the laser on right away, and then driving 10mm up and back. So that’s like a long dwell.
IDK what units the G4 P are in. The doc says it should be milliseconds… Well, whatever that ends up being seems better than the distance based 1mm of overcut (I can’t remember the correct term).
I really don’t know why I’ve been so brain-dead over the past couple of days…
For some reason I didn’t think about seeing what the Jtech laser plugin and Inkscape would do… and I’ve only been using it, almost exclusively, for the past couple of years to generate Marlin gcode. Go figure…
Anyway, fired up Inkscape, drew my rectangle, changed it to “path” type, and called up the JTech extension. Put the M3 and M5 codes for laser start and stop. Initially, added 0 for PowerOn Delay, and generated the gcode. Took a look with text editor… very straightforward and, interestingly, contained “placeholder” G4 P0 statement before and after each M3.
[attachment file=120514]
Tested with 0 delay, same unclosed figure we’ve seen before. Added a 0.2 second delay (JTech site says it’s seconds for Grbl, ms for 3dprinter) and ran fine.
[attachment file=120515]
As this code seems cleaner and works great with the delay, I’m giving in to using Inkscape and laser plugin for now.
I spent some time with my daughter this morning and we were able to consistently get better cuts/burns with this flow. I really want to like/prefer Lightburn but TBH it has been designed apparently with Inkscape’s UI in mind and it’s a fairly simple matter to switch between the two. While LB’s project files can’t be imported into Inkscape… LB does have EXPORT to svg, which can then be imported to Inkscape. LB tries to do some really nice things and, given time, I suspect will be the way to go. But, for now, I think the JTech laser plugin generates cleaner code and seems to work great, with little fuss.
Sorry if I add to the confusion. It seems to me I’ve read that Lightburn uses Inkscape’s engine. My laser is only 3.5W so I haven’t bothered trying to do any significant cutting. I haven’t found any problems as David has described with any of the pattern burning I’ve done. I did find problems with Inkscape and design dimensions not adding up between programs so I quit using that lol.
I am running Lightburn on an Arduino Uno with GRBL 1.1e (or greater) and have the Laser mode enabled. It really has been a great piece of software for me thus far. It’ll do engraving on cylinders but not bowl sides
I’ll try remounting my laser on the MPCNC this weekend and running David’s errant Gcode on an Uno.
I’ll also try running some GCode with Grblgru, an Arduino Mega, and the laser. Grblgru can follow bowl sides, ie both curves.
I fired up the laser on my MPCNC this morning run by an Arduino Uno with GRBL 1.1g.
I ran David’s gcode files as I found them posted above in Lightburn - all 5 that would run on an UNO - not the Marlin ones.
3.5W laser. Squares are 25mm on a side. No problems or adjustments. No missed segments as he had.
Might be a problem with a Nano and its processing power? since a lot of other LB programming things have been suggested. I don’t believe I have done anything fancy with my version of Lighturn. I’ve engraved simple shapes like this as well as gray scale pictures without any problems other than on white surfaces but that is expected…
Once I delivered my daughter’s laser engraver… dragged out an Eleksmaker A3 3.5 watt laser machine I had built up before. Got it set up and running with Mega/RAMPS/Marlin – as before – and then went to my stash and found a Uno/CNCshieldV3 board set to play with. Converted the Eleksmaker to a Grbl v1.1h set up… and hooked up the 3.5 watt Banggood laser it had mounted.
What do you know? Confirming JeffH’s findings, this unit seems to handle every test case presented in this thread without difficulty! Not a problem at all with unclosed shapes. Lightburn is fine… Grbl is fine. Apparently the CNC processor/controller and/or laser driver are the culprit(s). Note also the M3 and M4 labels… in Grbl 1.1h laser mode, M3 is the CONSTANT power mode and M4 is the newer DYNAMIC power mode. Look closely at the corners… and note the darker M3 burns whereas the M4 burns are beautiful.
[attachment file=120850]
[attachment file=120851]
[attachment file=120852]
[attachment file=120853]
[attachment file=120854]
I think I’m going to tidy this machine up and swap out my daughter’s machine. She said she prefers Lightburn’s all-in-one, ease of use, features over Inkscape/Jtech and is looking forward to the larger work area of the Eleksmaker machine.
For fun you can now use your Mega + RAMPS + GRBL Mega 5X and a laser. I figured out how to control my little laser today. I described the solution at the bottom of this topic:
