Possible bug on H2D HOME button - can damage PEI

Okay, to make a long story short:

I was doing some maintenance on the H2D and trying to resolve my first layer print quality issues - which I posted in another post/topic here.

The scenario,

  1. Using the touchscreen - moved the toolhead to the max -Y position. By chance, I had placed the tool head above the air filter near the right side.
  2. I raised the bed to the maximum Z position so I can clean underneath and verify that some screws are not loose. The tool head is tucked away above the air filter area.
  3. Done cleaning and pressed HOME on the touchpad and this is the problem:
  4. The bed did not move and remained at max Z height position.
  5. The tool head moved out of the air filter area along the +Y and then moved X, back to -Y.
  6. I quickly unplugged the unit.
  7. My PEI plate has a deep scratch. Luckily, the print head is not damaged or bent.
  8. So watch out when pressing the HOME button, make sure to move down that bed manually first.
    I submitted a ticket with Bambu, and they gotta put something in the firmware to prevent the HOME button from moving the toolhead along X and Y without moving the bed down first.

Here is the picture of the mark - hard to capture after I washed it, hoping it was a superficial scratch…

I think it has happened various times across multiple of my bambu machines… I don’t think they are going to fix it (but I do hope that at least they try to).

My suggestion is that, whenever you do home or other operations, make sure that the plate is empty and you leave some space for it to go up and down… Because you can’t trust the machine to do that unfortunately.

This is one of the scenarios where it happens. I’ve reported it so many times that I’ve stopped submitting tickets altogether.

Support also told me they wouldn’t fix it and showed no concern for customers’ damaged build plates. If you open a ticket, they’ll ask you to reproduce the issue on video—so be prepared to risk another build plate.

I hear you guys.

At least I don’t feel so dumb. As a casual programmer in my younger days, there were some basic things when writing a program or a function, and having some failsafe in place.

I do expect them to brush off my ticket and ignore me completely. Just hope this is a good reminder for everyone to be careful.

At least I was able to solve my 1st layer issues and also my ironing issues. It just happened that my Bambu PLA filaments prefer a flow rate of 0.90 rather than 0.98 to get perfect prints.

My line gaps at the first layer prefers an initial layer width of 0.30 and it is perfect.

All I need now is to learn how to get clean supports to break off. Putting 0.2 at the top or bottom Z level is still rough. I have not reprinted models with supports after fixing the 3 things above yet so it may be indirectly fixed.

In any case thank you for responding.

I am sorry to hear that your plate has been scratched. I have forwarded this to our team for investigation.

Please also send me a private message with your ticket ID, so we can further investigate the problem. It will be useful to include the log in the ticket, so that our team can investigate further based on your example.

Thank you.

4 Likes

Gotcha, I will forward all relevant information to your team. If this helps the next guy, then it is all worth it.

2 Likes

A quick and disappointing update on this “bug”…

  1. Bambulab tech support implies this is by design and that the problem resulted from user error.

  2. I replied that I completely disagree. The HOME function implies the printer will revert back to its home position regardless of its current state unless there are abnormal obstructions or abnormal behavior. Instead, the HOME function will unconditionally initiate a return to the home function without any checking.

This reckless implementation will result in many accidental damage with the fault inadvertantly being pushed back to the end user with certain damage to the build plate, potential damage to the hothead, potential damage to the toolhead, and potential damage to the heatbed.

As an analogy, I have flown drones from different brands the funciton RTH (Return To Home). The device will safely ascend to the preprogrammed high by the user and initiate a return. Should there be obstacles, the drone will stop or go around the obstacle when it can. What Bambulab support is saying is similar to this but the device will initiate movement without checking, and the responsiblity of the end user to position the device in the optimal position. This does not sit right with me.

I will wait for their response and hope to hear a more reasonable and practical answer. I will seriously rethink my personal and business investments with Bambulab at home and at the print farm and seriously consider switching to a different manufacturer if need be.

Mind you, I never asked or expect any freebies or replacements. This is more in response to what I feel is a strange and unreasonable response.

In closing, please take extra precaution when using the device. Aside from this issue, I do not know what other inconsistencies to expect.

=========

2025-10-04 00:24:45
Dear Customer,

This behavior is not caused by a software bug. The collision occurred because the homing sequence was initiated manually after the Z axis had been raised outside the normal operation range. When the printer is manually moved into a non-standard position (for example, lifting the bed fully up before homing), the system does not have a reference point for safe travel, so it may not lower the bed before moving the toolhead.

For future maintenance or inspection tasks, we recommend always returning the toolhead and bed to their original positions or performing a controlled homing sequence before manual movement. This helps prevent collisions or damage to the PEI sheet or toolhead.

If you need any further assistance, please don’t hesitate to contact me

Thank you,

Bambu Lab Customer Support

