I’m going to do a test real quick to see if the rotary changes speeds with pure B movements vs B/Y movements combined.
That’s an interesting output. Setting the speed at 3000mm/min. B movements are at F3000, but Y movements are F3437.75, using a 50mm square for independent, also spacing is funky.
G1 B-57.296
G1 Y50F3437.75
G1 B57.296F3000
G1 Y-50F3437.75
But together movements (rotated the box 45 degrees for a diamond) makes the feed F2121.32
G1 B-40.514 Y35.355F2121.32
G1 B40.514 Y35.356
G1 B40.514 Y-35.356
G1 B-40.514 Y-35.355
A small video of my test shows the rotary doesn’t really change speeds when Y is moving, it might slow down a tiny bit due to voltage drop of 1 vs 3 steppers, but nothing significant. So assuming Y is actually moving the F3000 set, and end results are accurate, then yes, the firmware is varying the B speed accordingly to the diameter of the object to match the given mm/min speed in the gcode.
Edit: Since their own software outputs like the older test version of Lightburn, I would say stay with that. What exactly got changed in this latest version? What was wrong on the backend?
We already had code that would scale the feedrate for rotary only moves when the rotary is in degrees. But… it was only doing this if the rotary was the A axis. So I made it do it for B axis when it’s a SnapMaker device.
…When was that implemented? I’ve always used A axis for my rotary with Lightburn as a GRBL machine, and I’ve never seen the feedrate change. Even in my guide found here; Lightburn + Rotary Guide - Snapmaker 2.0 - Snapmaker: where creation happens
I have a screenshot showing that A axis should be used, and from a saved project the speed is not modified for A axis movements (note that I’ve swapped A for B as according to my guide) Bbsolute coords 
This was of course with 1.3.01, as I have none saved from 1.4.
; LightBurn 1.3.01
; GRBL-M3 (1.1e or eBrlier) device profile, Bbsolute coords
; Bounds: Y0.02 Y-26.12 to Y74.91 Y26.12
;USER STBRT SCRIPT
M106 P0 S255
G28
G90
G53
G0 Z112.3 F6000
G54
G92 Z0
G53
G0 Z330
G0 X166 Y246.8 F6000
G54
G92 X0 Y95.5
M3 S0
;USER STBRT SCRIPT
G00 G17 G40 G21 G54
G90
; ScBn @ 1999.998 mm/min, 80% power
M9
M5
G0 Y0.139B-3.409
G0 Z41.3
; LByer C00
G91
M3
G1 B-1.156F2000S0 < Still F2000
G1 B-0.4S204
G1 B-1.48S0
G1 B-0.309S204
G1 B-1.156S0
Unless it was a planned change that wasn’t implemented yet?
EDIT: Aha! Opened up my other install which is still 1.4.0 and it was implemented then. My bad.
@Skreelink why do you think the max speed of rotary is a static value? From my point of view it is depending of the diameter of the object. If I would do a 45° rotation in one second on a 50mm object and the same with a 100mm object the speed is also double in regards of the longer way. So I would say you have to check/calculate the max speed for rotary (mm/min) for each diameter seperatly. With the simple formular d x pi x 7,5 it should fit for Artisan with 45°/sec.
I was basing the math off an object with a circumference of 360mm. So an object with a circumference of 360mm makes degrees == mm in distance across the curved surface. One degree turned is one mm of distance. So 45 deg/s is 45mm/s is 2700mm/min. I remembered wrong, go me. 
but I was close. That’s the max theoretical speed of the rotary in the simplest terms I can break them down. I could of course be very wrong, so take it with a grain of salt. All of this speed stuff is still technically not relevant to the above and I think we’ve gone a bit far on tangent about it. There’s a lot of math involved in making rotational speed into linear surface speed and my brain is currently mush.
EDIT: Putting in a circumference into lightburn of 360 makes it fully linear;
50x50mm square.
; Cut @ 3000 mm/min, 20% power
M107
M05
G0 B25 Y0 F3000
; Layer C00
M03 P20 S51
G1 B-50
G1 Y50
G1 B50
G1 Y-50
M107
M05
G90
And with the new math in place, halfing to 180;
; Cut @ 3000 mm/min, 20% power
M107
M05
G0 B50 Y0 F3000
; Layer C00
M03 P20 S51
G1 B-100
G1 Y50F6000
G1 B100F3000
G1 Y-50F6000
M107
M05
G90
@adammhaile
It doubled the Y value instead of B, so I assume that’s just the same Y/B swap from earlier that required the 90 degree rotation. It still comes down to if the math needs to be done in the software, or if the firmware of the machine is doing it for us. This I do not know currently.
@adammhaile now I found out when the laser is switching on after job finishing. It happens when I open and close the door. If I close it, after opening, the laser switched on. Maybe is really an issue from a newer firmware and I will check this also with Luban. One additional question. What does the second nummber in brakets mean? (see picture below)
I have also reported the issue with swichting on the laser to the Luban/ Artisan Firmware team to double check and find the root course. In the meanwhile I will check your latest LB version to see if there is a difference. I do it with exactly the same laser test as with the version before Let’s see what the outcome will be. I will keep you informed.
@adammhaile @Obicom Confirmed the snapmaker rotary is working deg/min, so the proper conversion for surface speed needs to be done in the software. I did a simple motion test;
G1 F1440
G1 Y0.00 B360
Assuming an F360 feedrate would take 1 minute to turn, I multiplied it by 4 to get F1440 to make it take 15 second. It took exactly 15 seconds. Halfing the movement to B180 took 7.5 seconds to move. I also changed the diameter in the machine from 114.6 (roughly 360mm circumference) to 1, and to 360. The machine did not change speed, still the same. I changed the speed from F1440 to F720 with B180, and it took 15 seconds as well.
So in conclusion, the snapmaker does NOT do any form of speed variation it seems, it only seems to use the diameter you put in (if running from the machine) for a starting point for origin. It also doesn’t interpolate any speed from the gcode. Simply turns the F rate into deg/min. I wonder if that means in Y/B moves, it actually slows Y down. 
So the actual surface speed changes depending on the circumference and has to be accounted for in software. Maybe my testing methods are wack. 
Just don’t listen to me 
EDIT: I have some HVAC guys here right now, so I’ll do some more tests and see if 2700deg/min is the actual top speed of the rotary. The fact the machine seems to run in deg/min though means it’ll never be able to really reach upper level engraving speeds (thus using a scan angle of 90 degrees would be preferred since Y can reach those speeds).
Just checking, are you saying something is still wrong? Wasn’t clear.
Total estimated job time.
Yes, the gcode it output on just Y or B movements doubled the Y movement when halfing the diameter of the object. I would assume it would double the B feedrate, since that’s the surface distance that actually changed.
Also finished the test. I was seeing how faster I could get the rotary to top out in rotational speed. It seems I was correct at 2700 deg/min. Meaning the rotary will not go any faster than a feedrate of F2700.
The file I created to test was this;
G91
G0 F3000
G1 B360 F1440
G1 B360 F2700
G1 B360 F3000
G1 B360 F4000
G1 B360 F6000
G1 B360 F9000
G90
Meaning it would do one rotation at F1440, then speedup to the theoretical ‘max’ of F2700, then 3k, and so forth. There’s a slight pitch variation from 2700 to 3000, but no perceivable speed difference, then nothing for all the subsequent turns, as it’s met it’s maximum speed.
I’ll have to talk to Oz… I just copied the code he did for A axis on other machines and would assume it’s correct.
@adammhaile your latest update is a little bit slower then the one before.
First try: 1h:33min , second try 1h:36min
See the outcome in the pictures below:
First test:
Second test (latest update from today):
You can also see that on both speed and power is chaning … not all the same speed
Power: 2%-15%
Speed: 500-950 mm/min (littel bit less then the max speed for 43mm diameter)
@adammhaile In my view, the last version is the best so far.
@adammhaile I did today a new check due to the “auto switch laser on” issue.
I tried the same workflow with Luban and the laser switched NOT on, after opening and closing the door of the enclosure. Therefore I gues it is LightBurn related. Maybe you support team could try to reproduce the issue with the Artisan on site.
@Obicom I still need this from you. We’ve not be able to reproduce it. So I need to see what luban is doing different.
I will do that for you but please consider … it happens after the job is done … if I open and close the door … therfore I ould guess has nothing to do with the g-code. The Artisan sent an information via the console if I open and close the door and I would guess that Lightburn reacts on this information. The 50mm squere should be on 3 or 4 axis mode (with or without rotary?)
Here the g-code for you @adammhaile
Luban_Gcode_50mm_squere_with Rotary.txt (10.8 KB)
Lightburn_Gcode_50mm_squere_with Rotary.txt (462 Bytes)
Here also the console output. After zhe 0:21 job (done) I opend the door, then closed and laser switched on. On the end I swichted of the laser manully.
I guess in this section the problem should be:
Stream fertiggestellt in 0:21
Enclosure door open
Enclosure door open process
job client: can not pause a job as current status is no printing, sys_sta: 0
Enclosure door close
unsubscript cmd[1:a2]!
cannot found match client for unsubscribe [1:a2]
subscribe cmd[12:a1], period[1000]!
subscribe success!
Auf Verbindung warten...
Port failed to open - already in use?
Auf Verbindung warten...
��ok
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
Enclosure door open
Enclosure door open process
job client: can not pause a job as current status is no printing, sys_sta: 0
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
sys_staus: 0, z_drop_limit_check: 0, z_probe_enabled: 0, state: 0
ok
Enclosure door close
set origin, len[4]
X:0.000 Y:20.000 Z:-16.188 A:0.000 B:0.000 E:0.000 Count X:16320 Y:13280 Z:46561 A:0 B:0
ok
X:0.000 Y:0.000 Z:-16.188 A:0.000 B:0.000 E:0.000 Count X:16320 Y:13280 Z:46561 A:0 B:0
ok
X:0.000 Y:0.000 Z:0.000 A:0.000 B:0.000 E:0.000 Count X:16320 Y:13280 Z:46561 A:0 B:0
ok
X:0.000 Y:0.000 Z:0.000 A:0.000 B:0.000 E:0.000 Count X:16320 Y:13280 Z:46561 A:0 B:0
ok
echo:Settings Stored (1856 bytes; crc 21079)
ok
X:0.000 Y:0.000 Z:0.000 A:0.000 B:0.000 E:0.000 Count X:16320 Y:13280 Z:46561 A:0 B:0
ok
Stream wird gestartet
Layer C00
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
echo:busy: processing
Stream fertiggestellt in 0:21
Enclosure door open
Enclosure door open process
job client: can not pause a job as current status is no printing, sys_sta: 0
Enclosure door close
unsubscript cmd[1:a2]!
cannot found match client for unsubscribe [1:a2]
subscribe cmd[12:a1], period[1000]!
subscribe success!
set laser power[0]
set laser power[0]
subscribe cmd[12:a1], period[1000]!
same client has registered same node with same period!
hmi set active coordinate[1]
ok
subscribe cmd[1:a2], period[1000]!
same client has registered same node with same period!
Are you actually sending the job to the device via LightBurn? As in LightBurn is actively controlling the machine. Or are you saving the file to an SD card or something. If you are controlling with LightBurn can you can a capture of the console in LB when it happens?
LightBurn has never reacted to any device door state information. I’m sorry to say that while I don’t know why it’s happening, I still don’t believe that it’s LightBurn causing the problem. It’s entirely possible that the different gcode we send is what’s technically the problem, but if it IS the problem then it’s the firmware reacting incorrectly to it. I’ve gone over all of the gcode we are outputting and none of it should cause the laser to turn back on.