viewit/OrcaSlicer-KX
5
4
Fork 1
Code Issues 2 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Kobra X: bed heats to highest project temp during G9111 auto-leveling instead of active filament's temp #4

New Issue
Closed
opened 2026-07-19 19:17:32 +02:00 by viewit · 1 comment
viewit commented 2026-07-19 19:17:32 +02:00
Owner
Copy Link

Description

Related to KX-Bridge-Release#96 (reported by @Blaim). Root-caused after tracing through the bridge and this repo's Kobra X machine profile — this is not a KX-Bridge bug, it's here.

Root Cause

resources/profiles/Anycubic/machine/Anycubic Kobra X 0.4 nozzle.json → machine_start_gcode:

G9111 bedTemp=[first_layer_bed_temperature] extruderTemp=[first_layer_temperature[initial_tool]]

G9111 is Anycubic's fused heat+auto-level macro. [first_layer_bed_temperature] is resolved in GCode::_print_first_layer_bed_temperature() (src/libslic3r/GCode.cpp:4025-4034):

if (m_config.bed_temperature_formula.value == BedTempFormula::btfHighestTemp) {
    bed_temp = get_highest_bed_temperature(true, print);
}
else {
    bed_temp = get_bed_temperature(first_printing_extruder_id, true, print.config().curr_bed_type);
}

bed_temperature_formula defaults to by_highest_temp (PrintConfig.cpp:2591-2598) and is never overridden by any Anycubic profile (confirmed via grep -rl bed_temperature_formula resources/profiles/Anycubic/ → no hits). So [first_layer_bed_temperature] in machine_start_gcode resolves to the highest bed temp across all filaments in the project, not the temp of the filament actually being printed.

The later in-body M140 S<temp> gcode instead uses the correct per-filament/per-extruder value, so it corrects the bed down after leveling — matching the reported behavior (35°C during leveling → 30°C afterward).

Confirmed with a real capture (ziptie_plate(01)_PETG_0.2_8m5s.gcode):

  • G9111 bedTemp=70 ... (highest-temp value across filaments used)
  • M140 S65 ; set bed temperature (correct per-filament first-layer value)

Other Anycubic machine profiles that use classic M140/M190 instead of G9111 (e.g. Kobra 2) are unaffected, since OrcaSlicer detects M140/M190 in custom start gcode and skips its own temperature injection (custom_gcode_sets_temperature() check in the same function) — this only bites profiles using the G9111 fused macro without an explicit M140/M190 anywhere before it.

Upstream precedent: BBL's own machines and SeeMeCNC profiles explicitly set "bed_temperature_formula": "by_first_filament" in their machine JSON (see resources/profiles/BBL/machine/fdm_machine_common.json). Anycubic profiles never set this key and silently inherit the by_highest_temp global default.

Suggested Fix

Add to Anycubic Kobra X 0.4 nozzle.json (and any other Anycubic profile using G9111 in machine_start_gcode):

"bed_temperature_formula": "by_first_filament",

This makes [first_layer_bed_temperature] resolve to the actual printed filament's bed temp, matching what the later M140 command already uses — eliminating the leveling/print temperature mismatch.

Verification steps

  1. Slice a project in OrcaSlicer-KX with ≥2 filaments of different bed temps (even if only one is actually printed/used on the plate).
  2. Compare G9111 bedTemp= value against the later M140 S value in the generated gcode — currently they diverge; after the fix they should match.
  3. Confirm on hardware: bed should hold the sliced first-layer temp throughout leveling, no 35→30°C-style correction afterward.

cc @Blaim for reference — this is being fixed here rather than in KX-Bridge since the bug is in the machine profile / gcode generation, not the bridge itself.