When the stepper motors have been released for some reason, the printer cannot for 100% know where it is.
You will notice a warning, every time you move an axis. It then proposes to home the printer, but you can also ignore the warning.

To home the printer it needs to find the XY zero first so that it knows where the center of the build plate is when it zeroes the Z axis.
It cannot start with Z because it has no clue where it is. Bringing Z up at the current location is giving the risk that the nozzle is missing the build plate entirely and you might damage a lot more than a build plate.

They could introduce a motion that first lowers the bed a couple of mm to prevent your issue, but when the build plate would be already at the bottom, that might damage the Z belt, although they could do that motion with a very low current on the steppers so nothing would be damaged.

You are probably one of the few people that raises the bed above the nozzle tip and executed a homing from that position. Something BBL developers didn’t anticipate.

Let’s hope they will adjust the homing motion in the next firmware update to fix this.

In the meantime they could have been a bit more tolerant and at least replace the build plate and possibly the nozzle in your case.
This is a learning experience for BBL also.

1 Like

Thank Gerrit! I totally agree with you. I believe all scenarios should be accounted for (actually, let me rephrase, as much of reasonable scenarios should be considered).

They should be more tolerant of their wording - and if they had said, thank you for the feedback, and we will consider it in future firmware - I would have been satisfied.

So in the meantime, this should serve as a warning to all. I test printed some models on the reverse plate, and the models came out okay, fortunately.

Visual and physical inspections of the extruder and looks okay.

It’s impossible to do with current bambu hardwares

That’s disappointing to hear actually…

What do you mean?
They can’t run the Z-axis stepper at low current?

It might not have sensor-less homing, but the stepper driver should be able to run a couple of mm down in low current and when it would reach the bottom, it would skip steps instead of damaging something.

I would say that a simple end stop sensor of any kind could have been added to guard the lower position of the bed, but in my opinion the homing process could be improved with firmware also.

1 Like

It doesnt solve the XY damage, but for adjusting the Z first a simple limit switch would prevent issues. When I was building CNC routers these were very easy to incorporate, Im surprised the H2D doesnt have them.

This is what I mean!
They don’t lower the bed first because there is no sensor (limit switch, hall sensor, etc.) to detect the bottom limit.

This is purely cost saving. Because it needs a sensor, wiring, an interface on the board to connect to and additional labor to assemble it.
It also adds an additional point of failure, which then becomes the responsibility of the manufacturer.

Assessment and request for action

From my testing, this appears to be a reproducible design issue rather than an isolated bug. I can consistently trigger the behavior as described below. Please review and advise whether this qualifies as intended behavior or a defect. If confirmed, I’m asking for a corrective plan.

Repro summary (short):

– Model: [exact model/firmware]

– Steps to reproduce: [1–2–3]

– Expected vs actual: [expected] / [actual]

– Impact: [e.g., risk of damage, downtime]

Product priorities (statement of fact, not attribution of motive)

Several fixes for existing models remain outstanding in my experience. I would welcome clarity on timelines for remediation alongside new releases.

Contest integrity (status update only)

I have submitted a complaint to the competent authority regarding a recent community contest. My submission asserts that multiple announced winners did not meet the stated entry criteria. As this is now pending review, I will limit public comments to verifiable facts and process updates. The authority will determine the outcome; I will not speculate.

Consumables quality and support

I received TPU spools with significant unusable portions (approx. one-third per spool). My make-good request was declined. I’m sharing this to highlight a quality/sustainment concern for existing customers.

Account moderation / GDPR (historical note)

An earlier moderation matter was resolved by agreement before any decision. I’m not disclosing details and reserve my rights in any future, similar scenario.

Constructive path forward

I propose that affected users compile concise, evidence-based reports (model/firmware, steps to reproduce, logs/photos). For EU customers, consumer-protection and digital-platform obligations may apply; I can share templates to structure submissions so issues are handled efficiently and respectfully.

Request to Bambu Lab

Please (i) acknowledge the reported behavior, and (ii) publish either a corrective plan with indicative timelines or a reasoned explanation if this is by design. A transparent protocol for known defects—and clearer communication on contests and moderation—would help rebuild trust.

Evidence structure for unresolved or delayed cases

Purpose of this post
Several users have experienced situations where issues remain unacknowledged or where communication stalls. To keep discussions factual and actionable, this post provides a standardized evidence template that anyone can use when Bambu Lab declines, delays, or stops handling a case. The goal is not to argue, but to help all parties work from the same verified facts, presented in a consistent, reviewable format.

This structure is intended to be compliant with forum rules and EU consumer frameworks. It can also serve as documentation if the matter later needs to be escalated through official channels.


Evidence Template

Issue title:
Short and factual (e.g., “H2D build plate collision during Z‑max homing”).

Affected product(s):

  • Model(s):
  • Serial (redacted):
  • Purchase date / region (EU):

