Interesting, but I do not think the Move window Speed field is factored into the processing of the output program. I just did a simple test and could not duplicate your finding.
I suspect you changed something else, maybe accidentally. Can you upload two copies of your Lightburn file, one each with the Move settings you describe?
Iāve been wrestling with this issue since last year, it does seem really odd and I agree that the move speed shouldnāt affect the job speed, but it does work for my situation.
here is a copy of my post from Nov. of last year in the Snapmaker Forum:
I changed the power on all layers to 1% for testing purposes, left the speed settings the same as in the original project. Ran the job with only one object of the array selected, ran fine in 7min, 18sec.
Went to run it exactly the same after the first one finished. Didnāt change a single thing, same object, just clicked Start and it took 18 min. to run, this would have seriously over burned the job.
Here is the start and end of the Gcode from both runs, Good and Bad:
GOOD:
Initial run, Get Position, Set Origin, click Start:
Waiting for connectionā¦
ok
X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:11280 Y:9560 Z:32580 B:0
ok
X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:11280 Y:9560 Z:32580 B:0
ok
Project loaded in 75 milliseconds
Starting stream
M106 P0 S255
M3 S0
G21
G90
M8
M05
G0 X247.74 Y9.341 F3000
G0 Z0
Layer #2
G91
G1 X0.042 I S2.5
G1 X-0.083Y0.1 I S0
G1 X-0.072 I S2.5
G1 X-0.081Y0.1 I S0
set air pump switch: open
G1 X0.075 I S2.5
G1 X-0.048Y0.1 I S0
G1 X-0.088 I S2.5
G1 X-0.042Y0.1 I S0
.
.
.
M05
G0 X232.687 Y71.709 F3000
G1 X232.552 Y72.063F900 I S2.5
G1 X232.249 Y72.724
G1 X231.864 Y73.341
.
.
.
G1 X232.792 Y71.761
G1 X232.717 Y71.71
G1 X232.687
M9
M05
G90
M5
G0 Z330 F6000
set air pump switch: close
Stream completed in 7:18
close Laser control
BAD:
Subsequent run, same object, just clicked Start
Starting stream
M106 P0 S255
M3 S0
G21
G90
M8
M05
G0 X247.74 Y9.341 F3000
G0 Z0
Layer #2
G91
G1 X0.042 I S2.5
G1 X-0.083Y0.1 I S0
G1 X-0.072 I S2.5
.
.
.
M05
G0 X232.687 Y71.709 F3000
G1 X232.552 Y72.063F900 I S2.5
G1 X232.249 Y72.724
G1 X231.864 Y73.341
.
.
.
G1 X232.792 Y71.761
G1 X232.717 Y71.71
G1 X232.687
M9
M05
G90
M5
G0 Z330 F6000
set air pump switch: close
Stream completed in 18:00
close Laser control
The reason is; G0 and G1 store speeds separately. By the snippets you posted, it looks like you have an engrave and a cut layer with different speeds. It also looks like youāre using āMarlinā as the code base.
Initially, G0 speed is set to F3000 before it says layer #2
G0 X247.74 Y9.341 F3000
However, thereās no speed setting F line on the first G1,
G1 X0.042 I S2.5
This tells me your first engrave is set to F3000, so lightburn assumes (since your whitespace scan is also F3000) that itās going to keep that speed, so it doesnāt put one on the G1 line.
So when it swaps to the cut layer, we see it sets a speed of F900 on G1 (I assume itās a new cut layer or slower engrave as it follows an M05
M05
G0 X232.687 Y71.709 F3000
G1 X232.552 Y72.063F900 I S2.5
So now your speeds are set; G0 = F3000 G1 = F900
So subsequent runs, since thereās no other G1 speed changes, keeps that speed. So now your original engrave is running at the speed of the cut section. Also this would explain why framing might have a change as well; if framing uses G1 itāll set G1 to your move tab speed, but then itās never updated in the program from the explanation above.
You can maybe mitigate this by using a whitespace scan of say, F2999, so your engrave speed of F3000 is different, Lightburn will be forced to put in a new speed change. Just make sure theyāre different, and Lightburn will plop a proper F change on your G1.
@Colin Maybe give this a read through and see about forwarding the idea of outputting F# to the first G1 move regardless of if the speeds match moving forward?
The 2.0 and Artisan are running Marlin, whereas the Ray is running GRBL. However, they must have taken points from my old guides and made their profiles as GRBL since it works fine (except the GRBL specific commands naturally)
Despite being Marlin, Iāve always used GRBL as the device in Lightburn for my 2.0. Itās also how Iāve stated to setup the machine in my guides as well.
In that case, Iām curious to know why the āSnapMaker (Marlin)ā device type would not be the first choice for running these (non-GRBL) Snapmaker devices?
Put another way, why is the GRBL control still preferable for you even though many of the buttons in LightBurn will not interact as expected?..presumably this would include get/set position, user origin etc. and what you noted in your post.
In that post you also mentioned the inline power function, which is availableā¦ but Iām just not sure if anybody is actively using it with the SnapMaker (Marlin) device. If there are any issues then it would be great to overcome them and consolidate the āSnapMaker (Marlin)ā as the recommended device to use for the (non-GRBL) Snapmaker. Appreciate your input!
Thanks for this detail, it looks like the feed rate on the G1 could indeed be getting carried from the previous cut layer, even though the G0 had changed the feedrate, so Iāve raised a question with the dev team. TBH I didnāt realise G1 and G0 could have individually-carried feeds, must be a Marlin thing.
G0should run at the machineās maximum possible speed, without any reference to the G1 feedrate, but early on Marlin used the same code for both commands. This was due to running in an ATMega 328 with a whopping 32 kB of code space, but AFAICT theyāre now stuck with it, because backwards compatibility.
The LinuxCNC doc explains how those commands should work:
Back in the day, G0 did not produce ācoordinatedā motion and could proceed at the maximum speeds of the individual axes without maintaining a straight line, but that could produce surprising results on a CNC machine with clamps & vises holding an irregular object to the table.
I donāt know about others, such as Snapmaker themselves, but I use it because;
1: It works fine, why change and break what works for me.
2: Generates leaner code, saves a little on size and thus speed by trimming unused I indicators and such.
2b: Also doesnāt generate a thumbnail, which seems to break the serial connection (though I donāt use USB)
3: I donāt use any of the button functions, so the macros being wrong doesnāt affect me at all. I have a full repeatable origin setup so I donāt worry about having to move and set origins, etc. Any movement I need I can do via console. (Power user syndrome? )
I use it all the time, but since itās a standard in GRBL, I hardly think about actively switching it as seen in your screenshot. I recently did a depth engrave with an A250T 10W + grayscale inline.
Is a Marlin thing. Normally G0 is just rapid machine max on a CNC platform, but in Marlin, it can be set differently, which can be a good thing, or a bad thing as seen above.
)
