I watched/listened to the video. I don’t hear anything unusual. Sounds the same basically as my SM2. Noises change based on speed and direction is normal. But I certainly don’t hear any unusual “beating” noises.
@Rwide
hi, everything is tight, there are no loose components.
If there were loose components, you should be able to tell from the print result, but that’s not the case.
I haven’t even asked about replacing them yet.
It must have something to do with the thermal load on the electronics, but even the replacement board has the same problem.
@snapUser
Then you should listen to it more closely, or you are stress-resistant when it comes to unusual noises.
If the printer runs very quietly and only starts to rumble after more than 15 hours, this is not normal.
Ya whatever.
Does it print fine?? Then I think you’re paranoid and wasting your (and others) time to be frank, for over a year it seems.
Maybe so, but if the replacement board has the same issue it seems to me that the issue is probably somewhere else…
Didn’t you have a broken bed when you first recieved it?
Perhaps your machine was dropped during delivery and is now compromised, bent, cracked and/or unaligned somehow. Perhaps it still strong enough to hold against bending forces when cold but when it gets warmer and weaker, something is shifting…
I hope Snapmaker will solve the issue or give you a replacement printer soon.
1 Like
Why do you think the bed temperature is important? Have you tried with a lower temperature?
After how much time do you get the beating noise?
I know you’ve checked all mechanical parts already but just in case, in my printer there is a little bit of space at the top of the back panel despite all screws are super tight. It was difficult to localize. This results in some vibrations which sounds like a little bit like your beating noise. I solved it by inserting a piece of flexible filament between the wobbling parts.
I’ve downloaded your example gcode and will test as soon as I have time… probably the upcoming weekend.
Hello @obertini,
the bed temperature is required for 99% of print jobs, which is why it is switched on. It could be less, but I wanted the test to be as identical as possible.
I also had the rattling on the rear wall, I lined it with foam rubber and since then it has been quiet.
It takes me at least 15 to 18 hours, then the noise starts slowly and increases a little.
It was really ugly live and you think something is blocked somewhere, but that’s not the case.
I am very pleased that you agreed to do the test, thank you very much.
Best regards
I managed to start testing earlier than planned 
I let the printer run over night, but without heating the bed…
(Un)fortunately, I was able to reproduce the same beating noise as you have observed.
It did not happen at the beginning but started at around 80% of the print.
While I was making some videos to document the phenomenon, I remembered about someone having an issue with the printer slowing down the print on some models with a lot of gcode instructions. Seems like there is a bug of buffer overflow somewhere in the firmware. This was hypothesized because when pausing and resuming the print, the printer starts to print normally again…
So I tried the same strategy. At 81%, when the printer was making a lot of these noises, I paused the printer and I resumed it straight away. And guess what… no more noise!
Here are the videos. They are self-explanatory.
What are the next steps? I would suggest to try to slice your part with another slicer. Would you be able to share the STL? Another option would be to reduce the complexity/resolution of the part itself to minimize the number of gcode instructions. Ultimately, one would need to debug the firmware. Any c++ / Marlin expert out there?
2 Likes
You can try to remove all comments using a script. This one works for me for prusa generated files; just pass the gcode filename as first parameter:
#!/bin/bash
# Get the filename from the first argument
filename="$1"
# Replace occurrences of lines starting with ';' with an empty string
sed -i '/^;WIDTH:/d' "$filename"
sed -i '/^;WIPE/d' "$filename"
Thanks for the suggestion. I’ve checked the gcode file and it has been sliced the Luban. There are no line starting with WIDTH: or with WIPE …
Then I’ve adjusted your script to remove all lines starting with a semicolon and to remove all semicolon along with all characters following it for each line.
Number of lines in the original file: 654806
Number of lines in the purged file: 645622
=> difference: 9184
I also counted all semicolon in the original file and I got 9191 => 1.4% of all lines.
Can this low number of comments be the source for a buffer issue?
I may start another test with the ‘purged’ file. However I would be curious to see the results of the same 3d model sliced with another engine.
Hi @obertini,
that’s excellent that you’ve already had time and have the same problem.
That proves that I don’t have a quirk 
Now I just need to understand how exactly this comes about.
Do you really think it could be due to the file created by Luban?
Here is the uncut file.
I can confirm your observation.
At pretty much exactly 80 %…
So after about 16 hours of printing, the noises I mentioned occurred, then I paused the print for about 30 seconds and continued printing.
There have been no more noises since then.
@Jade
Could you please ask your colleagues how this can happen?
Who or what is now overloaded?
Thanks for sharing the model file. I’ve sliced it with Cura 5.6.0 and OrcaSlicer 1.9.1 and the resulting file size is roughly the same size as with Luban.
I don’t think it will solve the issue.
I’m now thinking of digging into the firmware. I’ve a working development environment but I’m hesitating to flash my printer with a firmware that I tweaked…
Does anyone know a procedure to restore a firmware in case the printer is not booting anymore? The only procedure I’ve found implies the use of the touch screen which is a way too advanced functionality that is unlikely to be available in case there is something wrong with a modified firmware.
1 Like
hi, I’m currently printing via Cura. I don’t think that’s the reason, but I’ll know more in the morning. I have no idea how the firmware works. At the same time, I informed Snapmaker Support about the issue.
Also started a dummy print overnight with an Orca generated gcode. This morning the beating noise is audible.
Let’s hope Snapmaker can address this issue. It’s basically a showstopper for large parts. Ignoring the noise is likely to induce some early wearing of mechanical parts.
1 Like
I ran one overnight, cut with Cura, printed and it’s exactly the same.
After you press pause and then start printing again, everything is quiet again.
I also really hope that Snapmaker can fix this quickly.
It’s just a shame that it took so long for someone to confirm my observation.
@obertini Thank you very much for your help!
Started another try this morning with your original sliced gcode file for which I removed all comments.
93% and no Beating Noise. It seems to confirm it is linked to issue 26 on Github.
However, I had to change the printing speed several times during the print to reduce the overall noise because the printer is next to my desk. I used the printer screen in Adjust->Work Speed. I printer the file at 250% speed mostly but I reduced to 50% when needed.
You can download the gcode file without comments if you want to give a try. I’ve also uploaded more videos.
1 Like
Okay, thank you for the information. Then I’ll run another test with your file tomorrow.
Im thinking maybe if we’re lucky, putting M111 S0 and/or M122 S0 in the beginning of the gcode could help? 
1 Like
So, I can officially confirm that it runs with the Gcode file edited by @obertini without any banging noises!
Everything is now as it should be, really, nice and quiet.
@Jade, would you please share our findings with the relevant team.
If you want to change logging levels, you might want to take a look at the corresponding custom Snapmaker command M2020 S14 as well ( SnapmakerController-IDEX/snapmaker/gcode/contorl/M2020.cpp at main · Snapmaker/SnapmakerController-IDEX · GitHub ).
1 Like