Major bug in studio 2.5.3/2.6.0, fail to pre-heat left nzl (solved with beta FW)

Bambu Lab H2 Series
21

BS 2.5.3.61. (25characters)

22

I have the same issue on my H2C. Reported in github.

23

Thank you, hope it gets fixed because the improvements of 2.6.0 will be hard to pass when the H2C firmware is updated.

24

I’ve made a side-by-side video of the issue. Both videos start at the same time and stop when the same layer is finished. For this simple one nozzle change it adds 20 seconds to the print!!

3 Likes
25

It happens to me in my H2C but that’s something that should be happening in the H2D too. I wonder why there is no more people complaining about this issue?

26

Because few people print with two nozzles all the time.

27

That’s possible. But printing with a single nozzle wouldn’t defeat the purpose of buying/having a multi-nozzle 3D printer?

28

Good news, the Github issue report has been assigned. Don’t know if it’s because I followed up this morning with a support ticket or if support assistant intervened or because of you guys reporting on github but it’s moving :wink:

4 Likes
29

I’m meaning to go through and compare (diff) the generated g-code from the two versions, but haven’t yet – anyone do this?

I’m having some trouble following what the bottom-line actual issue is… sorry. In the old version it would start heating the left nozzle while the right was still printing? Or at some other time? I get that now it seems to wait to heat until it needs to print, just not sure what it used to do. That left nozzle is like the slow cousin of the family already… hehe.

Can you link the GH issue? I found it once but they get buried quick. Not to be Debbie Downer, but I’m afraid issue assignment means very little over there… most issues get assigned but very few dealt with. :confused:

-Max

30

Yes, I made a comparison. Indeed, the code from the latest version of Studio includes a command to heat the left nozzle at the very end of each layer. However, the heating of the right nozzle is turned on beforehand. This is a bug in the slicer code; it can’t be fixed by adjusting the start, end, and other g-code in printer parameters.

1 Like
31
1 Like
32

Yes I was confident it was in the machine gcode but no change related to it in start or filament change gcode so we cannot temporarily fix it ourselves

33

I received a response to my ticket. From what I could gather from this response is that the issue is known and is related to an incompatibility between studio v2.5.3/2.6 and current H2C firmware. So I guess this issue is specific to H2C and new studio version may behave fine on H2Ds. I wonder what other studio features are impeded when used on H2C…

I guess BL supposedly flagship printer is a lame duck at this stage, not benefitting from the latest improvements implemented on H2S/H2D and not fully compatible to the latest bambu studio releases.

@supportassistant, what is BL doing with that thing? It took 3 years to develop and is now sitting there waiting for a new firmware which does not seem to come, it’s confusing and frustrating. Is it so complicated that we’ll have to wait 3 years between each firmware release? It does not seem your “flagship” printer was even ready for primetime after those 3 years… The worst is with that bug it may even be the slowest printer in the bambu line-up, with a 20 second delay between layers, an H2D will have almost enough time to purge! Will bambu offer a H2C to H2D retro conversion?

1 Like
34

They’ll definitely release new firmware, I think, soon. It’s just that they have a strange and unhealthy practice of releasing Studio with new features and then firmware a little later. The new Studio should be released simultaneously with the firmware, not several weeks later, so that users don’t understand what’s going on.

35

Thanks for carrying the banner on this issue. It is very disappointing to know that I spent $3k+ for the flagship and within a month of purchase there is this bug and also that there is no way to dry and print at the same time like my P2S, even though I purchased a second AMS 2 Pro and two AMS HT units for this H2C.

Perhaps there is a YouTuber who didn’t get a free printer that is willing to speak up.

36

Since I was already digging into the Bambu Studio codebase for other issues, I also traced this regression. Below is a technical analysis showing where the behaviour changed, which commits are involved, and why H2C ended up being affected as well.

Regression: Pre-heating of the idle nozzle no longer reaches print temperature in BambuStudio 2.5.3 on H2C

Summary

