Laser engraving – not really getting great results

New Home Forum Mostly Printed CNC – MPCNC Advice – MPCNC Laser engraving – not really getting great results

This topic contains 282 replies, has 17 voices, and was last updated by  Kyle 5 days, 3 hours ago.

Viewing 30 posts - 241 through 270 (of 283 total)
  • Author
    Posts
  • #88668

    Jeffeb3
    Participant

    i thing that’s сommon property of all raster (but not only) images.

    If it was the original bitmap or ppm, then it would have a hard transition on the pixel boundary, and sloping shapes like the circle in the japan flag would have an approximation of a circle, but each transition would be sharp, and there would be no ringing. JPEGs aren’t the only format with these artifacts, BTW, but they will always have them.

    If you took the Japan flag, and converted it to a bitmap, then ran it through imagetogcode, then I’m guessing it wouldn’t have the same artifacts as if you went from svg to jpeg to imagetogcode.

    Reducing the resolution could help.

    Adding a white background around the whole image will eventually help (if we can get by the buffer issue), and the width of that border would have to be larger than the distance it takes Marlin to stop. That distance (for the curious) is travel_speed^2/(2*acceleration). So at 50mm/s and 400mm/s/s, it’s about 3.125mm. A little less due to jerk (a jerk of 8mm/s would make it approximately 3.05mm).

    I will point out that David’s original comment was that this is better than it was before (right), so this might just be icing on the cake. There’s a lot more that goes into this than I would have thought originally.

    #88669

    Ryan
    Keymaster

    Adding a white background around the whole image will eventually help (if we can get by the buffer issue), and the width of that border would have to be larger than the distance it takes Marlin to stop. That distance (for the curious) is travel_speed^2/(2*acceleration). So at 50mm/s and 400mm/s/s, it’s about 3.125mm. A little less due to jerk (a jerk of 8mm/s would make it approximately 3.05mm).

    Judging by the size we see in the horse and the grey boxes I would agree. 5 to be safe, then maybe we can increase the speed as well.

     

    The program has a switch for 1 bit color, maybe we can convince victor for a few more options to reduce the possible laser level without impacting the picture much, 4 bit with a laser might look just as good as 8 bit?

     

    #88671

    Ryan
    Keymaster

    Well, 0.2 does look much better than 0.3….twice the amount of commands, but half 0.1.

    #88672

    Jeffeb3
    Participant

    Well, 0.2 does look much better than 0.3….twice the amount of commands, but half 0.1.

    The error isn’t proportional either. There’s a point when it will just work (for a particular image). Unfortunately, you won’t know unless you run it. If Marlin can see the next long move while it’s doing the last long move, then it won’t stop. If it has <3.125mm in the buffer, then it will start slowing down.

    BTW, a 5mm gap would allow a max of 63mm/s speed, assuming still a 400mm/s/s acceleration.

    #88674

    Aaryn
    Participant

    This has laser_motion_test.gcode, which includes the fan commands every 10mm. It doesn’t pause at all. The fan commands aren’t causing accelerations (yay!?)

    That is great news and it fits what i have seen previously.  I have a theory that I would like some help testing if someone has time.  I think the reason we are seeing the Pause at each block in the Shades of Grey is all the Repeat F3000 commands.   Hear me out on this.  Every time Marlin receives an Fxxxx Command it will need to clear the buffer before it starts any other movements at the new feedrate.  Marlin doesn’t realize the new feedrate is the same as the old feedrate so it still pauses to clear the buffer.

    Since Victor’s Image to Gcode was written to use a different speed for the white spaces and the burns it is setting the feedrate every time it gets to the edge of a burn.  So the file is full of hundreds of the F3000 commands. Like in this text file here.

    ShadesChange

    So I have removed all but one of the F3000 commands from the shades of grey gcode we have been using.  Can someone please test this file?  Otherwise I will do test it when I get home.

    If I am correct you won’t see the pauses anymore.  If that is the case then we have two options to fix it.  #1  Tweek the firmware to not clear the buffer if the new feedrate is the same as the old feedrate.  Or ask Victor to make that another tweek to the Image to Gcode converter.  Honestly I could see both options being worth while.

     

     

    #88683

    Jeffeb3
    Participant

    Every time Marlin receives an Fxxxx Command it will need to clear the buffer before it starts any other movements at the new feedrate

    Why would it need to do that? Is there something in the code that indicates that? AFAIK, even if it has a command with F3000 and then F2000, it will only do accelerations from 3000 to 2000, not all the way to zero.

    Also, it’s not changing speeds, it’s set to F3000 through the whole file, right?

    #88689

    Aaryn
    Participant

    Every time Marlin receives an Fxxxx Command it will need to clear the buffer before it starts any other movements at the new feedrate

    Why would it need to do that? Is there something in the code that indicates that? AFAIK, even if it has a command with F3000 and then F2000, it will only do accelerations from 3000 to 2000, not all the way to zero.

    Also, it’s not changing speeds, it’s set to F3000 through the whole file, right?

    My Theory is just a theory at the moment.  I need to run the modified Gcode to see if I am correct.  But My theory makes sense from all the symptoms we have seen.

    • Having several moves in the same direction with occasional M106 SX changes sprinkled in the middle doesn’t cause the Pausing we see in the Shades of grey.  We have proven this with your test and with my laser calibration gcode file.
    • Shades of grey keeps pausing for reasons we don’t yet understand at the burn breaks.

    With that said I think the F3000 is causing the pausing.  The only way that would make sense to me is if the moves all stop and restart with the new feedrate.  It is the only

    “Why would it need to do you that?” you ask.  I don’t know seems like an unintended consequence that nobody has noticed in the 3D printing world.

    “Is there something in the code that indicates that?”  Don’t know but first I want to see if my theory is correct.  Is the pause caused by the F3000.  if so then we can dig into the code.  I don’t want to assume that is the cause then dig into the wrong part of the code.

    #88690

    Jeffeb3
    Participant

    Shades of grey keeps pausing for reasons we don’t yet understand at the burn breaks.

    You missed that I tested the buffer_test.gcode, with a bunch of 0.1mm moves, and it was pausing a lot. The 0.1mm movements in the gcode are what (I think) are causing the pauses.

    My mental model for this is the planner has a certain buffer, something like this in the buffer at once:

    (starts a x=0)
    G1 X10.0 ; long move, it’s at top speed…
    G1 X10.1
    G1 X10.2
    G1 X10.3
    (end of buffer)

    As it’s executing that move from X=0 to X=10, it’s looking ahead, and trying to decide if it needs to stop or slow down when it gets close to X=10.0. Since it only sees 0.3mm more of the path, it has no choice but to slow down. The next command (that it doesn’t know about) could be:

    – G1 X20.0 (which would mean it could keep going) or
    – G1 X-10.0 (in which case, it had better be slowing down or something could break).

    If the buffer was big enough to include the next command, or there were fewer 0.1mm commands, then it could see far enough ahead to know it doesn’t have to stop between blocks.

    I’m happy for you to test this theory, I just wasn’t sure if there was more to it.

    1 user thanked author for this post.
    #88709

    Aaryn
    Participant

    Well that makes sense.  I did read your earlier post but I clearly didn’t understand what you meant at the time.  It’s a good theory. If that is the case then when we I run my modified Shades or Grey then I should still see the pauses.

    #88724

    Jeffeb3
    Participant

    Yeah, and your power calibration tool looks like it’s in steps of 0.5mm, and they are all the same size, so that might be why it works.

    1 user thanked author for this post.
    #88763

    Aaryn
    Participant

    Yup.  Confirmed.  The F3000 had nothing to do with it.  The machine still pauses in the same spots with them removed.

    1 user thanked author for this post.
    #88776

    dkj4linux
    Participant

    Yup. Confirmed. The F3000 had nothing to do with it. The machine still pauses in the same spots with them removed.

    Been out most of the day. Just tested a file with all but the first F3000 removed. Same pauses, as Aaryn noted.

    2 users thanked author for this post.
    #88800

    Heath
    Participant

    This thread has been awesome.  You gentlemen are legends.  I have learned an incredible amount even though there’s so much of it that’s over my head.

    #88802

    dkj4linux
    Participant

    For whatever reason, I decided to run our “shades_of_grey” JPG through Image2Gcode… the other one, the MPCNC-customized one from a much earlier thread. Interestingly, it DOES NOT have the darkened edges we’ve been looking at, though it seems to have other problems less interesting (probably user error)…

    20190211_232000

    Here’s the gcode file it created… this file scans top-down vs. bottom-up

    shades_of_gray.gcode

    — David

     

    2 users thanked author for this post.
    #89169

    Heath
    Participant

    David, can you share the settings you used for ImageToGcode or Image2Gcode or whichever you used to make the Garfield gcode?  I scanned through the thread and couldn’t find them, but I may be overlooking them.

    #89176

    dkj4linux
    Participant

    Here’s the ImageToGcode screenshot showing the parameters for the Garfield gcode we’ve been running… this is running under Wine, which explains the slight misplacement of field labeling…

    heath

    — David

    Attachments:
    1 user thanked author for this post.
    #89182

    Ryan
    Keymaster

    I would say 0.2mm resolution is probably unnoticeable and less buffer work.

    1 user thanked author for this post.
    #89183

    Heath
    Participant

    I’ve started playing with LightBurn. Very nice software. But my first attempt to use it with a new image on a new material didn’t go so well. Too many changes at once. I wanted to take a step back and set a baseline with the same settings in the same software that made the Garfield gcode but a new image and then transition that to LightBurn.

    #89245

    dkj4linux
    Participant

    I would say 0.2mm resolution is probably unnoticeable and less buffer work.

    Not unnoticeable, I printed Garfield at three different resolutions using Viktor’s ImageToGcode… our original 0.1mm, 0.2mm, and 0.3mm. I left all other parameters the same… travel and burns rates were both 50 mm/s. File sizes went down accordingly. print times got quicker, and putting fewer burns down on the material lightened it considerably. The 0.2mm resolution did indeed seem to work well for my laser, spot size, and the cereal box cardboard I was printing on…

    20190215_071921

    20190215_071937

    20190215_071952

    — David

    3 users thanked author for this post.
    #89264

    Ryan
    Keymaster

    I saw that on my tests as well. I believe it is not as dark because it is not moving as slow, because the buffer is not as starved. So I think we kept trying to overcompensate the speed for the buffer issue. Using the right sized resolution and the right speed (30-35?) Might get us better results. Or even trying to limit the power output of the laser and find the speed that works without starving the buffer. I might get a chance to play with it some more, but, exciting…I am moving to a spot with a larger work area for me. I have to Pack and I kinda need to try and get all of my prep done so when I do move my shop I won’t miss shipping for more than a day.

    2 users thanked author for this post.
    #89406

    dkj4linux
    Participant

    I saw that on my tests as well. I believe it is not as dark because it is not moving as slow, because the buffer is not as starved. So I think we kept trying to overcompensate the speed for the buffer issue. Using the right sized resolution and the right speed (30-35?) Might get us better results. Or even trying to limit the power output of the laser and find the speed that works without starving the buffer. I might get a chance to play with it some more, but, exciting…I am moving to a spot with a larger work area for me. I have to Pack and I kinda need to try and get all of my prep done so when I do move my shop I won’t miss shipping for more than a day.

    Ryan, I think you guys talking about buffer issues, have nailed it. I’m convinced.

    Shades of gray… opened ImageToGcode and created 3 quick files… changing only the travel and burn rates. I used 0.2mm resolution for all files… and 50mm/s, 25mm/s, and 20mm/s for the rates. Slowing the rates definitely darkened the image and did away with the “acceleration effects” we’ve been seeing.

    20190216_165455

    20190216_165507

    20190216_165523

    20190216_165530

    Well done!

    — David

     

     

    1 user thanked author for this post.
    #89414

    Heath
    Participant

    Am I understanding it correctly that “Feed Rate” is the speed when the laser is on and “Travel Speed” is when the laser is off?

     

    #89417

    dkj4linux
    Participant

    Am I understanding it correctly that “Feed Rate” is the speed when the laser is on and “Travel Speed” is when the laser is off?

    That’s my understanding. I’ve only set them both to the same rate in tests so far.

    #89426

    Ryan
    Keymaster

    Nice, thank you David. So it looks like 20mm/s is primo right now. I do suggest keeping both numbers the same for now until we get things sorted out more clearly.

    We do have the option to increase the buffer, but I do not know what consequences might come of it or if it will actually help.

    1 user thanked author for this post.
    #92137

    Victor
    Participant

    Hello, guys! You, this forum and this thread are awesome! :)At the beginning, as I wrote my app, I had a cheap 1W UV laser (but it was actually less than 0.5W). I made really good results with it. But with max engraving speed of 250 mm/min. I unfortunately broken this tiny laser (it was really small) and bought a real (I think) 0.5W EleksMaker laser module and with it I got the same good results but with speed of 1000 mm/min. Then I bought a new 2.5W EleksMaker laser module in hope I can engrave much faster, but if I go faster then ~25 mm/sec my X-axis begins to stutter. I engrave with 0.07mm resolution. If I change the resolution to 0.3mm I can engrave with faster speeds without stuttering. So it seems (like Jeffeb3 said) to be a buffer and planner issues. I am not frendly to Marlin firmware to fix this issue, but I can change the Gcode 🙂 So my idea is to adjust X- and Y-axis resolution separately. I will make some tests and post the results.

     

    Nice, thank you David. So it looks like 20mm/s is primo right now. I do suggest keeping both numbers the same for now until we get things sorted out more clearly.

    We do have the option to increase the buffer, but I do not know what consequences might come of it or if it will actually help.

    Hi, Ryan!

    I have done two pics, one with 200mm/s travel speed, another with 25mm/s. The feedrate was 25mm/s for both pics. Engraving time was 5:01 and 22:40. Can you see the difference?

    1 user thanked author for this post.
    #92247

    Ryan
    Keymaster

    Victor you are using Marlin? With the tweak we are doing pretty good with M106/7 now.

    #92281

    Victor
    Participant

    Victor you are using Marlin? With the tweak we are doing pretty good with M106/7 now.

    yes, I am using Marlin 1.1.9
    but in this version marlin.cpp does not exist, so I am not able to try it out.

    If I understand it right, you can go over 25 mm/s without stuttering? Which resolution do you use?

    #93475

    IamSandX
    Participant

    Ok. Here are a few tests I have done with the same images. The far left image, where it looks like something was started was done at .2 resolution at a FR of 20mm and TS of 20mm. I seriously cannot get a usable image at all at .2 resolution. Maybe I’m misunderstanding something. The .12 resolution looks ok. The bottom 2 tests are run at the same settings. The wood I’m using is birch I believe. I got them from Hobby Lobby.

    #93495

    Kelly D
    Participant

    The .12 looks pretty good to me but I’m not 100% sure what I should be looking at/for. It could just be the wood. Did you try on cereal box cardboard? Did you sand the wood before burning?

    #93648

    IamSandX
    Participant

    Really I’m wondering if I’m misunderstanding something. At .2 resolution I can’t even make out a picture at all, it just looks like some random burn mark’s. Are you guys bumping .02 resolution at a time, from .1, or actually going .1 to .2 to .3 resolution? ?

Viewing 30 posts - 241 through 270 (of 283 total)

You must be logged in to reply to this topic.