New user problem with Pause then Resume

The software is fantastic so I purchased the GRBL license. After purchasing the license I have found an issue that I did not have with the trial version.
If I’m running a job and need to step away from the laser, I hit pause. With the trial version of the software, when I return and press resume, the laser turns on and the job continues from where it paused. With the activated license, when I press resume, the laser head advances back and forth about 10 times, then the laser turns on. This leaves a gap in the image where the head travelled forward without the laser burning. Are there different settings in the trial version and the licensed version? What have I done wrong? Any help would be appreciated.

There is absolutely no difference between the licensed and trial versions. Did you change anything in your setup? Are you using the GRBL device, or GRBL-M3?

This is actually kind of hideously complicated to do properly in software, for a few different reasons:

  1. LightBurn doesn’t track the current state of the GRBL device (or other device) while sending GCode, so when you pause, I don’t actually know if the beam is currently on or off

  2. LightBurn sends a decent amount of GCode ahead of where you actually are when streaming, because the controller needs a bunch of data in the buffer so it can plan properly and maintain speed. This means even if I did track when I tell the laser to turn off or on, the actual laser wouldn’t necessarily be in that state.

  3. The only way to deal with #2 is to pause by letting GRBL process all moves in the buffer, at which point the state I think it’s in will be the state it’s actually in, and then if I needed to turn off the beam I could do that. If you are running a job with lots of long straight lines, this could take seconds to even minutes before an actual pause happens. GRBL-LPC, for example, has over 200 commands in the buffer ahead of the current move. Regular GRBL is about 20, plus another 10 or so in the serial queue.

The easy answer is to use a recent version of GRBL (1.1f or higher), with laser mode enabled ($32=1), and variable power (the M4 command, used by the GRBL device profile in LightBurn). The Ortur should be detected as GRBL, not GRBL-M3. If it’s using GRBL-M3, you should change that to GRBL by clicking the ‘Devices’ button, then double-clicking on the device in the list, and changing it.

When using the GRBL driver in LightBurn, you’re automatically using the M4 (variable power) mode in GRBL, and that means if the laser stops moving, it also stops outputting, and this is all handled automatically by the controller itself.

I have an Ortur lm2-4.

Ps. I don’t think I changed anything.

I’m not sure what the difference is between the two you mention

Thank you for the response. I will check what you said to look at.

I’ve checked my settings and they are as you have indicated. As some of my images do have “long” straight lines, would it be possible to make your reason #3 an option? After pressing pause, the image would continue until the buffer is empty, then the head stops moving and in turn the laser shuts off. As it is right now, the pause function doesn’t work well for me.
Has no one else mentioned the skipping caused by the current programming of the pause function? Just curious. Thank you.

If your laser is in laser mode, the beam should turn off automatically when the laser is paused, and back on when it resumes. Are you using GRBL-M3 mode in LightBurn, by chance?

No I’m using GRBL. As mentioned above, when I press pause everything stops as it should. It’s when I hit resume the laser head resumes its path but the laser itself doesn’t start burning until after approx ten sweeps. So I guess that’s when the buffer refills with new information

No, that’s not the buffer, but it could be the next time the software emits a “laser on” command. What does your design look like?

I was etching a slate tile, paused the job, then resumed. That’s when it skipped several lines. I had to restart and that’s why the lower part of the C looks different than the upper part. Then I decided to do some tests. The stripes are actually a shaded rectangle which was paused three different times. Also the word test was paused twice and you can see a much smaller skip.

Another test of the same logo but on wood

I’ll check this with my own hardware and see if I can figure out what’s happening. With the generic GRBL driver, it shouldn’t be issuing commands to turn off the beam, just pausing, letting the controller turn off the beam for you.

Thank you for your time and effort. The weird part of this is that it did not appear to be happening with the trial version of the software.

Nothing has changed in this regard, so it’s possible you just happened to stop it between cuts, where the software was about to turn on the laser again anyway. I’ve had a brief look at the code and I’m always sending the “laser off” command, even if you’re in variable power mode. I’ll come up with a better approach and try to have that ready for the next release.

Do you mean you’re sending the laser on rather than laser off command? I like to think that I have a fairly logical mind, in fact years ago I used to work as a programmer. So I’m having a hard time wrapping my head around why the pause command’s effect is virtually instantaneous. Motion stops, laser turns off. If you can supersede the buffered commands to shut down motion and burn, why can’t the resume command supersede the buffered commands and restart the burn as soon as motion is restored. Sorry to be a pain in the neck. Just trying to understand.

With GRBL, there is an “instant pause” command, and I am sending that. I’m also sending the “laser off” command, which won’t even get processed right away, because it’s queued behind the other GCode waiting in the buffer, and that’s the problem - I shouldn’t be doing the second part if you’re in M4 (variable power) mode, because the instant pause will take care of that.

If you aren’t using variable power mode, I don’t send the instant pause, because it leaves the laser on, so I send the laser off command and wait for the buffer to empty, but then I don’t know what state the laser was actually in before, so I don’t know if I need to turn it on again or not. I’m going to work on fixing both.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.