Between BambuStudio 2.5.0 and 2.5.3, the pre-heating behavior of the idle nozzle on multi-extruder printers changed in two measurable ways. The pre-heating machinery itself was not removed; it was modified:

  1. The pre-heat target temperature was lowered from the filament’s nominal nozzle_temperature to nozzle_temperature − N, where N = filament_cooling_before_tower (typically 10 °C). The remaining offset is covered by a synchronous M109 at the tool-change point rather than by pre-heating during the preceding idle window.
  2. An M400 synchronization barrier (wait-for-motion-complete) was inserted before the pre-heat M104. This guarantees that heating only begins after all buffered moves have finished, which in practice shifts the M104 command closer to the tool change when it is preceded by a long travel.

Both changes were introduced as part of the work that added X2D support, between 2026-03-25 and 2026-04-08. The H2C is affected because two of the underlying mechanisms are not gated by printer model: the M400 barrier applies unconditionally, and the filament_cooling_before_tower parameter is stored in the H2C filament profiles rather than on the machine.

The combined effect at each right-to-left tool change is an added dwell of approximately the time required to cover the residual temperature delta (≈ 5 – 15 seconds, depending on filament temperature and hotend heating rate). The impact accumulates over the number of tool changes in the print.

Verified evidence chain

All commit hashes below are reachable on the public master branch. Paths and line numbers are as of the release tag v02.06.00.51.

1. 90a782617 — Pre-heat target clamped when a filament switcher is connected

  • Author: xun.zhang, 2026-03-25
  • Title: ENH:[pre-heating] 选料器连接时限制提前升温目标温度为打印温度-20
  • Message: “When the filament switcher is connected, limit the pre-heat target temperature to print_temp − 20. A new project-config field has_filament_switcher is introduced and propagated from device runtime state to GCodeProcessor.”

Code effect (src/libslic3r/GCode/GCodeProcessor.cpp:6390-6392):

if (has_filament_switcher && apply_pre_heating) {
    constexpr float switcher_temp_offset = 20.f;
    target_temp = std::min(target_temp, print_temp - switcher_temp_offset);
}

2. 9e55ba8a1 + a36acaba7 — M400 synchronization barrier added before every pre-heat/cool M104

  • 9e55ba8a1 (wenbing.shao, 2026-03-30, STUDIO-17603) — wipe-tower side
  • a36acaba7 (wenbing.shao, 2026-04-01, STUDIO-17603) — GCode-processor side

src/libslic3r/GCode/WipeTower.cpp:1307:

std::string buffer;
if (wait_for_moves)
    buffer += "M400\n";   // new barrier
buffer += "M104";

src/libslic3r/GCode/GCodeProcessor.cpp:6547:

buffer.emplace_back("M400\n");   // new barrier before pre-heat M104
std::string M104_line = "M104";

M400 blocks the firmware until all queued moves complete. This is technically correct (it prevents the heater from ramping while the toolhead is still moving), but it defers the moment at which the firmware sees the M104. If the pre-heat command previously sat at the beginning of a long travel, it now sits at the end of it.

3. 71a370d72 — Cooling logic intended to be “restricted to X2D”

  • Author: xun.zhang, 2026-04-08
  • Title: FIX: 提前升降温优化
  • Message, item 3: “降温逻辑限定于X2D” (“cooling logic restricted to X2D”)

The implementation gates the clamp on has_mixed_extruder_types, which is true only for machines with different extruder types on the two heads (DirectDrive + Bowden) — i.e. effectively X2D:

// Temporary workaround for X2D: when extruder types are mixed (e.g. DirectDrive + Bowden),
// limit pre-heating target to avoid overshooting on the slower-responding extruder.
bool has_mixed_extruder_types = extruder_types.size() > 1 &&
    std::adjacent_find(extruder_types.begin(), extruder_types.end(),
                       std::not_equal_to<>()) != extruder_types.end();

// X2D temporary workaround: only apply temp offset when extruder types are mixed
if (has_filament_switcher && has_mixed_extruder_types && apply_pre_heating) {
    target_temp = std::min(target_temp, print_temp - switcher_temp_offset);
}

So the −20 °C clamp from change (1) is, by 2.6.0, limited to X2D. H2C does not hit this specific branch. This is correct scoping on the code side.

4. bdd7f26b9 — filament_cooling_before_tower enabled for H2S; the same parameter is present in H2C profiles

  • bdd7f26b9 (xun.zhang, 2026-02-09) introduced "filament_cooling_before_tower": [10, 10] across ≈ 138 H2S filament JSONs.

The same parameter is now present in the H2C filament profiles on master:

