Lightburn Setting G0 Feedrate to 0

LightBurn Hardware Compatibility Marlin
1

Hi, I’m having an issue where Lightburn sets my G0 feedrate to 0 during travel moves.

; LightBurn 1.2.01
; Marlin device profile, current position
; Bounds: X0 Y0 to X90.91 Y78.99

;USER START SCRIPT
G21
M203 X100 Y100
; units mm
; set max feedrate 100mm/s
;USER START SCRIPT

G21
G91
; Cut @ 4 mm/sec, 100% power
M8
M05
G0 X44.023 Y36.859 F0    <-- right here
; Layer Speed 20 mm/s Pass 1 of 2
G1 X-0.248 Y0.15 F240 I S255
G1 X-0.231 Y0.173
G1 X-0.213 Y0.194
...

Surprisingly, my machine (MPCNC running Marlin) still executes the travel move (I would’ve expected the end effector to stay stationary given a feedrate of 0), but the travel move happens painfully slowly.

Adjusting the value in Edit > Device settings > Rapid Speed has no effect on the generated Gcode!
How can I force G0 commands to use a faster feedrate?

2

Ok since there is no obvious fix for this issue, I wrote a quick and dirty Python postprocessor:

# ------------------------------------------------------------------------------
# Fix Lightburn Gcode Post
#
# Authors: Markos       Date: 2022-12-08
#
# ------------------------------------------------------------------------------
#
# Change all the G0 F0 to more reasonable feedrate
#
# ------------------------------------------------------------------------------

import os
import sys

# Sanity
os.system('cls' if os.name == 'nt' else 'clear')
print("Start program!")
working = os.getcwd()
print("Directory: \t\t\t", end="")
print(working)

# Identify the file in the directy we want to fix
for file in os.listdir(working):
    if file.endswith(".gcode"):
        postThis = os.path.join(working, file)
        print("File to Process: \t", end="")
        print(postThis)

# Read input data from the gcode
with open(postThis) as f:
    lines = f.readlines()
    f.close()

print("Gcode length: \t\t%s" % len(lines))

# Creat output file, open in append mode
outFile = "outPut.txt"
f2 = open(outFile, 'a')
print("Filename: \t\t\t" + outFile)

# Start parsing the gcode and output the corrected lines
subString = "G0"

for i in range(0, len(lines)):

    fullString = lines[i]
    
    if subString in fullString:
        
        # Replace all the F0 with F60, 60mm/s
        repairedLine = lines[i].replace("F0", "F3600")
        f2.write(repairedLine)
        # print(repairedLine, end="")

    else:
        
        f2.write(lines[i])
        # print("Not found!")
        
    # print(lines[i], end="")

# End program
print("Success!")

I will probably re-do this post processor soon to make it more convenient to use, and I will post the updated code here when it is done.

3

Thanks for the code. I think they don’t much care about us Marlin folks since the Marlin mode does not generate G code that matches what is specified at: Linear Move | Marlin Firmware

1 Like
4

Just signed up to the forum to ask about this and your post was top of the list in the Marlin section. Thanks for the script.

1 Like
5

Alright np. It’s a shame this doesn’t have an official fix yet. I will update the script soon to make it less awful - I really just threw this script together and it’s a bit of an abomination but it does work lol

6

This is intriguing. I’ve asked the team internally. I suspect F0 is used as a shorthand to point at the maximum speed for traverse moves from where it appears in the Config file. I dug for a little bit on the Marlin Git but I struck out.

Which Marlin Build number are you running? Is it a specific MPCNC config?

1 Like
7

The ‘Fast Whitespace’ setting will be used for the G0 Rate in LightBurn.

This may be worth review:

2 Likes
8

Hi JohnJohn,
In response to your previous comment, my MPCNC is running Marlin 2.0.7.2, but it is a V1 Engineering custom configuration.

Thank you for linking ReaHe’s question about the Laser Jog Settings! This did the trick for me!

It is very unintuitive, however, that lightburn uses the “Fast Whitespace Scan” value for controlling G0 rapid moves during cutting operations. From the name of the setting, I would assume that it only controls traverse movements during raster image engraving or something. It might be worth considering renaming that setting, or creating a separate setting that can override it for rapid movements during cutting operations or smth

9

Not that it’s directly relevant for this Topic but I suspect this is a Marlin only thing. Can you confirm this doesn’t do this for GRBL machines?

10

Yes, this is a very specific quirk for Marlin.
I’m still attempting to tease the naming and the reasoning for it out of the Marlin spec.

1 Like
11

IIRC, Marlin is unique among G-Code interpreters, because it uses the same feedrate for G0 as G1 and implements them identically.

Other CNC implementations define G0 to move as fast as possible without regard to the feedrate used by G1, as in the LinuxCNC definition of G0:

This will produce coordinated motion to the destination point at the maximum rapid rate

So, for Marlin, you must force a feedrate that makes G0 go lickety-split, because otherwise it will trudge along at whatever rate you just used for G1. Having G0 use a feedrate you know is faster than anything else seems reasonable.

IMO, it’s just another reason why Marlin is a weak choice for anything other than a 3D printer controller.

1 Like
12

Can confirm this is how Marlin works.

Feedrates change a lot in 3D printing. Slicers recognise lots of different extrusion moves and you can generally customise the feedrate for all of them. (e.g. inner walls, outer walls, infill, bridges, tops and bottoms of things.)

Features like retraction/reversal before/after travel moves will also have a feedrate defined (acceptable retraction feedrates can be material-dependent). Z-hopping (G0 move) can also be combined with retraction for travel moves, and you generally don’t hop at the same speed you’d move the x and y axes.

I suspect they just decided to keep it simple and only keep the most recent feedrate in memory, on the basis the slicer can do the heavy lifting of keeping track of and defining what feedrate is required as and when. It would also save a tiny amount of space in memory, could make a difference on low-end hardware maybe?

1 Like
13

They start with a tiny amount of memory: the ATmega 328 microcontroller has 2 kB of RAM and 32 kB of Flash for the program. The RAM must hold all the variables, plus stack and heap space, plus a few other odds & ends.

The fact that essentially all cheap 3D printers / laser cutters / CNC machines use a '328 controller stands as a testament to human ingenuity …

1 Like
14

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