GRBL profile slow (G0 non-cut) transverse moves

GRBL

  • [VER:1.1h.20221101:]
  • [OPT:VZHD0LI,254,255]

The firmware is surely an Atomstack clone.
Tests carried out with 2 squares spaced X and Y apart with 0 power:

  1. CanCam profile - fast move

  2. GRBL-M3 profile - fast move

  3. GRBL profile:
    A. Line fill - fast move
    B. Offset fill - slow move
    C. Cut ------ very slow move
    If I edit the GCODE and put an M5 on the line before the G0 it works fine.
    Adding a pause works fine.

I tested it with version 1.3.01, 1.2.04, 1.1.04, 0.9.24. version 1.7Beta the same.

Is there any way for Lightburn to put M5 before the moves?

TIA


Rectangulos_teste__GRBL.gc (333 Bytes)
Rectangulos_teste__GRBL.lbrn2 (3.1 KB)

When in GRBL controller - have you changed the white space setting on Edit > device settings?

your speed is 100mm/sec so… rapids should be at or faster, depending on firmware/and settings.

Confused on why you getting such behaviour. There should be zero need to M5 it

Thank you. I haven’t changed any settings. I’ve already contacted the seller(maybe a faulty firmware or hardware) but in the meantime I found out that the GRBL G0 needed an M5 first to be really “fast”. The line fill only has G1 so it’s “fast”.
And I found a solution that works and that may be the solution for many machines with slow G0, I created a GRBL “Custom GCODE profile”, unchecked “Tool State Automatic” changed the buffer to 254 and it works except the return to zero .In CUSTOM GCODE there are a number of settings that I haven’t checked yet. I’ll check this later tonight

Solution_1
Solution_2
Solution_3
Solution_4



Solution_7

Edit: Lightburn 1.7.00 full window 1920x1080
I removed it as a solution because I did some more tests and everything is fast in direction 1position_1

but in direction 2 position_2
the Line-Fill mode and the image are slow.
Giving priority to shapes because with the optimization settings even if I put the laser where I wanted the program always went to the other end (bug?), happened once and then I couldn’t replicate the shapes lost priority when I changed from line to fill. I think the coordinates of the images started a little bit before the right position, but I’ll have to check.
I think my board/firmware doesn’t like G0 commands…

I also think that there is a misalignment in the boxes and the program usually has everything well aligned.
buggy

For now, I’ve found a 2-step solution:

  1. Using the GRBL-M3 profile, save the GCODE
  2. Edit in Notepad++ and change the M3 to M4 so as not to lose the dynamic mode and then Run GCode.

It always works well in all directions with Line-cut, Line-fill, Offset-fill, images, I’m going to try with CUSTOM GCODE to create a custom GRBL-M3 profile but with M4, the one I created didn’t work but I haven’t looked at all the options yet.