Need some help? Check out our new Help Centre

Laser speed slows down mid-project

I've been having this problem randomly and it seems that the project doesn't affect this problem at all.
The problem is that I've set the laser to engrave at a certain speed and it works fine, until suddenly mid-session, the speed drops, instantly and stays at that lower speed, until the project is finished. What happens is the slower speed makes the engraving darker and it's very visible.

I'm using PicEngrave Pro and PicSender (latest versions) and I'll include screenshots of them as well as examples of projects that a this happened to.

Note: I've tried several different projects, artworks, speed settings, with or without the feedrate change.

What makes this a bit strange to me is that I may be running one gcode file fine a few times and then randomly, this problem occurs with no change in anything really.

Photos will be in a comment below because I can't post pictures from my laptop but works fine from my phone.


  • Can you please email me a .nc file where this is occurring so we can run a test in-house to try and simulate this.
    Send it to

    Also, is your machine doing anything other that streaming the file to the Emblaser?
    Could a process be starting to cause this to happen on your computer?

  • I'm heading out right now and I'll send you the file when I'm back. I'm running WinXP on a fairly powerful mac (although from 2008 but still pretty good) that I upgraded to SSD.

    I'm using Parallels (latest version) so it's running while the OS X is running. I do have some apps that aren't doing anything but they could affect which I didn't realise until you mentioned it.

    I'm gonna run this one more time with nothing running on the computer except Parallels and see what happens.

    Thanks for the quick response!
  • edited March 2015
    Please try with the 'Use Feed Rate Change' check box unselected in the settings for PicEngrave Pro. It is possible that there is an issue with Parallels where it or OS X stops responding to the feed rate change commands that this function adds to each line of gcode. The intent of this function is to improve the shading contrast of gray scale image engraving. With the type of images and material surfaces that I have observed you appear to be using, it should not be needed.

    Also, please zip a problematic gcode file and send it to me or Jeff Woodcock so we can test it on one of our Emblasers.
  • I will do that and I'll experiment a bit further. The problem isn't the gcode file as this happens randomly with anything I export. The problem seems to be with PicSender. I suspect the computer somehow affecting PicSender, rather than the app itself causing this.

    I will end up having a dedicated windows computer for the laser but I can't at the moment.
  • When the problem occurs, have you noticed whether or not PicSender is displaying a red error message at screen bottom?
  • I haven't seen any errors. It continues and finishes off the project at the lowered (but steady) speed. The examples above where it didn't finish,I just stopped it when I saw the darker engraving
  • Thanks. Please also send us one of the original images you are engraving so we can test with it.
  • I'm doing a test right now with a similar Dithered image and using a 160IPM (4064mm/min) feedrate and a 40% Feed Rate Change with a .006" (1524mm) Pixel Resolution at 45D angle. So far so good.

    It's flying through the white areas and slows when pulsing the black areas.

    I wanted to push it to a higher extreme for this test. I will post my results when it's finished.
  • Thanks for that! One thing to note is that with the speed lowering, the feedrate is still happening, it's just the overall speed of the project that goes down.
  • I ran the gcode file generated from the dithered image twice, one right after the other without any issues. The second pass did get darker from burning again, but did not slow down anywhere to cause any out of the ordinary darker burnt area.

    The dithering algorithm I used was Atkinson @ .125 Error Correction and I'm using XP Pro OS.


    I'm not sure why your having this issue. I do use a slightly different grbl settings then stock, but not sure if that would cause any difference.

    $0=10 (step pulse, usec)
    $1=255 (step idle delay, msec)
    $2=0 (step port invert mask:00000000)
    $3=2 (dir port invert mask:00000010)
    $4=0 (step enable invert, bool)
    $5=0 (limit pins invert, bool)
    $6=0 (probe pin invert, bool)
    $10=3 (status report mask:00000011)
    $11=0.005 (junction deviation, mm)
    $12=0.002 (arc tolerance, mm)
    $13=1 (report inches, bool)
    $14=1 (auto start, bool)
    $20=0 (soft limits, bool)
    $21=0 (hard limits, bool)
    $22=1 (homing cycle, bool)
    $23=0 (homing dir invert mask:00000000)
    $24=25.000 (homing feed, mm/min)
    $25=2000.000 (homing seek, mm/min)
    $26=250 (homing debounce, msec)
    $27=1.000 (homing pull-off, mm)
    $100=200.000 (x, step/mm)
    $101=200.000 (y, step/mm)
    $102=200.000 (z, step/mm)
    $110=10000.000 (x max rate, mm/min)
    $111=10000.000 (y max rate, mm/min)
    $112=10000.000 (z max rate, mm/min)
    $120=10000.000 (x accel, mm/sec^2)
    $121=10000.000 (y accel, mm/sec^2)
    $122=10000.000 (z accel, mm/sec^2)
    $130=400.000 (x max travel, mm)
    $131=280.000 (y max travel, mm)
    $132=10.000 (z max travel, mm)
  • I suspect it may have something to do with Parallels. I'm gonna restart the computer, have nothing running except for Parallels and see what happens.

    I appreciate your help and I'll report back with results!
  • image

    Here's one that came out great!
Sign In or Register to comment.