[GH-ISSUE #1162 ] [Bug]: Filament Mapping doesn&#39;t work with Filament Track Switch #839

bambuddy-support-20260429-105348.zip

Owner

Originally created by @mkavalecz on GitHub (Apr 29, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1162

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

When the Filament Track Switch is installed, the Filament Mapping shows an empty list.

On the printers page, the AMS shows the filaments correctly, and they are also mapped correctly to the spools in the Filaments section.
But when starting/scheduling a print, the Filament Mapping list is empty.

Removing the Filament Track Switch solves the issue instantly, reconnecting the track switch breaks the list on the next printer reconnect.

Note: I'm using an X2D, the "Printer Model" dropdown on GitHub doesn't allow selecting this printer.

Expected Behavior

The installed filaments should be listed.

Steps to Reproduce

Install Filament Track Switch on printer
Try to print/schedule anything

Printer Model

Multiple printers

Bambuddy Version

v0.2.4b1

SpoolBuddy Version

No response

Printer Firmware Version

01.01.00.00

Installation Method

Docker

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

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 (Apr 29, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1162 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description When the [Filament Track Switch](https://eu.store.bambulab.com/products/filament-track-switch) is installed, the Filament Mapping shows an empty list. On the printers page, the AMS shows the filaments correctly, and they are also mapped correctly to the spools in the Filaments section. But when starting/scheduling a print, the Filament Mapping list is empty. Removing the Filament Track Switch solves the issue instantly, reconnecting the track switch breaks the list on the next printer reconnect. Note: I'm using an X2D, the "Printer Model" dropdown on GitHub doesn't allow selecting this printer. ### Expected Behavior The installed filaments should be listed. ### Steps to Reproduce 1. Install Filament Track Switch on printer 2. Try to print/schedule anything ### Printer Model Multiple printers ### Bambuddy Version v0.2.4b1 ### SpoolBuddy Version _No response_ ### Printer Firmware Version 01.01.00.00 ### Installation Method Docker ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package [bambuddy-support-20260429-105348.zip](https://github.com/user-attachments/files/27195422/bambuddy-support-20260429-105348.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

closed this issue
added the
enhancement
label

BreizhHardware commented

Author

Owner

@mkavalecz commented on GitHub (Apr 29, 2026):

@mkavalecz commented on GitHub (Apr 29, 2026): <img width="250" height="131" alt="Image" src="https://github.com/user-attachments/assets/630fd2c9-a94e-4742-b56b-f0167bc2472f" /> <img width="620" height="177" alt="Image" src="https://github.com/user-attachments/assets/4bd7e82f-c606-4ea9-a1f5-07bd1bf2afc1" />

BreizhHardware commented

Author

Owner

@mkavalecz commented on GitHub (Apr 29, 2026):

Full MQTT dump with and without the track switch:
mqtt_with_switch.txt
mqtt_without_switch.txt

Seems like there's a fila_switch entry related to this.

@mkavalecz commented on GitHub (Apr 29, 2026): Full MQTT dump with and without the track switch: [mqtt_with_switch.txt](https://github.com/user-attachments/files/27197559/mqtt_with_switch.txt) [mqtt_without_switch.txt](https://github.com/user-attachments/files/27197560/mqtt_without_switch.txt) Seems like there's a fila_switch entry related to this.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 29, 2026):

Since it's a new device, this is a feature request and not a bug.

First of all you should have a look at your logs and fix your system setup. Looks like your install is messed up. There are lot's of errors.

2026-04-21 14:16:05,981 ERROR [backend.app.services.virtual_printer.manager] Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure t
he data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer'

2026-04-21 14:39:04,268 ERROR [backend.app.services.mqtt_relay] MQTT relay connection failed: Not authorized

2026-04-21 14:50:30,710 WARNING [backend.app.core.encryption] MFA_ENCRYPTION_KEY is not set — TOTP secrets and OIDC client_secrets are stored in plaintext. Generate a key with
: python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"

2026-04-21 20:22:37,064 ERROR [backend.app.services.local_backup] Local backup failed: [Errno 13] Permission denied: '/app/data/backups/bambuddy-backup-20260421-202237.zip'

2026-04-22 23:48:44,177 ERROR [backend.app.services.camera] Chamber image: connection timeout to [IP]:6000
2026-04-22 23:48:44,177 WARNING [backend.app.services.obico_detection] Failed to capture snapshot for printer 1

2026-04-27 16:58:35,464 ERROR [backend.app.services.background_dispatch] Background dispatch job 2 failed: Failed to upload file to printer. Check if SD card is inserted and properly formatted (FAT32/exFAT).
raise RuntimeError(
"Failed to upload file to printer. Check if SD card is inserted and properly formatted (FAT32/exFAT)."
RuntimeError: Failed to upload file to printer. Check if SD card is inserted and properly formatted (FAT32/exFAT).
2026-04-27 16:59:50,316 WARNING [backend.app.api.routes.camera] ffmpeg stderr (stream_id=2-d5277339): [in#0 @ 0x5f8d6819e0c0] Error opening input: Invalid data found when processing input

The AMS info field (a hex bitmask) changes one nibble when the FTS is installed:

  Without FTS: 0x11002103, bits 8-11 = 0x1  ("left extruder")
  With FTS:    0x11002E03, bits 8-11 = 0xE  ("uninitialized")

Bambuddy's MQTT parser treats 0xE as "uninitialized, skip" — matching BambuStudio's reading for transient AMS state at boot. With the FTS installed the printer reports 0xE permanently because the AMS is no longer tied to a specific nozzle (the FTS routes between them), so every slot lands without an extruder assignment. The print modal's filament dropdown filters slots by extruderId === nozzle_id, so the list ends up empty.

Fix: detect FTS via print.device.fila_switch (non-null only when the accessory is installed) and drop the per-extruder filter when it's active.

Three things would help me ship this with confidence — (1) is the high-value one:

Test the fix on actual hardware. The dropdown showing slots is one thing; the print actually routing correctly through the FTS is another. I can post a beta image when ready.
One MQTT dump captured DURING a filament-load with FTS active — so I can see how fila_switch.stat / in / out change and tune the detection.
Confirm your AMS configuration. Bundle shows ams_unit_count=1 — single AMS, or am I misreading?

Side note: X2D is selectable internally but I missed adding it to the issue template. Will fix in passing.

@maziggy commented on GitHub (Apr 29, 2026): Since it's a new device, this is a feature request and not a bug. --- First of all you should have a look at your logs and fix your system setup. Looks like your install is messed up. There are lot's of errors. > 2026-04-21 14:16:05,981 ERROR [backend.app.services.virtual_printer.manager] Cannot create directory /app/data/virtual_printer/uploads: Permission denied. For Docker: ensure t he data volume is writable by the container user. For bare metal: run 'sudo chown -R $(whoami) /app/data/virtual_printer' > 2026-04-21 14:39:04,268 ERROR [backend.app.services.mqtt_relay] MQTT relay connection failed: Not authorized > 2026-04-21 14:50:30,710 WARNING [backend.app.core.encryption] MFA_ENCRYPTION_KEY is not set — TOTP secrets and OIDC client_secrets are stored in plaintext. Generate a key with : python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())" > 2026-04-21 20:22:37,064 ERROR [backend.app.services.local_backup] Local backup failed: [Errno 13] Permission denied: '/app/data/backups/bambuddy-backup-20260421-202237.zip' > 2026-04-22 23:48:44,177 ERROR [backend.app.services.camera] Chamber image: connection timeout to [IP]:6000 > 2026-04-22 23:48:44,177 WARNING [backend.app.services.obico_detection] Failed to capture snapshot for printer 1 > 2026-04-27 16:58:35,464 ERROR [backend.app.services.background_dispatch] Background dispatch job 2 failed: Failed to upload file to printer. Check if SD card is inserted and properly formatted (FAT32/exFAT). raise RuntimeError( "Failed to upload file to printer. Check if SD card is inserted and properly formatted (FAT32/exFAT)." RuntimeError: Failed to upload file to printer. Check if SD card is inserted and properly formatted (FAT32/exFAT). > 2026-04-27 16:59:50,316 WARNING [backend.app.api.routes.camera] ffmpeg stderr (stream_id=2-d5277339): [in#0 @ 0x5f8d6819e0c0] Error opening input: Invalid data found when processing input ----- The AMS `info` field (a hex bitmask) changes one nibble when the FTS is installed: Without FTS: 0x11002103, bits 8-11 = 0x1 ("left extruder") With FTS: 0x11002E03, bits 8-11 = 0xE ("uninitialized") Bambuddy's MQTT parser treats 0xE as "uninitialized, skip" — matching BambuStudio's reading for transient AMS state at boot. With the FTS installed the printer reports 0xE permanently because the AMS is no longer tied to a specific nozzle (the FTS routes between them), so every slot lands without an extruder assignment. The print modal's filament dropdown filters slots by `extruderId === nozzle_id`, so the list ends up empty. Fix: detect FTS via `print.device.fila_switch` (non-null only when the accessory is installed) and drop the per-extruder filter when it's active. Three things would help me ship this with confidence — (1) is the high-value one: 1. Test the fix on actual hardware. The dropdown showing slots is one thing; the print actually routing correctly through the FTS is another. I can post a beta image when ready. 2. One MQTT dump captured DURING a filament-load with FTS active — so I can see how `fila_switch.stat` / `in` / `out` change and tune the detection. 3. Confirm your AMS configuration. Bundle shows ams_unit_count=1 — single AMS, or am I misreading? Side note: X2D is selectable internally but I missed adding it to the issue template. Will fix in passing.

BreizhHardware commented

Author

Owner

@mkavalecz commented on GitHub (Apr 29, 2026):

Thanks again for the fast response!
Sorry, it wasn't my intention to mis-categorise the issue, I only added it as a bug, because the track switch is supposed to work with H2D/H2C too, and those are older, but I guess the track switch itself is new too.

I installed Bambuddy on 4.21 when I only had an A1 printer, and got the X2D on 4.27, so I had a few stumbles to get everything to be correct, but I already fixed all the errors, I used the printer yesterday too, notice how all of these are from <=04.27.

Your notes about the fix for the implementation sound promising, I'm ready to test a beta image whenever you are.
mqtt_during_print.txt
I didn't catch it specifically during the load, but this is how it looks like when a filament is actually loaded, during printing. Is this enough, or should I try specifically while it says loading filament?
I'm waiting for the AMS 2 Pro and AMS HT to be in stock in the Bambu Store to finish the setup, but the Track Switch arrived already, so I installed it in the meantime. So yes, I know this is a weird setup, but I only have 1 AMS for now, it's a temporary situation. :) It was a valid concern on your side though!

@mkavalecz commented on GitHub (Apr 29, 2026): Thanks again for the fast response! Sorry, it wasn't my intention to mis-categorise the issue, I only added it as a bug, because the track switch is supposed to work with H2D/H2C too, and those are older, but I guess the track switch itself is new too. I installed Bambuddy on 4.21 when I only had an A1 printer, and got the X2D on 4.27, so I had a few stumbles to get everything to be correct, but I already fixed all the errors, I used the printer yesterday too, notice how all of these are from <=04.27. 1. Your notes about the fix for the implementation sound promising, I'm ready to test a beta image whenever you are. 2. [mqtt_during_print.txt](https://github.com/user-attachments/files/27201395/mqtt_during_print.txt) I didn't catch it specifically during the load, but this is how it looks like when a filament is actually loaded, during printing. Is this enough, or should I try specifically while it says loading filament? 3. I'm waiting for the AMS 2 Pro and AMS HT to be in stock in the Bambu Store to finish the setup, but the Track Switch arrived already, so I installed it in the meantime. So yes, I know this is a weird setup, but I only have 1 AMS for now, it's a temporary situation. :) It was a valid concern on your side though!

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 29, 2026):

Thanks for the during-print bundle — it gave me everything I needed. Fix is in dev now (will land in the next daily build).

What changed:

Bambuddy now parses print.device.fila_switch from MQTT and exposes it on the printer status. When the FTS is installed, the print modal's per-nozzle filter on the filament dropdown is suppressed — so every loaded AMS slot is selectable for any nozzle's filament, since the FTS routes them.
Slots currently fed into a track get an [L] or [R] badge in the dropdown so you can see where the FTS is currently routing them. Idle slots show no badge — they can be routed on demand.

Single-AMS is fine for testing — that's exactly the configuration in your bundle, and the implementation handles it. Once your AMS 2 Pro and AMS-HT arrive, the same logic should hold (out is the FTS topology, in is the dynamic routing — neither cares how many AMS units are attached). If you do see anything off with multi-AMS routing once it's all assembled, please open a follow-up.

Detection is automatic (no setting), so you'll see the dropdown fill.

Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you.

BTW:

Slots currently fed into a track also get a routing badge in the dropdown — [L] or [R] — so the user can tell at a glance which slot the FTS is currently routing where (idle slots get no badge: they can be routed to either extruder on demand).

Can you please send me a screenshot so that I can check how it looks like? ;) Don't have a FTS.

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

@maziggy commented on GitHub (Apr 29, 2026): Thanks for the during-print bundle — it gave me everything I needed. Fix is in dev now (will land in the next daily build). What changed: - Bambuddy now parses print.device.fila_switch from MQTT and exposes it on the printer status. When the FTS is installed, the print modal's per-nozzle filter on the filament dropdown is suppressed — so every loaded AMS slot is selectable for any nozzle's filament, since the FTS routes them. - Slots currently fed into a track get an [L] or [R] badge in the dropdown so you can see where the FTS is currently routing them. Idle slots show no badge — they can be routed on demand. Single-AMS is fine for testing — that's exactly the configuration in your bundle, and the implementation handles it. Once your AMS 2 Pro and AMS-HT arrive, the same logic should hold (out is the FTS topology, in is the dynamic routing — neither cares how many AMS units are attached). If you do see anything off with multi-AMS routing once it's all assembled, please open a follow-up. Detection is automatic (no setting), so you'll see the dropdown fill. Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for you. --- BTW: > Slots currently fed into a track also get a routing badge in the dropdown — `[L]` or `[R]` — so the user can tell at a glance which slot the FTS is currently routing where (idle slots get no badge: they can be routed to either extruder on demand). Can you please send me a screenshot so that I can check how it looks like? ;) Don't have a FTS. ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!

BreizhHardware commented

Author

Owner

@mkavalecz commented on GitHub (Apr 29, 2026):

Thank you! I built a temporary docker image locally, to make it easier to try this out.
For any non-developer who might want to try similar new features, without waiting for the new daily image, here are the steps:

Switching to the dev branch from the daily docker image:

cd /opt/bambuddy
git clone https://github.com/maziggy/bambuddy.git tmp
cd tmp
git switch dev
docker build -t bambuddy:tmp .
cd ..
sed -i 's|ghcr.io/maziggy/bambuddy:daily|bambuddy:tmp|g' docker-compose.yml
docker compose up -d

Going back to the daily image:

sed -i 's|bambuddy:tmp|ghcr.io/maziggy/bambuddy:daily|g' docker-compose.yml
docker compose up -d

I can confirm that the loaded filaments now list correctly, here's the screenshot:

I'm currently running another print (bypassing Bambuddy), but it should be done in around 30 minutes, then I'll try starting a print job from Bambuddy and get back to you with the results.

@mkavalecz commented on GitHub (Apr 29, 2026): Thank you! I built a temporary docker image locally, to make it easier to try this out. For any non-developer who might want to try similar new features, without waiting for the new daily image, here are the steps: Switching to the dev branch from the daily docker image: ``` cd /opt/bambuddy git clone https://github.com/maziggy/bambuddy.git tmp cd tmp git switch dev docker build -t bambuddy:tmp . cd .. sed -i 's|ghcr.io/maziggy/bambuddy:daily|bambuddy:tmp|g' docker-compose.yml docker compose up -d ``` Going back to the daily image: ``` sed -i 's|bambuddy:tmp|ghcr.io/maziggy/bambuddy:daily|g' docker-compose.yml docker compose up -d ``` I can confirm that the loaded filaments now list correctly, here's the screenshot: <img width="611" height="313" alt="Image" src="https://github.com/user-attachments/assets/8936755f-69b0-4fb5-a098-d577c5ddb8e0" /> I'm currently running another print (bypassing Bambuddy), but it should be done in around 30 minutes, then I'll try starting a print job from Bambuddy and get back to you with the results.

BreizhHardware commented

Author

Owner

@maziggy commented on GitHub (Apr 29, 2026):

git checkout dev && git pull && docker compose build && docker compose up -d

@maziggy commented on GitHub (Apr 29, 2026): git checkout dev && git pull && docker compose build && docker compose up -d

BreizhHardware commented

Author

Owner

@mkavalecz commented on GitHub (Apr 29, 2026):

If you already have the repo checked out, that also works, yes :)
I used the docker-install.sh install method from the website for the initial setup, that only downloads the docker-compose file, so I had to clone the repo to a temp dir first.

But yeah, I should have used docker compose build instead of docker build. Both work, but your method is cleaner.
I'll clean this up tomorrow, so that watchtower can keep managing the updates.

Now for the important part:
I started a new print from Bambuddy, and the filament mapping seems to work correctly!
It loaded the correct filament, into the correct extruder, and is now printing happily.
Thanks a lot for the quick fix. I sent a "coffee" your way to show my appreciation ;)

@mkavalecz commented on GitHub (Apr 29, 2026): If you already have the repo checked out, that also works, yes :) I used the `docker-install.sh` install method from the website for the initial setup, that only downloads the docker-compose file, so I had to clone the repo to a temp dir first. But yeah, I should have used `docker compose build` instead of `docker build`. Both work, but your method is cleaner. I'll clean this up tomorrow, so that watchtower can keep managing the updates. Now for the important part: I started a new print from Bambuddy, and the filament mapping seems to work correctly! It loaded the correct filament, into the correct extruder, and is now printing happily. Thanks a lot for the quick fix. I sent a "coffee" your way to show my appreciation ;)

BreizhHardware commented

Author

Owner

@mkavalecz commented on GitHub (Apr 30, 2026):

Looks like there still needs to be some more work done for this, because right now, my AMS seems to be stuck to the right nozzle in Bambuddy, and whenever I try to print anything, the printer gets confused.

Also, the slicer seems to know some kind of ID for the track switch, because sometimes it says that the sliced file doesn't match the track switch on the printer, and I should sync and slice again. I have to select my actual printer, sync the info, slice, then send to Bambuddy, if I try to do the slicing with the virtual printer, it will always fail.

If you can tell me what kind of information I should get for you, I'm happy to help, I don't know the inner workings of this, so I wouldn't even know where to start.

@mkavalecz commented on GitHub (Apr 30, 2026): Looks like there still needs to be some more work done for this, because right now, my AMS seems to be stuck to the right nozzle in Bambuddy, and whenever I try to print anything, the printer gets confused. <img width="236" height="110" alt="Image" src="https://github.com/user-attachments/assets/2c763cbb-1475-45bf-ba91-6a843154938c" /> <img width="341" height="177" alt="Image" src="https://github.com/user-attachments/assets/5b2e71e7-3619-41a5-894d-eda41c9a9fb9" /> Also, the slicer seems to know some kind of ID for the track switch, because sometimes it says that the sliced file doesn't match the track switch on the printer, and I should sync and slice again. I have to select my actual printer, sync the info, slice, then send to Bambuddy, if I try to do the slicing with the virtual printer, it will always fail. If you can tell me what kind of information I should get for you, I'm happy to help, I don't know the inner workings of this, so I wouldn't even know where to start.

BreizhHardware commented

Author

Owner

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

This is a slicer warning and has nothing to do with Bambuddy.

if I try to do the slicing with the virtual printer, it will always fail.

You need to explain in detail what you're exactly doing.

@maziggy commented on GitHub (May 1, 2026): This is a slicer warning and has nothing to do with Bambuddy. > if I try to do the slicing with the virtual printer, it will always fail. You need to explain in detail what you're exactly doing.

BreizhHardware commented

Author

Owner

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

Okay, so what I wanted to say, was 2 things.

I had a print failure yesterday, here are the steps that lead to it as detailed as I can remember.

I opened a 3mf in Bambu Studio, selected the actual X2D printer (not the virtual printer) as a device, pressed sync to get the correct printer info, and sliced the model. So far, this is the official sequence, and it's independent from Bambuddy.
Then I pressed send, and sent the sliced file to the Bambuddy virtual printer. The virtual printer was configured as Archive type, so it added the file into the Archive. So far so good.
I started the print from Bambuddy, with the filament mapped to the correct spool in the AMS, the printer started printing, and I thought everything was fine.
Later I noticed print quality issues, and the print started to come up, which in itself would of course be independent from Bambuddy.
BUT this is when I realised: the printer did the whole print with the RIGHT (aux) nozzle, instead of the left one, even though the slicer told it to use the left one. The right nozzle on the X2D is inferior, and I printed PETG, which could very well be what caused the quality issue.
I cleaned up the build plate, and wanted to start the job again. This time, when the printer started the print, it failed in the beginning.
I opened Bambu Studio, went to the device tab and selected the actual X2D (not virtual) printer, to see the HMS code, that is where I've sent the screenshot from. I could have as well sent the same HMS code from within Bambuddy or took a picture with my phone of the printer's screen, I just thought there's nothing more official than the official app, so that's where I took the screenshot from. The source doesn't really matter, what matters is the message itself.

The issue persisted, no matter what I tried. The printer refused to print anything else from within Bambuddy from this point, so I started using Bambu Studio directly, without involving Bambuddy, because that was the only way for me to move forward.

So there were two problems with this:

A print started from Bambuddy started on the wrong extruder.
Then everything got fucked up seemingly permanently.

After a while of trying, the printer flat-out told me that it's in an invalid state, and I should reset to factory defaults.

Completely different observation that might or might not be an actual issue:

I have both the Bambuddy virtual printer and the actual X2D configured in Bambu Studio.
While slicing files, I realised, that Bambu Studio tries to sync information from the printer currently selected on the device tab automatically.
The virtual printer doesn't show the same information that the real device does, it is expected to be like this, that itself is not an issue.
The issue is, that when I select the actual X2D, slice a file correctly, then press Send and select to send it to Bambuddy virtual printer, this will also select the virtual printer on the device tab from that point.
The next time I slice, it will try to sync information from the virtual printer, which WILL cause issues.
One of the issues I've seen is that it seems to report nothing for the Left Nozzle diameter, and 0.4 for the Right Nozzle diameter, which shows a warning in Bambu Studio that "different nozzle sizes are not supported"
The other issue I've seen, is the one that I sloppily mentioned earlier: it seems like when Bambu Studio slices a file while a printer with an installed filament track switch is selected as a device I assume it will write some kind of ID of the track switch into the sliced file. If the ID doesn't match the printer the sliced file will be printed on, it shows this error saying that it will cause issues:

I think what might have happened when I saw the error was this:

I might have accidentally sliced a file while the virtual printer was selected.
Then I tried to start the print directly from Bambu Studio using the "Print plate" button, and selected the real printer directly.
And I think that should have been the moment I saw the error

This second issue is only important, because as a user, I expected that the device selection is only important while selecting the current destination for the "Print plate"/"Send".
Both the virtual printer and the real printer are reported as X2D, I think it was quite safe to assume that as long as the Build Plate / Nozzle / Filament etc. options are selected correctly (and they were), the "which actual physical printer will this be printed on" shouldn't matter at all.
This was always the case for other Bambu printers.

But it seems like Bambu changed this expectation, because the error message stated that the model was sliced for a different track switch, and I should re-slice it to avoid issues while printing. This took me by surprise, slicing should only depend on the printer's configuration, not the actual physical printer.

Sorry for the wall of text, I honestly couldn't tell this any shorter without losing context that might be important.
I stopped using Bambuddy for now, and went back to Bambu Studio, because I don't want to repeat what happened yesterday.

@mkavalecz commented on GitHub (May 1, 2026): Okay, so what I wanted to say, was 2 things. 1. I had a print failure yesterday, here are the steps that lead to it as detailed as I can remember. - I opened a 3mf in Bambu Studio, selected the actual X2D printer (not the virtual printer) as a device, pressed sync to get the correct printer info, and sliced the model. So far, this is the official sequence, and it's independent from Bambuddy. - Then I pressed send, and sent the sliced file to the Bambuddy virtual printer. The virtual printer was configured as Archive type, so it added the file into the Archive. So far so good. - I started the print from Bambuddy, with the filament mapped to the correct spool in the AMS, the printer started printing, and I thought everything was fine. - Later I noticed print quality issues, and the print started to come up, which in itself would of course be independent from Bambuddy. - BUT this is when I realised: the printer did the whole print with the RIGHT (aux) nozzle, instead of the left one, even though the slicer told it to use the left one. The right nozzle on the X2D is inferior, and I printed PETG, which could very well be what caused the quality issue. - I cleaned up the build plate, and wanted to start the job again. This time, when the printer started the print, it failed in the beginning. - I opened Bambu Studio, went to the device tab and selected the actual X2D (not virtual) printer, to see the HMS code, that is where I've sent the screenshot from. I could have as well sent the same HMS code from within Bambuddy or took a picture with my phone of the printer's screen, I just thought there's nothing more official than the official app, so that's where I took the screenshot from. The source doesn't really matter, what matters is the message itself. The issue persisted, no matter what I tried. The printer refused to print anything else from within Bambuddy from this point, so I started using Bambu Studio directly, without involving Bambuddy, because that was the only way for me to move forward. So there were two problems with this: - A print started from Bambuddy started on the wrong extruder. - Then everything got fucked up seemingly permanently. After a while of trying, the printer flat-out told me that it's in an invalid state, and I should reset to factory defaults. 2. Completely different observation that might or might not be an actual issue: - I have both the Bambuddy virtual printer and the actual X2D configured in Bambu Studio. - While slicing files, I realised, that Bambu Studio tries to sync information from the printer currently selected on the device tab automatically. - The virtual printer doesn't show the same information that the real device does, it is expected to be like this, that itself is not an issue. - The issue is, that when I select the actual X2D, slice a file correctly, then press Send and select to send it to Bambuddy virtual printer, this will also select the virtual printer on the device tab from that point. - The next time I slice, it will try to sync information from the virtual printer, which WILL cause issues. - One of the issues I've seen is that it seems to report nothing for the Left Nozzle diameter, and 0.4 for the Right Nozzle diameter, which shows a warning in Bambu Studio that "different nozzle sizes are not supported" - The other issue I've seen, is the one that I sloppily mentioned earlier: it seems like when Bambu Studio slices a file **while a printer with an installed filament track switch is selected as a device** I assume it will write some kind of ID of the track switch into the sliced file. If the ID doesn't match the printer the sliced file will be printed on, it shows this error saying that it will cause issues: <img width="438" height="138" alt="Image" src="https://github.com/user-attachments/assets/17b8d124-859e-4294-966a-dd36af79d29e" /> I think what might have happened when I saw the error was this: - I might have accidentally sliced a file while the virtual printer was selected. - Then I tried to start the print directly from Bambu Studio using the "Print plate" button, and selected the real printer directly. - And I think that should have been the moment I saw the error This second issue is only important, because as a user, I expected that the device selection is only important while selecting the current destination for the "Print plate"/"Send". Both the virtual printer and the real printer are reported as X2D, I think it was quite safe to assume that as long as the Build Plate / Nozzle / Filament etc. options are selected correctly (and they were), the "which actual physical printer will this be printed on" shouldn't matter at all. This was always the case for other Bambu printers. But it seems like Bambu changed this expectation, because the error message stated that the model was **sliced** for a different track switch, and I should re-slice it to avoid issues while printing. This took me by surprise, slicing should only depend on the printer's configuration, not the actual physical printer. Sorry for the wall of text, I honestly couldn't tell this any shorter without losing context that might be important. I stopped using Bambuddy for now, and went back to Bambu Studio, because I don't want to repeat what happened yesterday.

BreizhHardware commented

Author

Owner

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

Another note that might be important for the 1. problem I mentioned:

I'm printing using Bambu Studio now, but Bambuddy is still running in a kind of readonly mode, to monitor the printer.
Now when I'm printing from Bambu Studio, the AMS shows for the left extruder within Bambuddy.

When it started the job on the right extruder it showed an R there. I think it shouldn't really show anything with a track switch, but I don't know if this is related to why it started to print on the right extruder, or not. It might just be a visual thing that shows where it is currently, in which case, it's not an issue.

@mkavalecz commented on GitHub (May 1, 2026): Another note that might be important for the 1. problem I mentioned: I'm printing using Bambu Studio now, but Bambuddy is still running in a kind of readonly mode, to monitor the printer. Now when I'm printing from Bambu Studio, the AMS shows for the **left** extruder within Bambuddy. <img width="524" height="754" alt="Image" src="https://github.com/user-attachments/assets/5c3caa35-4489-4d2a-ac32-6a967f5e2e7b" /> When it started the job on the right extruder it showed an R there. I think it shouldn't really show anything with a track switch, but I don't know if this is related to why it started to print on the right extruder, or not. It might just be a visual thing that shows where it is currently, in which case, it's not an issue.

BreizhHardware commented

Author

Owner

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

Detailed write-up — thank you, this is exactly what I needed to triage.

Splitting what I see into three things:

The wrong-nozzle print is a real Bambuddy bug, separate from the detection fix that just shipped. The detection fix made the loaded filaments visible in the dropdown, which is why your first print dispatched at all — but 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. The print quality issue and the eventual "invalid state" are downstream of the printer doing actual prints with mismatched tool/route. Not a status display issue.
The Studio sync-from-VP behaviour is real but separate. Studio's "select-as-device on Send" pattern is on Studio, but our VP advertising thin/empty hardware fields makes it worse. Worth its own issue.
The L badge during your Studio-driven print is just status display — Bambuddy reads what the printer reports the FTS
currently has routed where, and renders that in the AMS card. No effect on routing.

To fix (1) properly I need to see the full project_file MQTT command that Studio sends to your X2D — that's where the missing field set lives. I just pushed a small dev-only diagnostic: when a slicer-launched project_file passes through the request topic, Bambuddy will now log the full payload at INFO level (no debug-mode required).

If you can:

Pull dev again
Start one Studio -> X2D direct print (don't go through Bambuddy)
Send the resulting bambuddy.log

I'll diff Studio's payload against ours and ship the routing fix.

Issue hygiene: I'd suggest keeping #1162 closed (the as-filed FTS detection issue is genuinely fixed), and opening two follow-ups so each one has a clean repro and resolution path:

"X2D + FTS: Bambuddy-launched prints route to wrong nozzle" (severity: high — blocks X2D + FTS users from printing safely)
"Virtual Printer advertises empty hardware fields that Studio syncs into slices when VP is the active device"
(severity: medium — confusing UX, potentially mis-sliced files)

Reference this thread in both and I'll prioritise the routing one.

@maziggy commented on GitHub (May 2, 2026): Detailed write-up — thank you, this is exactly what I needed to triage. Splitting what I see into three things: 1. The wrong-nozzle print is a real Bambuddy bug, separate from the detection fix that just shipped. The detection fix made the loaded filaments visible in the dropdown, which is why your first print dispatched at all — but 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. The print quality issue and the eventual "invalid state" are downstream of the printer doing actual prints with mismatched tool/route. Not a status display issue. 2. The Studio sync-from-VP behaviour is real but separate. Studio's "select-as-device on Send" pattern is on Studio, but our VP advertising thin/empty hardware fields makes it worse. Worth its own issue. 3. The L badge during your Studio-driven print is just status display — Bambuddy reads what the printer reports the FTS currently has routed where, and renders that in the AMS card. No effect on routing. To fix (1) properly I need to see the full project_file MQTT command that Studio sends to your X2D — that's where the missing field set lives. I just pushed a small dev-only diagnostic: when a slicer-launched project_file passes through the request topic, Bambuddy will now log the full payload at INFO level (no debug-mode required). If you can: - Pull dev again - Start one Studio -> X2D direct print (don't go through Bambuddy) - Send the resulting bambuddy.log I'll diff Studio's payload against ours and ship the routing fix. Issue hygiene: I'd suggest keeping #1162 closed (the as-filed FTS detection issue is genuinely fixed), and opening two follow-ups so each one has a clean repro and resolution path: - "X2D + FTS: Bambuddy-launched prints route to wrong nozzle" (severity: high — blocks X2D + FTS users from printing safely) - "Virtual Printer advertises empty hardware fields that Studio syncs into slices when VP is the active device" (severity: medium — confusing UX, potentially mis-sliced files) Reference this thread in both and I'll prioritise the routing one.

BreizhHardware commented