@adammhaile Hello Adam, unfortunately I didn’t saved the code and switch off my machine after the testin. I created the same file again and hope it is reproducable for you. Attached the gcode. (hope you can find the issue) I am not allowed to upload g-code files. Therfore I rnamed it to txt. Please change the file type to “.gc” I find the M05 command on the end of the gcode and this should switch off the laser off. Could it be that lightburn (not from gcode) switch the laser on again?
Lightburn Test.txt (3.7 KB)
I’m not sure. Looking into it.
1 Like
Can you share a screenshot of your device settings? I see a few small discrepancies in the gcode. Particularly with your power settings. The start of your code says this;
; Cut @ 6000 mm/min, 20% power
However, the gcode is setting S200 which would be proper for GRBL’s default S-value of 1000. Snapmaker needs an S-value of 255.
M03 P20 S200
Also, there is a Z movement right before it begins the first cut;
G0 Z10
; Layer C00
This usually will only be here if you have enabled Z axis on (and set a material height). Either disable Z-axis, or enable relative Z moves only.
EDIT: I am unable to replicate it in Lightburn doing it without inputting a material height manually. If I leave material height at 0, it doesn’t put the line in.
; Cut @ 10000 mm/min, 100% power
M107
M05
G0 B40.926 Y0 F3000
; Layer C00
However, setting a material height, it inputs as normal.
; Cut @ 10000 mm/min, 100% power
M107
M05
G0 B40.926 Y0 F3000
G0 Z10 < Here
; Layer C00
Make sure focus and material are both 0 if you’re doing the origin and focus yourself.
The Max-s Value I took from the “outdated” manual “How to connect Snapmaker”.
Good to know that this is wrong and should be 255.
Z-Axis should be ddisabled? And “Unterstützung” also zero?
Thankfull for every hint …
Yes, that seems to be correct.
1 Like
@Skreelink I try currently the setting what you recommended. It works fine so far. Also the 10mm Z lift up is gone with “Unterstützung” = 0 … BUT … it seems that the speed settings are slower then expected. If I try this logo in image mode it needs more then 1 hour (with 1500mm/m or 2000 mm/m) If I do a comparrable job with Luban it needs lot less time. I would guess that the speed settings are not really the reality. Do you have any idea whoud it could be and what I should chnge? I will attache again the gcode. Thankfull for any hint. (seetings are now as in last post picture)
test2.txt (344.9 KB)
Luban is notoriously for bad estimates, however, also keep in mind that since it’s working in degrees it is moving less than a mm per degree. When you set 1500mm/min, on the rotary, by gcode you’re actually setting 1500deg/min (since that’s the unit the rotary moves in) and that will influence surface speed depending on the object’s circumference. 1 degree = 1mm only in an object with a circumference of 360mm or diameter of ~114.5mm.
The listed spec for the rotary is 45 deg/sec. You can do some advanced math to convert to match your material yadda yadda. However.
Instead, you can make Y do the bulk of the movement (and actually do the moves in mm/m) by setting the scan angle to 90 degrees, so the bed will move back and forth instead of the rotary.
@Skreelink & @adammhaile
I did a little math and created a formula. This could be included in LightBurn. If I want to get a certain speed, but the given value is simply “abused” by the software, then I have to calculate a suitable factor depending on the diameter of the object. This is easier than I thought at the beginning. Example: I want to laser at 1500mm/min, but Lightburn makes it 1500°/min, then I have to calculate how many °/min I need to get to 1500mm/min in the end. I calculate for that:
360/(d x Pi)=factor (D= diameter, Pi= 3.14…)
Now I take my 1500 and multiply it by the factor. I then set the result in Lightburn as the speed in order to obtain the desired speed at the end. You are welcome to try it out. It worked for me in all the counter-calculations. This would mean that if I set 1500mm/min as the desired speed in Lightburn, LighBurn could simply calculate the factor, multiply it by the speed and automatically set it as °/min for the rotary module. This is not rocket science either. LB knows the diameter, which I enter in the Rotary Setup. Now it would be good to know the maximum value of the rotary module and enter it in LightBurn if necessary. For the Snapmaker Rotary, this would be 45°/second. This makes it easy to calculate what the maximum possible speed would be for a certain diameter. Here is the simplified and shortened formula for the maximum speed: Diameter multiplied by Pi multiplied by 7.5 → d x Pi x 7.5 = max (real) Speed. But that would also mean that it cannot achieve the desired 1500mm/min with a diameter of 43mm. Good to know 
and would also explain why I could not see any difference in my test matrixes at different speeds, as the maximum value had long since been reached. Can anyone find an error in my calculations?
@Obicom for that Z lift you are getting you likely have focus height or material height set
@Skreelink are you seeing the laser stay on when a job is done? I can’t see anything that would cause what @Obicom is seeing.
@adammhaile I could overserve it yesterday again … after the job was done the laser was off … than I lifted the z axis and after a short while the laser switched on. Never seen before with Luban. Must something from Lightburn, but no idea why. Yes, the 10mm lift came from the Focus high. It is misleading in the German translation. Here it is called “Unterstützung”. This is a wrong translation. It should be translated to “Fokus Höhe” or “Fokus Abstand”.
Additional question in regards of the topic above. Is this correct that ´LB using the speed setting in rotary mode as °/min instead of mm/min and if yes … would you be so kind to take a look on my formula and think about to implement it in LB?
I’ll see if one of our support team that has the artisan can reproduce the issue with the laser staying on.
Sorry about the translation, we are having them all redone soon so hopefully they will be better.
And no, we don’t use deg/min. Just inch or mm per min.
@adammhaile That sounds interesting … what does that mean for rotation? Are you doing exactly the calculation I did to translate a static velocity into angular velocity? After all, the velocity when rotating is relative to the diameter of the object. How do you take that into account? And how do they take into account the maximum speed of the rotary module? This sets a limit for the speed of the rotary module. (Artisan = 45°/sec)
Nothing in the gcode would cause it, there’s a proper M05 at the end like there should be.
(going by the test gcode supplied above) also given the fact it comes back on after the machine moves back to the finish position (and thus finished with the gcode file) leans towards firmware bug.
G1 B-0.527
M05
G1 B-2.195
M107
M05
; return to starting pos
G0 X3.153 Y-30.44 F6000
Also did a quick test on my own machine, making a new program AND testing the one from @Obicom
however I truncated the center keeping the first and last 20 lines of movement/laser control. Both times the laser turned off as it should, and remained off.
However; keep in mind I’m running a 2.0 machine with custom firmware, and not the latest. Snapmaker “sort of” implemented inline in their firmware 1.15 and up (on the 2.0) which has a problem of keeping the laser on when it should be off. I assume their artisan base can’t be too different. Infact “A400” used to be in the codebase, which became the artisan. The bug turns the laser back on when issuing a power level of S0 at the previous power, instead of being off. However, an M05 should still override that and take the laser fully offline.
So overall, I think it’s a firmware bug. Maybe try downgrading to a previous firmware version, or upgrading if you’re not on the latest?
@Skreelink I have never observed that with Luban during 100 of hours. It happens only with Lightburn. So I would guess it can’t be from the firmware. I will still observe it and will try to find a way to reproduce it. What do you think about mm/min speed and °/min for rotary. Are you sure that Lightburn translate the speed settings (e.g. 1500mm/min) into °/min?
Unless the snapmaker is doing calculations in the firmware itself, the gcode lines here;
G1 B2.196 F2000
Are a rotary movement, in degrees, at F2000. The firmware would interpret this line, as read, “move 2.196 units at 2000 units per minute” which the units in the rotary are degrees, as we have established. Lightburn and Luban both simply stretch the image to match the circumference, which would change how far it goes.
Example, this is the movement section for a 10x10mm square @ 3000mm/m on a 50mm diameter object.
; Cut @ 3000 mm/min, 20% power
M107
M05
G0 B11.459 Y0 F3000
; Layer C00
M03 P20 S51
G1 B-22.918
G1 Y10
G1 B22.918
G1 Y-10
M107
M05
G90
and simply changing the size to a 100mm diameter, same exact project.
; Cut @ 3000 mm/min, 20% power
M107
M05
G0 B5.73 Y0 F3000
; Layer C00
M03 P20 S51
G1 B-11.46
G1 Y10
G1 B11.46
G1 Y-10
M107
M05
G90
Notice it’s still using F3000, so 3000 units per minute, but the B rotation changes, and gets smaller (since larger diameter objects are “flatter” and requires less stretch).
50mm: G1 B22.918
100mm: G1 B11.46
So for an object that should end up the same exact size (10mm), is traveling twice the distance, but at the same speed on the smaller object. Effectively changing the ratio to 2:1.
Edit: Generated the same project in Luban after updating it to 4.8.0. Ending gcode is still just an M5, though not as many, and it doesn’t have the padding 0, though M5 and M05 are exactly the same.
M5
G0 Y5.00 B0.00
G92 B0.00
M107 P0
; G-code END <<<
G91
G0 Z0 F150
G90
And back to the distance experiments, Luban starts it in the center instead of moving to a corner to start, so you have to add together the distances.
50mm object;
; G-code START <<<
G90
G21
M106 P0 S255
G0 F3000
G1 F3000
G0 X0.00
G0 Y10.00 B-11.46
M3 P50 S127
M3
G1 Y10.00 B11.46
G1 Y0.00 B11.46
G1 Y0.00 B-11.46
G1 Y10.00 B-11.46
M5
G0 Y5.00 B0.00
G92 B0.00
M107 P0
Movement goes as follows;
G1 Y0.00 B11.46
G1 Y0.00 B-11.46
From positive 11.46 to -11.46 == 22.92 (rounded up from 22.918 we got before.
Same exact thing, 2:1 with 100mm object.
; G-code START <<<
G90
G21
M106 P0 S255
G0 F3000
G1 F3000
G0 X0.00
G0 Y10.00 B-5.73
M3 P50 S127
M3
G1 Y10.00 B5.73
G1 Y0.00 B5.73
G1 Y0.00 B-5.73
G1 Y10.00 B-5.73
M5
G0 Y5.00 B0.00
G92 B0.00
M107 P0
-5.73 to 5.73 = 11.46 units of movement. So Luban is also working in degrees, and the speed still lists as F3000 (in these examples). So X units at 3000 units per minute, or deg/min.
While written a bit differently, the end result of the gcode is exactly the same, along with how it turns the laser off.
EDIT2: I swapped the machine in Luban between the 2.0 and the Artisan, and it spat out the EXACT same gcode file. So that’s good to know.
2.0 on left, Artisan on the right, thumbnail hash truncated for readability.
Ok, so please note that as far as LightBurn is concerned it is outputting mm/min not degrees. I can confirm that for sure.
Whether or not that is correct for this machine is a different issue. We don’t have any other machines we support for which they take anything other than distance / time for the F parameter.
I’ll have to talk to Oz about if we can do degrees… I’m not even sure how the mixed units make sense since if you did G1 Y10 B12.7 F3000… what is the 3000 value here? Y is mm and B is degrees.
@Skreelink @Obicom regardless of the speed, is LightBurn outputting the size correctly for your tests?
Can you export the gcode for a 50mm square on both luban and lightburn and send those to me here? Sorry to say I agree it’s likely firmware. We emit the M5… at that point it’s out of LightBurn’s hands. But I want to see what’s different between Luban and LightBurn.
While technically the feed is mm/m, by how it’s written, it’s deg/min on B and mm/min on Y. 
I’m going to say the machine HAS to be doing some form of interpolation in the firmware for B distances. Since double the distance in code, equates the same physical dimensions. I never meant to really get that deep into it, but can sometimes get caught on a tangent. As I recall, however, when I did the math a few days ago, the theoretical max speed of the rotary should be something like 2880mm/m. So the fact it seems slower at 1500 on B than Y is odd, might just be perspective? The times are completely different as well. Luban even has two different times between the 2.0 and the Artisan so… 
I’m more inclined to trust Lightburn’s time estimate.
However, seeing as the code between Lightburn and Snapmaker do match up exactly (just written a different way) and every project I’ve done with Lightburn has come out accurate, yes. Lightburn’s code generation seems to be spot on.
Spoke with Oz and there is actually some tweaking to the feedrate we need to do. I’ll implement it and get a new build out soon.