[GH-ISSUE #1192] [Bug]: X2D + FTS: Bambuddy-launched prints route to wrong nozzle

BreizhHardware commented

2026-05-07 00:14:29 +02:00

Owner

Originally created by @mkavalecz on GitHub (May 2, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1192

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

Sometimes the prints start on the incorrect nozzle while printing with a filament track switch.

"Our project_file MQTT command is missing the per-filament nozzle/extruder routing fields that Studio sends for FTS-equipped X2Ds. Without those, the X2D defaults to one nozzle (right, in your case) regardless of the slicer's intent." as described by @maziggy in the comments of #1162

Expected Behavior

Prints should always start on the correct nozzle.

Steps to Reproduce

Start a print from Bambuddy while using the filament track switch.

Printer Model

X2D

Bambuddy Version

dev branch, commit 592ec44

SpoolBuddy Version

No response

Printer Firmware Version

01.01.00.00

Installation Method

Manual (git clone)

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

bambuddy-support-20260502-140850.zip

Screenshots

No response

Additional Context

No response

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @mkavalecz on GitHub (May 2, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1192 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description Sometimes the prints start on the incorrect nozzle while printing with a filament track switch. "Our project_file MQTT command is missing the per-filament nozzle/extruder routing fields that Studio sends for FTS-equipped X2Ds. Without those, the X2D defaults to one nozzle (right, in your case) regardless of the slicer's intent." as described by @maziggy in the comments of #1162 ### Expected Behavior Prints should always start on the correct nozzle. ### Steps to Reproduce Start a print from Bambuddy while using the filament track switch. ### Printer Model X2D ### Bambuddy Version dev branch, commit 592ec44 ### SpoolBuddy Version _No response_ ### Printer Firmware Version 01.01.00.00 ### Installation Method Manual (git clone) ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package [bambuddy-support-20260502-140850.zip](https://github.com/user-attachments/files/27302300/bambuddy-support-20260502-140850.zip) ### Screenshots _No response_ ### Additional Context _No response_ ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled

BreizhHardware

2026-05-07 00:14:29 +02:00

closed this issue
added the
bug

wontfix
labels

BreizhHardware commented

2026-05-07 00:14:30 +02:00

Author

Owner

@maziggy commented on GitHub (May 2, 2026):

Thanks for the bundle — I dug through it. Two things:

The project_file payload captured in your log (External project_file payload: ...) is from a Studio-launched print already, not Bambuddy. That's exactly what I need — Bambuddy logs full Studio payloads at INFO when it sees them go through the request topic, no mosquitto needed.
But that print was single-filament (ams_mapping: [0]), so it tells me nothing about per-filament nozzle routing. I need to see how Studio formats the payload when it's actively routing different filaments to different nozzles via the FTS — that's the field Bambuddy is missing.

Could you do two short test prints from BambuStudio (not Bambuddy) and send a fresh support bundle for each:

Test A — both nozzles in use. A small dual-color model (any 5-min calibration cube with side text in a contrasting filament works), with the two filaments deliberately assigned to different nozzles in Studio's filament panel. Press print → wait until printer ACKs → grab support bundle.
Test B — single nozzle. Same model, same two filaments, both routed to the same nozzle. Same procedure, fresh bundle.

The key log line in each will be External project_file payload: {...} near the start of the print — that's the Studio wire format I need to diff. Once I see what changes between A and B, the patch to _send_print_command is local.

@maziggy commented on GitHub (May 2, 2026): Thanks for the bundle — I dug through it. Two things: 1. The `project_file` payload captured in your log (`External project_file payload: ...`) is from a Studio-launched print already, not Bambuddy. That's exactly what I need — Bambuddy logs full Studio payloads at INFO when it sees them go through the request topic, no mosquitto needed. 2. **But** that print was single-filament (`ams_mapping: [0]`), so it tells me nothing about per-filament nozzle routing. I need to see how Studio formats the payload when it's actively routing different filaments to different nozzles via the FTS — that's the field Bambuddy is missing. Could you do two short test prints **from BambuStudio** (not Bambuddy) and send a fresh support bundle for each: - **Test A — both nozzles in use.** A small dual-color model (any 5-min calibration cube with side text in a contrasting filament works), with the two filaments deliberately assigned to *different* nozzles in Studio's filament panel. Press print → wait until printer ACKs → grab support bundle. - **Test B — single nozzle.** Same model, same two filaments, both routed to the *same* nozzle. Same procedure, fresh bundle. The key log line in each will be `External project_file payload: {...}` near the start of the print — that's the Studio wire format I need to diff. Once I see what changes between A and B, the patch to `_send_print_command` is local.

BreizhHardware commented

2026-05-07 00:14:30 +02:00

Author

Owner

@mkavalecz commented on GitHub (May 2, 2026):

Ah, sorry, I didn't realise that a single-filament print will not give you what you need, but that sounds completely valid.
I'll do the test as recommended and get back to you, but the print I just started takes around ~13 hours, so realistically speaking you can expect my response with the new logs tomorrow. (unless the print fails for some reason, in which case I can do the test sooner.)

One small note though: the print I mentioned earlier in #1162, which was routed to the wrong nozzle, was also a single-filament print.

@mkavalecz commented on GitHub (May 2, 2026): Ah, sorry, I didn't realise that a single-filament print will not give you what you need, but that sounds completely valid. I'll do the test as recommended and get back to you, but the print I just started takes around ~13 hours, so realistically speaking you can expect my response with the new logs tomorrow. (unless the print fails for some reason, in which case I can do the test sooner.) One small note though: the print I mentioned earlier in #1162, which was routed to the wrong nozzle, was also a single-filament print.

BreizhHardware commented

2026-05-07 00:14:30 +02:00

Author

Owner

@mkavalecz commented on GitHub (May 3, 2026):

Test A:

2026-05-03 13:47:58,569 INFO [backend.app.services.bambu_mqtt] [-] [[SERIAL]] External project_file payload: {"ams_mapping": [1, 0], "ams_mapping2": [{"ams_id": 0, "slot_id": 1}, {"ams_id": 0, "slot_id": 0}], "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": "Cube + Cube.gcode.3mf", "flow_cali": false, "layer_inspect": true, "md5": "BCF8FEA788082C764F3C8CD977481C0B", "nozzle_offset_cali": 2, "param": "Metadata/plate_1.gcode", "profile_id": "0", "project_id": "0", "sequence_id": "20001", "subtask_id": "0", "subtask_name": "Cube + Cube", "task_id": "0", "timelapse": true, "url": "brtc://emmc/Cube + Cube.gcode.3mf", "use_ams": true, "vibration_cali": false}

Test B:

2026-05-03 13:54:42,244 INFO [backend.app.services.bambu_mqtt] [-] [[SERIAL]] External project_file payload: {"ams_mapping": [1, 0], "ams_mapping2": [{"ams_id": 0, "slot_id": 1}, {"ams_id": 0, "slot_id": 0}], "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": "Cube + Cube.gcode.3mf", "flow_cali": false, "layer_inspect": true, "md5": "A3FC355AE71FF389797E2DB23308701A", "nozzle_offset_cali": 2, "param": "Metadata/plate_1.gcode", "profile_id": "0", "project_id": "0", "sequence_id": "20002", "subtask_id": "0", "subtask_name": "Cube + Cube", "task_id": "0", "timelapse": true, "url": "brtc://emmc/Cube + Cube.gcode.3mf", "use_ams": true, "vibration_cali": false}

Support zip containing both:

bambuddy-support-20260503-135626.zip

I don't think this will give you the answer you're looking for though, because both project_file logs seem to be the same.

@mkavalecz commented on GitHub (May 3, 2026): Test A: <img width="678" height="645" alt="Image" src="https://github.com/user-attachments/assets/b63073bf-3010-4e67-8b56-462bfe58ce94" /> ``` 2026-05-03 13:47:58,569 INFO [backend.app.services.bambu_mqtt] [-] [[SERIAL]] External project_file payload: {"ams_mapping": [1, 0], "ams_mapping2": [{"ams_id": 0, "slot_id": 1}, {"ams_id": 0, "slot_id": 0}], "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": "Cube + Cube.gcode.3mf", "flow_cali": false, "layer_inspect": true, "md5": "BCF8FEA788082C764F3C8CD977481C0B", "nozzle_offset_cali": 2, "param": "Metadata/plate_1.gcode", "profile_id": "0", "project_id": "0", "sequence_id": "20001", "subtask_id": "0", "subtask_name": "Cube + Cube", "task_id": "0", "timelapse": true, "url": "brtc://emmc/Cube + Cube.gcode.3mf", "use_ams": true, "vibration_cali": false} ``` Test B: <img width="685" height="642" alt="Image" src="https://github.com/user-attachments/assets/6396e984-a13b-4fc1-8376-1aef1a2ba71b" /> ``` 2026-05-03 13:54:42,244 INFO [backend.app.services.bambu_mqtt] [-] [[SERIAL]] External project_file payload: {"ams_mapping": [1, 0], "ams_mapping2": [{"ams_id": 0, "slot_id": 1}, {"ams_id": 0, "slot_id": 0}], "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": "Cube + Cube.gcode.3mf", "flow_cali": false, "layer_inspect": true, "md5": "A3FC355AE71FF389797E2DB23308701A", "nozzle_offset_cali": 2, "param": "Metadata/plate_1.gcode", "profile_id": "0", "project_id": "0", "sequence_id": "20002", "subtask_id": "0", "subtask_name": "Cube + Cube", "task_id": "0", "timelapse": true, "url": "brtc://emmc/Cube + Cube.gcode.3mf", "use_ams": true, "vibration_cali": false} ``` Support zip containing both: [bambuddy-support-20260503-135626.zip](https://github.com/user-attachments/files/27317247/bambuddy-support-20260503-135626.zip) I don't think this will give you the answer you're looking for though, because both project_file logs seem to be the same.

BreizhHardware commented

2026-05-07 00:14:30 +02:00

Author

Owner

@maziggy commented on GitHub (May 3, 2026):

Wait for the next daily. I've completely rewritten the virtual printer function. It now has also full printer access - so ou can sync the slicer.

@maziggy commented on GitHub (May 3, 2026): Wait for the next daily. I've completely rewritten the virtual printer function. It now has also full printer access - so ou can sync the slicer.

BreizhHardware commented

2026-05-07 00:14:30 +02:00

Author

Owner

@mkavalecz commented on GitHub (May 3, 2026):

I've seen that you fixed that issue, thank you.
These prints did not involve the virtual printer in any way, did you also find something that might fix the nozzle routing?
I didn't see anything noteworthy in the logs, but I don't have the background knowledge that you do.

@mkavalecz commented on GitHub (May 3, 2026): I've seen that you fixed that issue, thank you. These prints did not involve the virtual printer in any way, did you also find something that might fix the nozzle routing? I didn't see anything noteworthy in the logs, but I don't have the background knowledge that you do.

BreizhHardware commented

2026-05-07 00:14:31 +02:00

Author

Owner

@maziggy commented on GitHub (May 4, 2026):

Sorry, mixed up the issues.

@maziggy commented on GitHub (May 4, 2026): Sorry, mixed up the issues.

BreizhHardware commented

2026-05-07 00:14:31 +02:00

Author

Owner

@maziggy commented on GitHub (May 4, 2026):

Looking at your A/B tests properly: you're right that the two payloads are nearly identical. Only md5 (different sliced files) and sequence_id differ. That actually rules out my original hypothesis — Studio doesn't carry per-filament nozzle routing in project_file at all. The tool-routing must be inside the 3MF gcode (T0/T1 tool-change commands the slicer encodes per object), not in the MQTT command.

Comparing your Studio payload against what Bambuddy sends, the only field-level differences I can see are auto_bed_leveling, extrude_cali_flag, bed_type, and the task-identity fields — none are nozzle related.

I think we've been chasing the wrong shape. You mentioned earlier that the wrong-nozzle bug also repros on single-filament prints (the original #1162 case). The right diagnostic is comparing single-filament Studio dispatch vs single-filament Bambuddy dispatch of the same 3MF, since that isolates "what Bambuddy's send does that Studio's doesn't" with the bug actively reproducing rather than against a model that probably routes correctly anyway.

Could you do this:

Pick a single-filament 3MF that you've previously seen Bambuddy route to the wrong nozzle (or any single-filament file whose slicer-intended nozzle you know — e.g., explicitly assign the filament to the left nozzle in Studio's filament panel, slice, save the 3MF).
Run A — print it directly from Studio. Wait for the printer to ACK / start moving. Note which nozzle activates.
Run B — same 3MF, dispatched from Bambuddy. Note which nozzle activates.
Grab a support bundle covering both runs.

The two External project_file payload log lines should be byte-comparable (same file = same md5, same plate, same ams_mapping). Anything that differs between the Studio-correct-nozzle case and the Bambuddy-wrong-nozzle case is the bug.

If A also routes to the wrong nozzle, then the issue isn't Bambuddy at all — it's the 3MF / Studio side, and we'll need a different angle.

Thanks for your patience on this one — and again, sorry for the misdirected reply earlier.

@maziggy commented on GitHub (May 4, 2026): Looking at your A/B tests properly: you're right that the two payloads are nearly identical. Only md5 (different sliced files) and sequence_id differ. That actually rules out my original hypothesis — Studio doesn't carry per-filament nozzle routing in project_file at all. The tool-routing must be inside the 3MF gcode (T0/T1 tool-change commands the slicer encodes per object), not in the MQTT command. Comparing your Studio payload against what Bambuddy sends, the only field-level differences I can see are auto_bed_leveling, extrude_cali_flag, bed_type, and the task-identity fields — none are nozzle related. I think we've been chasing the wrong shape. You mentioned earlier that the wrong-nozzle bug also repros on single-filament prints (the original #1162 case). The right diagnostic is comparing single-filament Studio dispatch vs single-filament Bambuddy dispatch of the same 3MF, since that isolates "what Bambuddy's send does that Studio's doesn't" with the bug actively reproducing rather than against a model that probably routes correctly anyway. Could you do this: 1. Pick a single-filament 3MF that you've previously seen Bambuddy route to the wrong nozzle (or any single-filament file whose slicer-intended nozzle you know — e.g., explicitly assign the filament to the left nozzle in Studio's filament panel, slice, save the 3MF). 2. Run A — print it directly from Studio. Wait for the printer to ACK / start moving. Note which nozzle activates. 3. Run B — same 3MF, dispatched from Bambuddy. Note which nozzle activates. 4. Grab a support bundle covering both runs. The two External project_file payload log lines should be byte-comparable (same file = same md5, same plate, same ams_mapping). Anything that differs between the Studio-correct-nozzle case and the Bambuddy-wrong-nozzle case is the bug. If A also routes to the wrong nozzle, then the issue isn't Bambuddy at all — it's the 3MF / Studio side, and we'll need a different angle. Thanks for your patience on this one — and again, sorry for the misdirected reply earlier.

BreizhHardware commented

2026-05-07 00:14:31 +02:00

Author

Owner

@mkavalecz commented on GitHub (May 6, 2026):

I don't think following these steps would help us immediately, because after you made the changes to allow selecting the filament mapping, I did have a few successful prints (started from Bambuddy), before one of them went to the wrong nozzle.

I'm pretty sure even if I try these steps, both prints would normally start on the correct nozzle. I have no idea what is the exact trigger that causes the issue to appear, but it definitely doesn't happen always, otherwise all my prints started from Bambuddy would have been bad, and that was not the case.

I'm sorry to say, but I've lost the will to go forward with the debugging for now.
It's not about patience, I do have that, it's just that I have extremely limited free time these days.
I've shelved the idea of using Bambuddy, I currently value stability more than features, that's why I got a Bambu printer.
I'll keep Bambuddy as a way of additional monitoring, but I won't use the archive, or start prints from it.

If I'm honest, I'm still debating if I should or shouldn't use the track switch itself too.
While the convenience it gives is nice, in a lot of scenarios, it increases the print time drastically, and it also has limitations regarding filament support.
If I ditch the FTS, and/or someone else helps you debug this issue, I might give Bambuddy another chance in the future.

@mkavalecz commented on GitHub (May 6, 2026): I don't think following these steps would help us immediately, because after you made the changes to allow selecting the filament mapping, I **did** have a few successful prints (started from Bambuddy), before one of them went to the wrong nozzle. I'm pretty sure even if I try these steps, both prints would normally start on the correct nozzle. I have no idea what is the exact trigger that causes the issue to appear, but it definitely doesn't happen always, otherwise all my prints started from Bambuddy would have been bad, and that was not the case. I'm sorry to say, but I've lost the will to go forward with the debugging for now. It's not about patience, I do have that, it's just that I have extremely limited free time these days. I've shelved the idea of using Bambuddy, I currently value stability more than features, that's why I got a Bambu printer. I'll keep Bambuddy as a way of additional monitoring, but I won't use the archive, or start prints from it. If I'm honest, I'm still debating if I should or shouldn't use the track switch itself too. While the convenience it gives is nice, in a lot of scenarios, it increases the print time drastically, and it also has limitations regarding filament support. If I ditch the FTS, and/or someone else helps you debug this issue, I might give Bambuddy another chance in the future.

BreizhHardware commented

2026-05-07 00:14:31 +02:00

Author

Owner

@maziggy commented on GitHub (May 6, 2026):

Fair enough. I'm sure someone else with a FTS switch will come up.

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (May 6, 2026): Fair enough. I'm sure someone else with a FTS switch will come up. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

Rows
Columns

[GH-ISSUE #1192] [Bug]: X2D + FTS: Bambuddy-launched prints route to wrong nozzle #864

Component

Bug Description

Expected Behavior

Steps to Reproduce

Printer Model

Bambuddy Version

SpoolBuddy Version

Printer Firmware Version

Installation Method

Operating System

Relevant Logs / Support Package

Screenshots

Additional Context

Checklist