resources/profiles/BBL/filament/Bambu ABS @BBL H2C.json:29:    "filament_cooling_before_tower": [
resources/profiles/BBL/filament/Bambu ABS @BBL H2C 0.2 nozzle.json:32:    "filament_cooling_before_tower": [
resources/profiles/BBL/filament/Bambu ABS @BBL H2C 0.6 nozzle.json:29:    "filament_cooling_before_tower": [
resources/profiles/BBL/filament/Bambu ABS @BBL H2C 0.8 nozzle.json:29:    "filament_cooling_before_tower": [
resources/profiles/BBL/filament/Bambu ASA @BBL H2C 0.8 nozzle.json:26:    "filament_cooling_before_tower": [
…

In GCodeProcessor::PreCoolingInjector::process_pre_cooling_and_heating the value is consumed as follows (GCodeProcessor.cpp:6388):

float target_temp = get_nozzle_temp(iter->next_filament_id, false, false,
                                    !iter->ignore_cooling_before_tower);

When filament_cooling_before_tower is non-zero, the pre-heat target is reduced by that amount — unconditionally with respect to the printer model. There is no is_X2D gate here. For an H2C printing Bambu ABS, the pre-heat target becomes print_temp − 10 °C; the last 10 °C must be covered by the synchronous M109 at the tool-change point.

Why the H2C is impacted, even though the workaround was intended for X2D

Two of the three changes above are scoped correctly:

  • Change (1) was scoped to “any machine with a filament switcher” originally, then narrowed to X2D-only via has_mixed_extruder_types in change (3).
  • Change (3) itself uses the correct gate for its stated intent.

The H2C regression comes from:

  • Change (2) — the M400 barrier — which has no machine-model gate at all and applies to every pre-heat command.
  • Change (4) — the filament_cooling_before_tower: [10, 10] values present in the H2C filament profiles. This parameter was designed for hardware that benefits from slightly under-heating the idle nozzle to prevent heat-creep on a slower-responding hotend. Its placement in the filament profile, rather than on the machine, means the value applies to every printer using that filament profile regardless of head configuration.

References

Commit Date Author Role
90a782617 2026-03-25 xun.zhang Introduced pre-heat clamp (later scoped to X2D)
9e55ba8a1 2026-03-30 wenbing.shao Added M400 barrier in wipe tower
a36acaba7 2026-04-01 wenbing.shao Added M400 barrier in GCode processor
71a370d72 2026-04-08 xun.zhang Narrowed the pre-heat clamp to mixed-extruder types
bdd7f26b9 2026-02-09 xun.zhang Enabled filament_cooling_before_tower on H2S (same parameter is now present on H2C)

JIRA ticket cited in the commits: STUDIO-17603.

Relevant source locations (tag v02.06.00.51):

  • src/libslic3r/GCode/GCodeProcessor.cpp:6368-6400 (pre-heat target computation)
  • src/libslic3r/GCode/GCodeProcessor.cpp:6547 (M400 before M104 in the processor)
  • src/libslic3r/GCode/WipeTower.cpp:1307 (M400 before M104 in the wipe-tower writer)
  • resources/profiles/BBL/filament/Bambu * @BBL H2C*.json (filament_cooling_before_tower entries)
1 Like
37

Thank you, very interesting. By the look of it H2D should also be affected but no one has reported it

38

No, since the H2D have the same left and right toolhead, both X2D and H2C have different kind of toolheads. I accidently read the X2D instead of H2D :wink:
That said, their track record does not inspire much confidence. They often develop features with one intended purpose, only for them to cause problems elsewhere.

At times, it gives the impression that they do not fully understand the range of machines they are developing for, and that some parameters are being set more by guesswork than by proper validation.

39

All in all all this does not seem like major coding, I wonder why they did not quickly release a hotfix rather than let it slip unchecked for so long. Changes from jira 17603 seem to have been commited last week. For H2C may be the prime tower cooling is the bigger contributor and if H2D presets are not affected, it may be less noticeable. May be I should try modifying the preset to judge the change

40

I have not looked into that specifically, but you could try adjusting the temperatures in the tower cooling section of the filament settings, perhaps setting them to 0 to see whether that resolves the issue. I do not have an H2C myself, so for now I can only inspect the code.