I found two more bugs in the new start code for the H2D (besides the wrong display information in another thread):
During flushing and flow dynamics calibration the toolhead fan stays either on low or not strong enough shortly before activating the poop shoot. This causes sometimes the filament sticking somewhere in the poop area.
(in the past the toolhead fan was activated with a high flow to cool the extruded filament)
The printer does a full bed levelling in bed levelling auto mode twice. Sometimes it does the bed levelling even three times.
Prior to upgrading to v2.5.x, I successfully printed multiple models using TPU for AMS. Today (after upgrading), when I went to print the same models, I now get an message stating “current firmware version cannot start this print job. Please update to the latest version”. Well, when I go to the console and check on firmware update, there is none. So I can’t print but also can’t upgrade the firmware.
Same issue as when they banned certain filaments on the ObXidian nozzle for the X1 Carbon, which then carried over to the H2D so it could no longer print ASA Aero with HF nozzles.
My workaround at the time (since it was a Bambu Studio error/bug) was to slice and send the job to the printer, then start the print either from Handy or directly from the printer’s screen; that might work for your situation as well.
Since this was recorded with H2D of course you can’t hear that the toolhead fan doesn’t spin up correctly before using the poop shoot but at least the several homing and three bed levelling are visible (I added chapter markings in the video description).
Like I mentioned earlier, with the new H2D start code that was introduced in 2.5.0 when setting bed levelling to automatic it does at least two times bed levelling, and sometimes three times bed levelling (but not always).
This print is done with a single color Bambu PLA using the right hotend via AMS 2 Pro.
0:00 Init begin
0:13 Homing toolhead (1st time)
1:04 Homing bed (1st time)
4:40 Homing toolhead (2nd time)
5:00 Homing bed (2nd time)
5:07 Bed levelling (1st time)
5:43 Homing toolhead (3rd time)
6:01 Homing bed (3rd time)
6:09 Bed levelling (2nd time)
6:38 Homing toolhead (4th time)
6:56 Homing bed (4th time)
7:04 Bed levelling (3rd time)
8:08 Print begin
I don’t think it has anything to do with BS, I’m also on 2.5.0 and don’t have this. It’s more like it has detected twice a problem with bed leveling so it redoes it from square one with a homing. It’s either a false detection due to a faulty sensor or a real one. Don’t you have a piece of filament stuck beliw the plate or on the bed?
Apart from BS upgrade have you upgraded the firmware by any chance? If nothing obvious is with your bed or plate, I would do a factory reset but you can try redoing a bed calibration prior to see if it solves it
Nope. And Nope.
This started with 2.5.0. Might be coincidence but I never seen my printer doing bed levelling three times before 2.5.0. And on the video it’s not the only time that happened after 2.5.0.
So coincidence is very unlikely.
The G-code around G28 / G29 changed between the start G-code that came with 2.4 (dated 20251022) and 2.5 (dated 20260116).
Unfortunately Bambu doesn’t provide public documentation for their G-code so it’s impossible for me to narrow down the issues. Even G28/G29 are used in a “non-standard” way (“standard” means according to Klipper/Marlin specs).
I wouldn’t really call what Bambu does with G-code “non‑standard” in the strict sense. In practice, no 3D printer vendor runs a pure, universal “standard” anyway – every firmware has its own G-code flavor and wraps the common commands with vendor‑specific logic.
That’s true for Marlin, Klipper, RepRapFirmware, Prusa’s Buddy firmware and also for Bambu: they all interpret and extend the same core commands in slightly different ways, which is exactly why slicers even have a “G-code flavor” setting in the first place.
The interesting part here, to me, isn’t that Bambu does something unique around homing/leveling – that’s completely normal – but that your H2D is running the leveling routine three times. From my experience, that kind of repeated probing is more likely a reaction to bad probe data (e.g. a marginal or failing sensor) than a sign that the G-code or firmware suddenly became “non‑standard”.
For what it’s worth, I’ve already had to replace the right Eddy sensor twice on my H2D, and a third replacement is currently on the way. That pattern makes me even more inclined to suspect intermittent sensor issues when I see repeated leveling or recalibration behavior, rather than assuming the G-code itself is at fault.
Could be the case but my 1st layers are close to perfect. So the data quality of the sensor can’t be too bad b/c it’s not that easy to achieve a close to flawless first layer.
I did put “standard” in quotes, knowing that there is no such a standard.
But Marlin, Klipper, Prusa use all kind of the same flavor and they are in most part interchangeable. And they all provide documentation, available for the public.
In no way I meant that Bambu’s usage of “non-standard” G-code (again, quotes here) is the reason for the strange init behaviour and honestly, I don’t read that from my last post.
What I wanted to say is that I simply can’t troubleshoot myself due to the G-code being “non-standard” and due to lack of documentation.
Otherwise I wouldn’t even bother posting that here as a question (or to-do-list for Bambu’s team) and I’d rather provide a G-code w/o the mentioned issues. Again, I can’t.
But since there are some critical questions to my post overall and I would probably ask the same if I wasn’t the originator of this thread I’ll run two simple identical prints, one with 2.4 and one with 2.5.
Maybe I can add the “solved” flag to this post then.
