SM2.0 ignores certain gcode commands

I assume you are also aware but forgot to mention that there is also a bug with M900 g-code commands too? This I would like to see fixed as well as it would make calibration for new filaments much simpler

No I think we did nothing to M900 command, I’ll ask our dev about this.
May you check the latest docs to see if you do it right.

M900 works for me via the console In Luban (USB works, WiFi does not) and Via the Octoprint terminal.

The firmware seems to be a mashup of Marlin v1.6.x and Marlin v2.0.x. I have not seen any supported G/M codes listed for SM2.

M900 works through the console for me as well but it does not seem to work when embedded in a g-code file like when tuning the linear advance “K” value

I’m guessing the TS is parsing out that command as well.

The temperature commands ignored (M104, M140, M109, M190) are fixed in Firmware version v1.6.1.0 (with TS v1.6.1.2): Snapmaker 2.0 Firmware Updates and Downloads

I have to state that only these 4 commands are overwritten by TS in order to have the adjustment feature. We don’t have any reason to change the behavior of original M900.


Great news! Thank you!

I can confirm that M104 and M109 commands are now working when embedded in g-code files. However, the M900 commands still seem to be ignored (see image below). I would expect to see different behaviour across the K value range of 0-0.2.

The g-code file for this was generated using the following website
The g-code file used in this image is also attached below
0-0.2kfactor.gcode (10.4 KB)

Has the Snapmaker team actually run tests with the M900 command to confirm it is working?

Shown in the image below the same lines but all printed using the same M900 K value (0.08). This was done by manually setting the M900 K value through the console in Luban and printing over a USB connection from a PC.

As you can see, the printed line quality shown is much different to the K0.08 line shown in the image from my previous post which suggests that the K900 command in the g-code file used to print the previous test was ignored.

Please can this be investigated properly as solving this issue would make tuning printer settings for different materials far less hassle as at the moment it requires manual changing through the console and re-printing per M900 K value tested.


Hey @C.Harris thank you for your testing.
You could write the M900 in your start-skript using cura, simplify3d for example.
I don´t know if luban could do so.

The point of this script is to dial in the M900 value though so putting a single value in the start script wouldnt help unfortunately. Im not even entirely certain putting it in the start script would do anything as it seems to ignore all the other M900 commands as well.

The only time M900 seems to work is when entering it into the console over a wired connection and saving it to the printer settings using M500.

I’m willing to bet that the script will work from Octoprint by bypassing the touchscreen. The touchscreen seems to have a few issues when it parses the gcode files. I will try to run the script tomorrow and let you know.


Thanks, that will go a long way towards narrowing down the cause of this issue!

1 Like

Does snapmaker team can answer about this bug ?
You never give exact answer about the bugs can you please be more involved. You guys only answer 1/5 questions on this forum.
We want snapmaker team to be more involved


push @parachvte @Rainie

Update please SM team

Sorry I’ve been off for a while.

What’s the issue here? Are we still on the issue of M900 not working if it’s in the start script?

Thank you for revisiting this.

The issue is as posted above that M900 Kx.xx commands within a g-code file do nothing. This is evidenced by the images I posted on March 8th.

1 Like

@parachvte Has there been any progress on this?

you’ve probably solved it but you can print the K value test over usb-serial connection, this way it will respond. i’ve found any K value between 0.05 and 0.08 to be really good