Bug Reports and Feedback for Snapmaker-GD32Base-2.X


If you find a bug on the touch screen (Firmware version: Snapmaker-GD32Base-2.4), please report it here. I will give feedback to our developer and solve it as soon as possible. Thank you!

Downloads and Updates for Firmware
Downloads and Updates for Firmware
Downloads and Updates for Firmware
Downloads and Updates for Firmware
Downloads and Updates for Firmware
Downloads and Updates for Firmware

I have updated the firmware to GD32Base-2.4 and have some new symptoms. It is necessary to confirm whether it is a bug.

I set the nozzle temperature to 207 degrees and when I output it, the temperature of the nozzle flies like a wave between 180 ~ 220 degrees during the output.
When the temperature ran out, the printer output stopped due to Thermal Runaway Error.

I knew that the sensor was faulty and replaced both the heater and the temperature sensor, but the symptoms are the same.

So, the temperature of the nozzle of gcode was changed to 205 degrees, and the above symptoms disappeared.
Firmware 2.2 did not have this symptom. However, after updating to 2.4, these symptoms suddenly appeared.
You need to know if you have a new bug.


I found the cause of the problem. It seems to be down due to the heat dissipation problem of the board, not the firmware problem.
I removed the case of the control board and used it.
It seems that the heat dissipation of the control board case does not work properly.


I don’t like the feature that the Snapmaker “parks” its head at the top. Owning the compartment I noticed it became quite tricky to do a filament exchange cause you got so little room on top to do a clean insert. 5cm lower would help. And the head doesnt have to move all the way down (Z-movement takes so much time) to prime itself and start printing.

Furthermore the whole init process is somewhat not optimized:
Why does it heat up both nozzle and the bed and then start its priming routing? It would be better if it both heats up and moves the nozzle to 0,0,0 for priming so it can start instantly when it’s heated up. Yes, it pumps filament before printing and that can only be done with a heated up nozzle, but still it can move to the init point, keep heating up, then pushing the filament. In case fine leveling needs all temperatures be at 100% of the print setting, still the firmware can send the head to the origin and do the final fine tuning / filement test after it’s 100%.

I know, it’s just a little print time saving, especially on long lasting prints, but in case you do a quick test print it’s quite some time.


Both of your “problems” are not within the firmware - the starting and ending scrips are written by the slicing software.

The initialization process is ok for me.
But I think what you want is not possible with the gcode (no actions during waiting for temperature stabilization). Because we have stepper motors without feedback (like an absolute encoder in my drems) you have to home all axes to the limit switch to be sure to hit the right point when the print starts.
Laser and CNC function are not as automated as the printing routine.

My Ultimaker does this routine at startup:

  • heat the nozzle for automatic active leveling (if activated) to about 175°C
  • heat the bed to set temperature
  • home all axes
  • move nozzle to priming position
  • heating up the nozzle to set temperature
  • priming routine

The parking position is not optimal - but also done with the gcode.
For the filament change I use jog mode (10 mm mode) to move into a good position.
Because of the structure of the machine I would suggest to home the x axis to reduce the torque on the Z axis.



With the firmware before it didn’t go up to top Z positions. Currently I notice that it even wants to do some extra Z+ steps on priming, running into the limit with a unhealthy sound.

the starting and ending scrips are written by the slicing software.

Ok, so I hope the devs relocate this problem to being a problem in Snapmakerjs.


The parking position is not optimal - but also done with the gcode.

Just did some testing, even with no gcode loaded the head won’t move further down than 10mm. Z-axis is locked after that. It just can’t be moved by software (Simplify3D) nor disconnected via touchscreen, so I guess the parking position is coded in the firmware.


Hi Rainie,

When clicking on files on the touch screen, i noticed that the 1st file in the list is hidden as the back and home buttons are over it. Could you please start the list below these buttons.

Is there any possibility of adding more stats to the screen like time left.


Since the last firmware update I have not been able to calibrate properly. Prior to the update i was printing PLA directly on the snapmaker bed with zero adhesion issues (no tape or gluestick). After the firmware update I am having issues with calibrating (and adhesion). After adjusting the calibration I go to print and it doesnt reflect the adjustments. After the failed print I go back into calibration and adjust the points that are too close to the print head and causing the failure (I have raised the so much that in calibration mode i can slide paper between the nozzle and bed without touching) but it is still too close when printing. This is across many different gcode files and using the same spool of PLA as before the update.

Im not sure if the head/arm is dropping before trying to print (hardware issue) or resetting the calibration (software) but it does seem to keep roughly the same height every time I start a new print.

Please Help!


Hi wh8424, this is Alan here.

Did you mean no matter how you calibrate the printer, the 3D print module head still maintain a lower height level relative to heater bed. Due to this issue your print job always fail when printer start printing.Is that right?

Looking forward to your reply.

Best Regards.


yes, i have raised the pint head in calibration mode so high that a piece of paper will slip between without touching but the nozzle during printing rubs the build plate and usually will knock off parts of the first or second print layers.

I have not tried if i lower it too much in calibration what will happen, or if i raise it a very large amount during calibration what will happen.


I see, thank you for your feedback!

Did you re-calibrate all the point (start from corner 1), or try reset and re-calibrate the printer?

Will try to reproduce with Firmware 2.5, Once I get progress will post here.



Yes, I have always calibrated 1 through 4 in that order. Also have tried resetting and then calibrating and that didn’t help…


Hi wh8424
Had tried a few time but still unable to reproduce until now.I think it’s not only firmware cause this problem(such as controller board or linear module).
Is your machine still has this issue? If it is ,you can send emails to support@snapmaker.com.



I just upgraded my firmware to v 2.6 (basic). I chose basic (v1 for enclosure with no lock) because I don’t have an enclosure.

My Snapmaker was no longer able to Home (Snapmaker would hang), and upon closer examination, I was unable to use the Z axis (there was simply no response)

This is a pretty serious BUG.

I reloaded my v 2.4 firmware and the problem went away.

I tried loading v 2.6 a 2nd time and the same thing happened.

I am definitely sticking with v 2.4 and would warn anybody against installing v 2.6


Something wrong with Y-axis-control?

After upgrading to 2.6, I get some strange failures in the Y-axis (back to front), where the print is suddenly shifted, and then just prints on, and sometime later jumps again, the lower one exactly to the original position.
I have changed material, clamped the magnetic buildplate, resliced.
But now I am back at 2.2, and noticed the feed-sound is smoother, like better handovers between line-segments, so I suspect something in the basics has changed for the worse.


Hi Broomer68

Would you mind uploading the g-code file? just want to reproduce this problem on 2.6.By the way what software you choose to slice the model?



Gcode by cura, and printed allright before firmware-update. but I think the problem has been resolved.
When I downgraded to 2.2 everything printed good, then I tried reflashing the 2.6 again, and it still works, so, I suspect the first upgrade had some problem, without reporting a bad flash.


So the shifted problem wasn’t showing up when you re-upgraded to 2.6 ?

I still wonder what caused the layout shifted. So I would like to reproduce this problem.If you can provide the g-code file which had this problem, that would be helpful.



Yes, the shift has not (yet) re-appeared.
The files are quite big >50MB so uploading takes some time. I will do that tonight.

But I doubt it is the file, as the shift did not occur with the old firmware, and it was in several files, and not at specific heights, and not the same shifts either, just 1 time it has shifted back to original position.