Environment:

  • Firmware:
  • Bambu Studio version:
  • Nozzle / bed / chamber details:
  • Build plate type:
  • Filament (brand, material, batch/lot):
  • Any modifications:

Preconditions:
Describe any setup required before the issue occurs.

Steps to reproduce (SR):

  • SR‑1 …
  • SR‑2 …
  • SR‑3 …
    (Keep each step verifiable and brief.)

Expected result:
What should happen.

Actual result:
What actually happens (include messages, sounds, LED patterns, etc.).

Impact / risk:

  • Safety or damage potential: [Yes/No; specify if “Yes”]
  • Downtime or blocked task:
  • Frequency of occurrence:
  • Number of units/users affected:

Diagnostics & artifacts:

  • Log files: name + SHA‑256
  • G‑code / project file: name + SHA‑256
  • Photos / videos: name + SHA‑256 + timestamp
  • Profile export: name + SHA‑256

Reproduction matrix (optional if tested on multiple setups):

Model FW Plate Filament Profile Result Notes
Pass/Fail

Workarounds tested:
List all changes you have tried and their results.

Related threads or tickets:

  • Forum thread(s):
  • Support ticket ID(s):
  • Date/time of support responses (Europe/Stockholm):

History / prior determinations:
Summarize any previous denials or “by design” statements (≤25 words each).

Request for corrective action:

  • Confirm classification (bug vs. design issue)
  • Publish remediation plan or reasoned denial
  • Provide estimated timeline or interim mitigation

EU customer note (informational):
EU consumer‑protection and digital‑platform obligations may apply. This note is for information only — not a legal threat.


File naming convention

YYYYMMDD_HHMMSS-Model-Topic-Artifact.ext
Example: 20251005_094312-H2D-ZMaxHoming-Video01.mp4

Include SHA‑256 checksums for verification:

20251005_094312-H2D-ZMaxHoming-Video01.mp4
SHA256: 3f2a...d91c
Timestamp: 2025-10-05T09:43:12+02:00 (Europe/Stockholm)

Evidence pack structure (ZIP)

/evidence/
  /media/              # Photos/videos
  /logs/               # Printer logs
  /gcode/              # Exact test files
  /profiles/           # Exported slicer profiles
  /reports/            # Filled-in report (PDF/TXT)
  checksums.txt        # SHA-256 list
  README.txt           # Short “how to reproduce”

checksums.txt format:

SHA256 *relative/path/to/file

Capture recommendations

  • Record the entire reproduction in one continuous take, showing both display and motion.
  • Avoid personal or identifying data in photos or videos.
  • Redact serial numbers in public uploads, but keep originals for formal evidence.
  • Use ISO 8601 timestamps with timezone Europe/Stockholm.
  • Keep tone factual — no personal remarks, no speculation.

It needs a physical Z limit switch I think. OP’s problem is caused by that.

Bambu uses the loadcell on toolhead instead of on bed. So the only way that the bed can know where it is, is to, touch the nozzle first. Either going slowly up or down would fail in this case. Z is very hard to do sensorless detection due to extra weight.

I think this is a design flaw caused by the lack of physical switches, nothing too much can be done with the current hardware. If it goes up too much it hits the nozzle, if it goes down too much it hits the bottom.

My suggestion as a user? Always make sure that the bed is in a reasonable place before doing home…

Bambu should really just put the camera feed EVERYWHERE on the interfaces, including sending prints.

Lack of limits switches prevents a complete automated solution.
However Bambu should add UI that prompts the user to make the sure the bed is a safe distance from nozzle, before initiating Homing.

They know the machine is out of the safe position, because they already prompt you for that.

So adding additional UI prompt and polish here would be trivial.

Thank you for the support and feedback. I don’t feel as dumb running into this issue. After receiving Bambulab Support’s message, it made me feel like I was at fault for making basic assumptions on how to use the machine…

Similar scenario happened to my A1 a few weeks ago, where it wasn’t even at insane maximum or minimum Z-position, I was just doing normal lubrication of the z-axis screws and used the printer’s movement system to smoothen out the globs of lubricant. When I was done I pressed the home button, but when the gantry went upwards, it didn’t stop going up and kept hitting the top of the printer and made a very unsatisfying noise and I shut off power the moment I realized it wasn’t going to go back down after 1 second of loud thud noises. Luckily this caused no permanent damage to the printer but it was quite scary, and I hope this doesn’t happen again.
I used this same method of lubrication of the z-axis screws on my H2D and even though I raised it higher than the bottom of the nozzle (which was all the way at the back of the printer) I put it back lower than it before pressing home again, since it just seemed wrong to press “home” when the bed is at a higher elevation at the bottom of the nozzle and learning from past mistakes I did not want this same thing happening to a 2,550 dollar machine. But yeah, rule of thumb, if it doesn’t seem like its in the right spot, you should probably put it back before using it again.