Today after powering it up, I homed it first and it did not make grinding sound since (even after several prints).
Does it grind for you if your first action after powering it up is home as well?
It just happened to me when bed was at the lowest position - it was clearly on Z axis - I could see the bed trying to go lower, but of course, could not. Is here anyone from Bambu monitoring this thread? It def looks like a serious issue.
1 Like
FWIW, this has been a known issue for some time now.
1 Like
Is there any solution for now? Perhaps making sure that the bed is not at its lowest position before initiating new print?
1 Like
Yes, that is the only workaround I’ve seen mentioned so far.
Maybe the reason why this happens is in machine G start code:
;===== machine: X1 =========================
;===== date: 20230130 =====================
;===== reset machine status =================
G91
M17 Z0.4 ; lower the z-motor current
G0 Z12 F300 ; lower the hotbed , to prevent the nozzle is below the hotbed
G0 Z-6;
G90
...
G91 sets to “relative” mode, which then follows by G0 Z12. If bed is already at lowest… then disaster follows.
EDIT: If my speculations are correct, then following modification should fix it:
;===== machine: X1 =========================
;===== date: 20230130 =====================
;===== reset machine status =================
;=== added by djeZo888 ======
G90
M17 Z0.4 ; lower the z-motor current
G0 Z30 F300
;=== end added by djeZo888 ===
G91
;M17 Z0.4 ; lower the z-motor current
G0 Z12 F300 ; lower the hotbed , to prevent the nozzle is below the hotbed
G0 Z-6;
G90
EDIT2: Not sure what would happen if you run this after power up, because printer doesn’t know location of Z at that time.
1 Like
I can confirm that this isn’t only happening on the z-axis. Issue also occurs on the y-axis randomly at the start of some prints.
Does it happen at the beginning? If you tell me at which point after start of the print it happens, I may find the problem in G code.
The solution I posted works for Y axis.
I did some further search and it looks like this is a problem that has been around since long time and nobody care to fix it. Like some people said, this G code is a mess and there are a lot of unnecessary moves and actions that could be removed thus reducing “preparation” time.
A few days ago, I’ve been printing Hydra AMS, which is fairly high and in subsequent prints I’ve experienced this issue as well.
Has BambuLab been notified about this bug?
Do they have bug tracker for firmware issues? Is it public?
Do we know when next firmware/Bambu Studio update is planned for release?
The issue happens when starting new print, after previous print moved bed to lowest position and printer has been turned off between prints. For me, workaround is simple: perform manual homing after turning the printer on.
djeZo888 > Do you know why Bambu has added lowering bed to startup gcode? Looks to me like some debugging code which unfortunately has been distributed to customers. During normal usage of Bambu X1C, nozzle should never get below hotbed.
No idea why this is there… it is useless. Perhaps it is there to solve issue in case of some rare combination of positions which would end up in failed print.
Btw, the G code I added seems like solves the issue plus it also works okay directly after printer is turned on. Since I have been using it, I do not get grindings anymore.
Furthermore I also changed end G code, so it does not drop the bed very low after print is finished. It is another possibility how to solve this issue.
...
M17 Z0.4 ; lower z motor current to reduce impact if there is something in the bottom
{if (max_layer_z + 100.0) < 225}
G1 Z{max_layer_z + 100.0} F600
G1 Z{max_layer_z +98.0}
{else}
G1 Z225 F600
G1 Z223
{endif}
M400 P100
M17 R ; restore z current
G90
G1 X128 Y225 F3600
...
So, instead of moving to 250 (or 248), I move it to 225 (or 223), which is 25 less. That is enough so that next time when print is initiated, bed wouldn’t go so low to crash anymore. But in this case, you still need to be careful to raise your bed a bit if you are doing manual bed adjustments dropping it down to the very low/lowest position.
3 Likes
I haven’t been printing as much throughout the past couple days, and I don’t consistently run into this issue. The things I’ve been printing have not been tall, so I am starting to think that perhaps I was just overlooking how low the bed actually was when I was beginning the prints I was hearing the grinding on. Since I haven’t had the issue in a few days, I’m starting to doubt my previous claims that this was happening on the Y axis too. Still keeping an eye out though, will capture some detail or a video if it happens again.
Actually, the print doesn’t have to be very tall, the code shows that the bed will drop down if the object is 150mm or taller.
This is normal if your bed is all the way lowered. Naturally it wants to move the bed down a little on startup to make sure it is out of the way of the print head moving. If you’re concerned, make sure the bed isn’t bottomed out before you power off the printer, then it won’t do that at startup
1 Like
Yes, but why would you need to take care of that manually? It should be automatic. There is no need to crash. And like I said, it can be prevented. Running modified G code for days now, no issues anymore and no more crashes.
1 Like
Well i manually have to remove the finished print. So raiseing the bed is not hard since you are there at the control screen.
I don’t see it as a crash, its something that Bambu Lab decided to do to keep from damaging the nozzle or the bed. Even Prusa makes their stepper miss steps checking z height. 
1 Like
Yeah, the printer companies have no need to justify their choices to the user. If they had to detail every decision, explaining their reasoning, then listen and reply to all the counter arguments from the “armchair experts” , it would take an army.
Even tracking down the people who decided on a single issue and getting them to recall a chance meeting discussion between three people on the factory floor six months ago to find the answer to a single decision …
Think people. They ain’t explaining this or any other Firmware choice.
EDIT: Not aimed at you @Barryg41 
1 Like
I have had this issue a total of 5 times since I got my X1C. 1 time was a few days after getting my X1C and lowering the bed fully prior to homing, 3 times were while printing the Hydra AMS sections (forgot to raise the bed EVERY time) and the last time was after printing something else that left the bed lowered at the end.
Honestly, if I knew that it was just noise and that no potential existed for causing damage, I’d be totally fine ignoring it. It’s just that it sounds like the belt slipping on the drive sprocket.
I am not expecting anybody to justify any design decisions to me, but my expectation is that any company capable of developing a world class product like this is more than capable of solving such a basic programming issue in a ridiculously short time.
When I got my Mavic 2 Pro a few years ago, I marveled at the insane level of engineering and sheer amount of brainpower that went into designing that amazing machine. The only reason I bothered to learn more about Bambu Lab was after reading about the company’s origin. DJI broke ground on a new era for drones and photography/videography. Bambu Lab is doing the same for 3D printers.
Regardless, a bug is a bug. Unless Bambu Lab engineers intended for the Z-axis to generate horrible noises during automatic operation, then I’ll consider this to be a design or programming error and keep my fingers crossed for it to be fixed.
I’ve been a mechanical and control system engineer for years. A funny (and somewhat relevant) memory I have is many years back when I was asked to solve an annoying issue with a product routing system. This was an issue that we all knew about, but it had not been corrected due to other tasks with higher priorities. When my manager asked me about the issue, I began to explain why the issue still existed. He stopped me after a few sentences and said, “I don’t really care why this is still a problem. I just want to know if you can fix it.” I stopped and replied with, “sure!” His response was, “Well then, go fix it.” lol And just like that, it was fixed. 
1 Like
This has happened to me since day dot. If the printer finished a tall print. The only way to get it to stop is by homing it beforehand.
That’s my experience in any case. I would have thought they had fixed it by now
1 Like
Ive been having this issue since updating firmware. I dont understand how the printer does not know or check z axis position before attempting to move it beyond its lower limit. Itd also be nice for the stepper motors to have an over torque alarm before skipping belt teeth.
2 Likes
if the solution proposed by @djeZo888 is the one that avoids this horrible noise, which just woke me up, then BL should take this into the next Studio version, for Christ sake. I knew it, forgot it, just printed something tall and… My god, terrible noise.