That’s the drawback of a beta firmware, when you install it you agree on a disclaimer that s… can happen. It should not be anything major, the main issues would have been checked by bambu prior to release but you’re not protected from whatever small things that was not fully tested, hence the need for beta testers.
That reported issues (if they really are reported in the proper beta firmware thread) are not handled and the firmware is released to the public as is, that’s a fault of bambu. These issues were surely overlooked and firmware was pulled.
Again, I did not check, were they reported in the right beta thread? because I’m sure support don’t check every single post in every thread.
I know that, but its not about the beta firmware here. Its about that they releases the public firmware without clarifying if that bug is still in it or not.
And lets be honest, if a reported bug that damages your printer still is in the public release thats a major flaw and will damage a lot of more printer of people that are not in beta.
Im a beta tester myself so things like this get ironed out and i know the risk that comes with it.
But when i install a public firmware that should be tested and my 2300 Euro printer just casually damages parts of its toolhead just because Bambu was lazy thats something different.
But it seems some people are cool with that happening.
Mine did the same thing it bent the stopper had to order some more just in case. But have to order all the stopper not just the plastic thing like in the kit that came with it. Which is strange
I guess you pointed towards the right direction. Probably the machine gcode got updated to compensate the issue. Haven’t checked but I believe the experts living inside this forum already know no offense
If your printer is saying it has a firmware update then it should be fine to update. The one that was available briefly got pulled, so if there’s a new one then I would assume that they’ve made some fixes to it and re-pushed it out.
Well it looks like the bed slamming into the bottom is still an issue even with the H2D they never fixed it. Had a power outage during print, printer comes back on and asks if I want resume, click resume. Tool head begins to rehome while bed starts to lower all the way to the bottom, hitting the bottom and then grinding out for 5 seconds (you would think some feedback would tell it that it hit an obstacle), made a god awful grinding sound, hope those z belts aren’t toast now. Then it started printing mid-air (resuming) without lifting the bed back up. Why did it drop the bed after a resume like that? Really strange. Can’t believe there is no detection or z-stop on this thing.
Maybe starting a new thread about this issue and starting a support ticket would bring more attention to the issue so they might fix it later? It seems like from what you’ve said that the power outage recovery feature doesn’t really work
ok let’s settle our argument before (kinda like a childish hobby for me) and try to figure out your case right now. this power outage resume routine is weird (and 100% not should be like this), a correct behavior should be that only the toolhead would rehome (it’s susceptible to innertia when power is lost), while the heat bed stays. I’m really wondering why this would happen. Luckily usually this would not cause physical damage, but you really need to re-tram your bed and redo bed mesh calibration now.
I think lowering the heatbed a little before homing the toolhead is probably still necessary (and may be the intended behaviour) to avoid the toolhead hitting the part, but the printer should still remember the last z location of the bed before the power outage and prevent lowering it too much and colliding with axis limits. And of course after the toolhead is homed, the bed should return to the last z value and attempt to resume printing.
It seems like maybe the printer either didn’t remember the last z location or the soft end stop isn’t working for the power outage resume routine?
I think what @moebis described is more like the bed moved all the way to the bottom. Which is not the correct way of doing it.
The soft endstop would only work when there’s nothing on the bed, and it’s only used for going upwards, because that’s how you trigger the loadcells. When you’re going downwards, it’s naturally very hard for the motor to detect a hard stop because it’s carrying weight.
Yes that makes sense, it shouldn’t move it to the bottom completely.
What I mean by soft endstop is the software endstop that prevents any commands that moves the axis beyond its limits to be executed, so for example in this case it should detect a command moving Z axis above 325mm (hitting the bottom of the machine) and prevent it from being executed. Afaik this should be a common feature in all CNC machines that don’t have a hard endstop limit switch on both sides of the axis limits. In this case it seems like there wasn’t a software limit to stop the collision.
no offense