mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-05-09 08:25:54 +02:00
[GH-ISSUE #318] [Bug]: AMS mapping for Left Nozzle failing on H2D Pro #201
Labels
No labels
A1
automated
automated
bug
bug
Closed due to inactivity
contrib
dependencies
dependencies
duplicate
enhancement
feedback
hold
invalid
Notes
P1S
pull-request
security
ThumbsUp
user-report
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/bambuddy-maziggy-1#201
Loading…
Add table
Add a link
Reference in a new issue
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?
Originally created by @cimdDev on GitHub (Feb 10, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/318
Originally assigned to: @maziggy on GitHub.
Bug Description
Printing a dual- or single-nozzle job using the left nozzle results in the error:
"Failed to get AMS mapping table". Prints that use only the right nozzle start as expected.
Expected Behavior
The print command sent from Bambuddy should correctly assign the left and right nozzles as specified in the sliced file and start the print without errors.
Steps to Reproduce
Printer Model
H2D Pro
Bambuddy Version
0.1.9b
Printer Firmware Version
01.01.00.00
Installation Method
Manual (git clone)
Operating System
Linux (Ubuntu/Debian)
Relevant Logs / Support Package
Screenshots
bambuddy-support-20260210-110949.zip
Additional Context
The right nozzle uses AMS 2 Pro and the left nozzle uses AMS HT.
Checklist
@maziggy commented on GitHub (Feb 10, 2026):
That's interesting. Another H2D Pro user reported that everything is working.
Anyway, let me check your logs.
@maziggy commented on GitHub (Feb 10, 2026):
Your debug logs don't contain an actual print attempt - just periodic status updates. So I cannot see what's happening when you start a print. Beside of that I cannot see any errors in your logs.
@cadtoolbox can you confirm this bug?
@cimdDev commented on GitHub (Feb 10, 2026):
I retried two print attempts and both were failing.
bambuddy-support-20260210-122634.zip
2026-02-10 12:23:43,562 INFO [backend.app.services.bambu_mqtt] [2398BA570300343] Sending print command: {"print": {"sequence_id": "20000", "command": "project_file", "param": "Metadata/plate_1.gcode", "url": "ftp://TC83 H2D CubeTest_L black.3mf", "file": "TC83 H2D CubeTest_L black.3mf", "md5": "", "bed_type": "auto", "timelapse": 0, "bed_leveling": 1, "auto_bed_leveling": 1, "flow_cali": 0, "vibration_cali": 1, "layer_inspect": 0, "use_ams": true, "cfg": "0", "extrude_cali_flag": 0, "extrude_cali_manual_mode": 0, "nozzle_offset_cali": 2, "subtask_name": "TC83 H2D CubeTest_L black", "profile_id": "0", "project_id": "0", "subtask_id": "0", "task_id": "0", "ams_mapping": [512], "ams_mapping2": [{"ams_id": 255, "slot_id": 1}]}}
@cadtoolbox commented on GitHub (Feb 10, 2026):
I'll test this morning with a few more AMS varieties per print. I'll send whatever errors I capture.
@cimdDev commented on GitHub (Feb 10, 2026):
This is the mqttx for the same print successfully started from bambu studio:
{
"print": {
"ams_mapping": [
128,
-1
],
"ams_mapping2": [
{
"ams_id": 128,
"slot_id": 0
},
{
"ams_id": 255,
"slot_id": 255
}
],
"auto_bed_leveling": 2,
"bed_leveling": false,
"bed_type": "textured_plate",
"cfg": "0",
"command": "project_file",
"extrude_cali_flag": 2,
"extrude_cali_manual_mode": 0,
"file": "TC83 H2D CubeTest.gcode.3mf",
"flow_cali": false,
"layer_inspect": true,
"md5": "416F8CFD655BE651ADA212C9C529658A",
"nozzle_offset_cali": 2,
"param": "Metadata/plate_1.gcode",
"profile_id": "0",
"project_id": "0",
"sequence_id": "20002",
"subtask_id": "0",
"subtask_name": "TC83 H2D CubeTest",
"task_id": "0",
"timelapse": true,
"url": "ftp://TC83 H2D CubeTest.gcode.3mf",
"use_ams": true,
"vibration_cali": false
}
}
@maziggy commented on GitHub (Feb 10, 2026):
AFAIK @cadtoolbox has only tested with "normal" AMS devices.
Anyway, found the problem. The slot id calculation for AMS-HT devices was wrong.
Fixed in branch 0.1.9b. Please let me know if it works now.
If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!
@cimdDev commented on GitHub (Feb 10, 2026):
this is the mqttx for a dual nozzle print started from Bambustudio. left nozzle black and right nozzle white:
{
"print": {
"ams_mapping": [
128,
2
],
"ams_mapping2": [
{
"ams_id": 128,
"slot_id": 0
},
{
"ams_id": 0,
"slot_id": 2
}
],
"auto_bed_leveling": 2,
"bed_leveling": false,
"bed_type": "textured_plate",
"cfg": "0",
"command": "project_file",
"extrude_cali_flag": 2,
"extrude_cali_manual_mode": 0,
"file": "TC83 H2D ext Cube Test LR.gcode.3mf",
"flow_cali": false,
"layer_inspect": true,
"md5": "CC507DFC1D73ACA81F63B8564E456734",
"nozzle_offset_cali": 2,
"param": "Metadata/plate_3.gcode",
"profile_id": "0",
"project_id": "0",
"sequence_id": "20003",
"subtask_id": "0",
"subtask_name": "TC83 H2D ext Cube Test LR",
"task_id": "0",
"timelapse": true,
"url": "ftp://TC83 H2D ext Cube Test LR.gcode.3mf",
"use_ams": true,
"vibration_cali": false
}
}
this is the mqtt report from the printer after print start:
mqtt_H2D_report.json
I hope this helps to figure out the AMS Id mappings
@cimdDev commented on GitHub (Feb 10, 2026):
I will try with the new changes in 0.1.9b
@cadtoolbox commented on GitHub (Feb 10, 2026):
I had a failure on a dual nozzle print as well. I think it's related to nozzle temp. My logs attached:
bambuddy-support-20260210-090533.zip
DualNozzlePrintH2D-MQTT.zip
@maziggy This failure was still using only normal AMS's. I never tested a dual nozzle print prior.
@maziggy commented on GitHub (Feb 10, 2026):
For the normal H2D it's working. Using it on a daily basis.
Let's find the differences.
@maziggy commented on GitHub (Feb 10, 2026):
Analyzed the logs and MQTT dump from @cadtoolbox. This failure is unrelated to the AMS mapping:
This is a printer-side spaghetti detection false positive, not a Bambuddy AMS mapping issue. The AI detection can be toggled in the printer's settings or via layer_inspect in print options.
@cadtoolbox Can you confirm whether the spaghetti detection was actually a true positive (actual print failure) or a false positive?
@cimdDev commented on GitHub (Feb 10, 2026):
the AMS ID mapping issue in the print command appears to be fixed, but there is still an edge case where invalid filament-to-nozzle assignments is accepted. I swapped the spools between the ams. the only allowed mapping should be like thsi:
in bambuddy I started the print like this:
this prints successfully but in the wrong colors
Swapped or incorrect materials may cause failures when different materials settings are used for the wrong materials.
@maziggy commented on GitHub (Feb 10, 2026):
Don't get it. Wrong colors means swapped colors? Black is White and vice versa?
Also I need logs! Cannot debug blindfolded :)
@maziggy commented on GitHub (Feb 10, 2026):
Ah wait...
Did you clicked Re-read in filament mapping section?
@cimdDev commented on GitHub (Feb 10, 2026):
I am not sure my above statment is correct. I will test more tomorrow with different materials and provide logs. For sure the AMS id in the print command is fixed and does not trigger "Failed to get AMS mapping table" anymore. The prints starts successfully.
My understanding is just that left/right nozzle usage in the G-code is fixed by toolchange commands. Therefore:
Left nozzle should only allow mapping to left AMS HT
Right nozzle should only allow mapping to right AMS 2 slots
Maybe I am wrong on this. At least this is the case in bambu studio. I will do more tests with swapped nozzle assignments.
Since the original issue with the print command is resolved, you can close this one if you like. I will reopen or create a new one if needed. thanks
@maziggy commented on GitHub (Feb 10, 2026):
Perfect. Please let me know your test results!
If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!
@cadtoolbox commented on GitHub (Feb 10, 2026):
@maziggy I feel like the spaghetti detection was correct but only caused by Bambuddy. Studio send of the same print has no issues. This was the same behavior previously fixed for single nozzle prints on the H2D Pro.
I'm looking through logs to try to find any differences.
@cadtoolbox commented on GitHub (Feb 12, 2026):
@maziggy Here's a side-by-side comparison of sending dual nozzle prints using an H2D Pro from bambu studio and bambuddy:
It looks like Bambuddy is not sending the AMS mappings like Studio does.
Missing:
"ams_mapping": [ 8, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ]Missing:
"ams_mapping2": [ { "ams_id": 2, "slot_id": 0 }, { "ams_id": 0, "slot_id": 1 }, { "ams_id": 255, "slot_id": 255 }, ... ]Bambuddy_Start.json
BambuStudio_Start.json
@maziggy commented on GitHub (Feb 13, 2026):
Should be fixed in branch 0.2.0b. Please let me know....
@cimdDev commented on GitHub (Feb 17, 2026):
There is still an issue with how Bambuddy handles nozzle assignments for dual‑nozzle, multi‑material prints.
I tested a sliced file that contains:
In Bambu Studio, the gcode.3mf is sliced with the materials grouped like this (LL | RR) I sliced the file for a setup with an AMS for the left and an AMS for the right extruder.
But in Bambuddy, the grouping appears incorrectly (LL | LR):
Incorrect Nozzle Mapping
Bambuddy currently allows assigning a right‑nozzle material to the left extruder, and vice versa.
This should not be allowed, because:
Allowing these invalid mappings leads to print failure. The print begins but fails on the first toolchange with the error:
“position of left hotend is abnormal”
Expected Behavior
Additional Clarification
In my setup, I do not have an AMS 2 connected to the left extruder.
The error occurred during a dual‑color print (one left, one right) where I intentionally swapped the assignments to an impossible nozzle mapping to test the behavior.
@maziggy commented on GitHub (Feb 19, 2026):
Please try again with latest beta release 0.2.1b.
@cimdDev commented on GitHub (Feb 19, 2026):
It seems to be fixed in 0.2.1b.
I will do some more test cases, If I find an issue I would reopen or submit a new one.
thanks!