## Description Related to [KX-Bridge-Release#96](https://gitea.it-drui.de/viewit/KX-Bridge-Release/issues/96) (reported by @Blaim). Root-caused after tracing through the bridge and this repo's Kobra X machine profile — this is **not** a KX-Bridge bug, it's here. ## Root Cause `resources/profiles/Anycubic/machine/Anycubic Kobra X 0.4 nozzle.json` → `machine_start_gcode`: ``` G9111 bedTemp=[first_layer_bed_temperature] extruderTemp=[first_layer_temperature[initial_tool]] ``` `G9111` is Anycubic's fused heat+auto-level macro. `[first_layer_bed_temperature]` is resolved in `GCode::_print_first_layer_bed_temperature()` (`src/libslic3r/GCode.cpp:4025-4034`): ```cpp if (m_config.bed_temperature_formula.value == BedTempFormula::btfHighestTemp) { bed_temp = get_highest_bed_temperature(true, print); } else { bed_temp = get_bed_temperature(first_printing_extruder_id, true, print.config().curr_bed_type); } ``` `bed_temperature_formula` defaults to `by_highest_temp` (`PrintConfig.cpp:2591-2598`) and is **never overridden** by any Anycubic profile (confirmed via `grep -rl bed_temperature_formula resources/profiles/Anycubic/` → no hits). So `[first_layer_bed_temperature]` in `machine_start_gcode` resolves to the *highest bed temp across all filaments in the project*, not the temp of the filament actually being printed. The later in-body `M140 S<temp>` gcode instead uses the correct per-filament/per-extruder value, so it corrects the bed down after leveling — matching the reported behavior (35°C during leveling → 30°C afterward). **Confirmed with a real capture** (`ziptie_plate(01)_PETG_0.2_8m5s.gcode`): - `G9111 bedTemp=70 ...` (highest-temp value across filaments used) - `M140 S65 ; set bed temperature` (correct per-filament first-layer value) Other Anycubic machine profiles that use classic `M140`/`M190` instead of `G9111` (e.g. Kobra 2) are unaffected, since OrcaSlicer detects `M140`/`M190` in custom start gcode and skips its own temperature injection (`custom_gcode_sets_temperature()` check in the same function) — this only bites profiles using the `G9111` fused macro without an explicit M140/M190 anywhere before it. Upstream precedent: BBL's own machines and SeeMeCNC profiles explicitly set `"bed_temperature_formula": "by_first_filament"` in their machine JSON (see `resources/profiles/BBL/machine/fdm_machine_common.json`). Anycubic profiles never set this key and silently inherit the `by_highest_temp` global default. ## Suggested Fix Add to `Anycubic Kobra X 0.4 nozzle.json` (and any other Anycubic profile using `G9111` in `machine_start_gcode`): ```json "bed_temperature_formula": "by_first_filament", ``` This makes `[first_layer_bed_temperature]` resolve to the actual printed filament's bed temp, matching what the later `M140` command already uses — eliminating the leveling/print temperature mismatch. ## Verification steps 1. Slice a project in OrcaSlicer-KX with ≥2 filaments of different bed temps (even if only one is actually printed/used on the plate). 2. Compare `G9111 bedTemp=` value against the later `M140 S` value in the generated gcode — currently they diverge; after the fix they should match. 3. Confirm on hardware: bed should hold the sliced first-layer temp throughout leveling, no 35→30°C-style correction afterward. cc @Blaim for reference — this is being fixed here rather than in KX-Bridge since the bug is in the machine profile / gcode generation, not the bridge itself.
👍 1 ❤️ 1
viewit commented 2026-07-20 16:03:31 +02:00
Author
Owner
Copy Link

Fixed in v2.4.2-kx1 — added "bed_temperature_formula": "by_first_filament" to the Kobra X machine profile. The G9111 macro now heats to the correct per-filament bed temperature throughout auto-leveling.

Release: https://gitea.it-drui.de/viewit/OrcaSlicer-KX/releases/tag/v2.4.2-kx1

Fixed in v2.4.2-kx1 — added `"bed_temperature_formula": "by_first_filament"` to the Kobra X machine profile. The G9111 macro now heats to the correct per-filament bed temperature throughout auto-leveling. Release: https://gitea.it-drui.de/viewit/OrcaSlicer-KX/releases/tag/v2.4.2-kx1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
viewit
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: viewit/OrcaSlicer-KX#4
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?