SM2.0 ignores certain gcode commands

Hi all!

First post here! I was hoping to put together a set of standard calibration prints that I use for new filaments/spools of filaments to dial in settings with minimal prints required.

I am looking to include a temp tower and test print for linear advance values but I am told that other users have had trouble with SM2.0 ignoring commands to change temp or to set K value (linear advance) such as M900 Kx.x.

Has anyone found a work around for this?

As you can see from this G-Code table for Snapmaker it doesn’t seem to use M900.

Im not entirely understanding your reply. From what I can see, the link is to the SM1 gcode reference file.

What I dont understand is why it being missing from this reference file would mean that It would ignore a built in gcode command? When entering M503, I can see the linear advance value printed in the console “M900 K0.22” so it seems there is a parameter saved for this (the default Marlin value for K).

I have been able to manually change the K value using M900 and have seen it affect print quality so it seems to respond to manual changes. Just wondering if there was a way to get it to respond to the M900 commands generated in a tuning file from Marlin found here:

I think the M900 command works. The table shows modifications we made to original Marlin G-code, and most of Marlin G-code are supported in both SM1 and SM2. We will rearrange a new document as an official G-code reference on our website later.

1 Like

Is anyone else seeing where the initial bed and extruder heat to temperature codes are being used but the Snapmaker 2 is ignoring all subsequent M104 and M140 codes in the files? I went as far as setting it up so they are reset at every level change and my SM2 A350 continued to print at the initial layer values.

This occurred with both the SM Luban software and code I generated from the Prusa Slicer applications and the M codes were in both files where I expected them to be.

So far this is making it so I either have better bed adhesion with PLA but with stringing and niblets bleeding off the object or better print quality and essentially eliminating the string with a greater chance of the print not adhering well from the the first layer to the bed (although I must admit the included coated spring metal bed is easier to adhere to that most).

This is the exact issue I am talking about, the same happens for temp towers where the M104 and M140 commands are included in the gcode but the SM2 seemingly ignores these values and continues with the initial temps.

1 Like

So what the real solution ??
How to print a tower temp on CURA with SNAPMAKER2 ?
How to properly print K value test also ?

1 Like

I have the same or similar issue. The printer ignores any nozzle temps in the start gcode and only takes the print temp it seems.

The only solution with the current firmware that I can figure out is to manually change the temperature at the correct time. A possible activity when it involves the initial layer and a change to the following layers, but with a layer tower that means staying nearby and watching for the correct time to change to the next temperature.

I can now confirm it is the touchscreen controller parsing the gcode that causes the temperature gcodes and others to be ignored. I disconnected the touchscreen and setup Octoprint on a Pi 4 B and my same start code works as expected. I can now send the gcode directly from PrusaSlicer and start a print. A few more tweaks to do before it is ready for primetime though.



Have you had any success in obtaining SM2 A series supported Marlin 2 g/M code from SnapMaker?

Yes I can confirm there is a bug when dealing with temperature G-code in TS, we will fix it ASAP.

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?