Grbl/M4 and Lightburn — closed-shapes… NOT!

New Home Forum Random or Off Topic Grbl/M4 and Lightburn — closed-shapes… NOT!

This topic contains 69 replies, has 8 voices, and was last updated by  Oz 2 days, 11 hours ago.

Viewing 30 posts - 31 through 60 (of 70 total)
  • Author
    Posts
  • #120214

    K Cummins
    Participant

    Spray those with Shellac, and you’ve got some $20 earrings on etsy. Easy. Maybe put a wire in them too.

    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. 😉

    1 user thanked author for this post.
    #120217

    dkj4linux
    Participant

    Spray those with Shellac, and you’ve got some $20 earrings on etsy. Easy. Maybe put a wire in them too.

    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…

    And then YOU came along… 😉

    #120219

    K Cummins
    Participant

    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…

    And then YOU came along… 😉

    Always happy to highlight the foibles and follies of others! 😀

    #120249

    dkj4linux
    Participant

    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.

    20191107_001832

    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”

    20191104_092557-1

    Marlin… big difference

    20191107_001311

    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?

    Enough! For tonight, at least. Night, night… all.

    — David

    #120270

    Jeffeb3
    Participant

    Can you post the square gcode with the marlin config?

    I think you could probably run the square with grbl config on marlin. You’d want to separate the line with a bunch of gcodes on one line.

    #120276

    dkj4linux
    Participant

    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.

    • This reply was modified 1 week, 4 days ago by  dkj4linux.
    #120283

    dkj4linux
    Participant

    Here’s better/simpler… turned off the cut-through option in LB…

    #120288

    dkj4linux
    Participant

    OK… I guess I expected this…

    20191107_083455

    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” 😉

    Later.

     

    #120292

    Jeffeb3
    Participant

    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.

    Here’s a link to their issues to give you a nudge: https://github.com/grbl/grbl/issues

    #120293

    Jeffeb3
    Participant

    This file is interesting too. This is the one with the “cut through” option on:

    ; 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
    G1 F100 S511.5
    G4 P0.05
    G1 S0
    G0
    M5
    M3
    G1Y25S1023F1000
    G1X25
    G1Y0
    G1X0
    G1 F100 S511.5
    G4 P0.05
    G1 S0
    G0
    M5
    M5
    M9
    G1S0
    G90
    ; return to user-defined finish pos
    G0 X0 Y0
    M2
    

    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.

    #120294

    Jeffeb3
    Participant

    This is the other code:

    ; 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
    M5
    M9
    G1S0
    G90
    ; return to user-defined finish pos
    G0 X0 Y0
    M2
    

    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:

    ; 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
    
    #120299

    David Walling
    Participant

    I’m wondering if it’s a hardware issue.

    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.

    #120301

    Jeffeb3
    Participant

    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.

    But it’s cutting off early, not starting late. The hardware would have to know the arduino was about to turn it off.

    #120322

    dkj4linux
    Participant

    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.

    20191107_100517

    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.

    sq25-Grbl-LB-2

    I think David is right… I need to generate some Grbl gcode from another software and try it on that machine.

    Later.

     

     

    #120326

    Jeffeb3
    Participant

    Chip off the old block, eh?

    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:

    ; 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
    
    #120330

    David Walling
    Participant

    Whatever it is, it’s extremely consistent.

    #120331

    Jeffeb3
    Participant

    Based on the images, it’s off for about 15% of the length of one side. The feed rate is 1000mm/min, and the length of the side is 25mm.

    So my guess is you need to dwell for close to 0.2s. I think that’s a G4 P200, but it should be easy to tell if that’s way more than 0.2s.

    #120337

    dkj4linux
    Participant

    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.

    20191107_154933

    Don’t remember how to insert inline code, so have attached the file. It can’t get any simpler.

    Openbuilds_cam-grbl

    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 😉

    What next?

     

    #120341

    Jeffeb3
    Participant

    Marlin isn’t the only difference, right? The laser hardware is different. So the one attached to grbl is taking longer to power up from a cold start.

    #120342

    Jeffeb3
    Participant

    Does this code work?

    #120366

    dkj4linux
    Participant

    Does this code work?

    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…

    #120378

    Jeffeb3
    Participant

    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.

    #120394

    dkj4linux
    Participant

    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…

    20191107_202232

    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.

    sq25mm_OB-original

    I’m tired and my head hurts. I’ll take a look again tomorrow… and try to be more systematic about it.

    Later.

     

     

    #120499

    Jeffeb3
    Participant

    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).

    #120513

    dkj4linux
    Participant

    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.

    sq25_0001

    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.

    sq25_0002

    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.

    — David

     

     

    #120521

    David Walling
    Participant

    Sounds like your experience has now come full circle like mine.

    I really wanted to like LB too. But in the end, I found Inkscape to be easier and less complicated.

    #120542

    JeffH
    Participant

    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.

    #120723

    JeffH
    Participant

    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…

    Cheers

    1 user thanked author for this post.
    #120849

    dkj4linux
    Participant

    OK. Another data point…

    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.

    20191111_093323

    20191111_122734

    20191111_125157

    20191111_122757

    20191111_122811

    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.

    All is right in my world again… and I am at peace 😉

    — David

     

    2 users thanked author for this post.
    #120897

    JeffH
    Participant

    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:

    https://www.v1engineering.com/forum/topic/grblgru-lowrider-2-virtual-simulation-5-axis/page/2/#post-120896

    The more control boards, the more Fun! ha ha

Viewing 30 posts - 31 through 60 (of 70 total)

You must be logged in to reply to this topic.