[GH-ISSUE #1193] [Bug]: Virtual Printer advertises empty hardware fields that Studio syncs into slices when VP is the active device

BreizhHardware commented

2026-05-06 12:33:30 +02:00

Owner

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

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

When sending a file to the virtual printer in Bambu Studio, the virtual printer will be kept as the selected device from that point.
If the user slices the next file while the virtual printer is still selected, it can introduce issues into the sliced file, which is confusing behaviour.

See the comments in #1162 for more details.

Expected Behavior

The virtual printer shouldn't silently sabotage the slicing.

Steps to Reproduce

Slice a file while the virtual printer is selected in Bambu Studio.

Printer Model

Multiple printers

Bambuddy Version

v0.2.4b2

SpoolBuddy Version

No response

Printer Firmware Version

No response

Installation Method

Manual (git clone)

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

No response

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/1193 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description When sending a file to the virtual printer in Bambu Studio, the virtual printer will be kept as the selected device from that point. If the user slices the next file while the virtual printer is still selected, it can introduce issues into the sliced file, which is confusing behaviour. See the comments in #1162 for more details. ### Expected Behavior The virtual printer shouldn't silently sabotage the slicing. ### Steps to Reproduce Slice a file while the virtual printer is selected in Bambu Studio. ### Printer Model Multiple printers ### Bambuddy Version v0.2.4b2 ### SpoolBuddy Version _No response_ ### Printer Firmware Version _No response_ ### Installation Method Manual (git clone) ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package _No response_ ### 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-06 12:33:30 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

2026-05-06 12:33:31 +02:00

Author

Owner

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

Thanks for filing — and for the wall of text in #1162 that explains the actual workflow. After thinking about it: this is a real trap, but the right resolution is documentation rather than a code change, and I want to explain the reasoning honestly so you (and anyone else reading this thread) understand the trade-off.

What we'd have to do to "fix" it in code: make the virtual printer mirror the target printer's static hardware fields (nozzle count, nozzle diameters, FTS presence) when responding to Studio's sync. That's technically doable — Bambuddy already has the data — but it conflicts with how server-mode VPs are designed:

A VP in Immediate / Review / Print Queue mode is a file receiver, not a live channel to a printer. It deliberately advertises thin metadata so the slicer doesn't lead users into thinking they can configure AMS slots, set live temperatures, or start prints from the slicer. (See the existing wiki FAQ "Why don't I see my AMS / filament slots in the slicer?" for the full reasoning.)
If we start populating some fields (nozzle, FTS) but not others (AMS), users will reasonably ask "well why don't AMS slots appear, you have the data?" and we end up halfway between two designs.
The proper fix for "I want the slicer to see live printer state" is Proxy Mode, which already does exactly that. It forwards the full slicer ↔ printer conversation, so Studio sees real nozzle diameters, real FTS state, real AMS — everything. No metadata gymnastics, no half-measures.

For server modes, the rule is simpler and worth documenting clearly: slice against your real printer's profile, then Send the result to the VP. Don't leave the VP selected as the active device when slicing. Studio's sticky-device UX is on Studio, but we can warn users about the trap.

I've added a new section to the Virtual Printer wiki page that walks through the issue, the symptoms (including the exact "different nozzle sizes" warning and the FTS-ID-mismatch message), and the correct workflow. It'll be live with the next docs deploy.

Closing this as docs-only. If you (or anyone else) hit a scenario the docs don't cover after they're deployed, please reopen — happy to extend the section. The X2D + FTS routing fix from #1192 is the higher-priority item and is what'll actually unblock you for normal Bambuddy-driven prints.

@maziggy commented on GitHub (May 2, 2026): Thanks for filing — and for the wall of text in #1162 that explains the actual workflow. After thinking about it: this is a real trap, but the right resolution is documentation rather than a code change, and I want to explain the reasoning honestly so you (and anyone else reading this thread) understand the trade-off. **What we'd have to do to "fix" it in code:** make the virtual printer mirror the target printer's static hardware fields (nozzle count, nozzle diameters, FTS presence) when responding to Studio's sync. That's technically doable — Bambuddy already has the data — but it conflicts with how server-mode VPs are designed: - A VP in Immediate / Review / Print Queue mode is a **file receiver**, not a live channel to a printer. It deliberately advertises *thin* metadata so the slicer doesn't lead users into thinking they can configure AMS slots, set live temperatures, or start prints from the slicer. (See the existing wiki FAQ "Why don't I see my AMS / filament slots in the slicer?" for the full reasoning.) - If we start populating *some* fields (nozzle, FTS) but not others (AMS), users will reasonably ask "well why don't AMS slots appear, you have the data?" and we end up halfway between two designs. - The proper fix for "I want the slicer to see live printer state" is **Proxy Mode**, which already does exactly that. It forwards the full slicer ↔ printer conversation, so Studio sees real nozzle diameters, real FTS state, real AMS — everything. No metadata gymnastics, no half-measures. **For server modes, the rule is simpler and worth documenting clearly:** slice against your real printer's profile, then Send the result to the VP. Don't leave the VP selected as the active device when slicing. Studio's sticky-device UX is on Studio, but we can warn users about the trap. I've added a new section to the [Virtual Printer wiki page](https://maziggy.github.io/bambuddy/features/virtual-printer/#dont-slice-with-the-virtual-printer-selected-as-the-active-device) that walks through the issue, the symptoms (including the exact "different nozzle sizes" warning and the FTS-ID-mismatch message), and the correct workflow. It'll be live with the next docs deploy. Closing this as docs-only. If you (or anyone else) hit a scenario the docs don't cover after they're deployed, please reopen — happy to extend the section. The X2D + FTS routing fix from #1192 is the higher-priority item and is what'll actually unblock you for normal Bambuddy-driven prints.

BreizhHardware commented

2026-05-06 12:33:31 +02:00

Author

Owner

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

If I'm being honest, I have mixed feelings about this.

On one hand, this is exactly what I thought myself as well: this is a documentation issue.
We can't change how Bambu Studio works, and the virtual printer is already documented to not send real device info, so this behaviour is somewhat expected.

On the other hand, as a user I'd normally like to use Bambuddy this way:

Slice my files in Bambu Studio
Send them to Bambuddy's virtual printer
Use the Queue/Archive-reprint features within Bambuddy to handle the actual printing

In this workflow, Bambu Studio's sole responsibility is slicing, everything else should be Bambuddy.

When the virtual printer advertises incorrect or incomplete information about itself, it's not normally an issue, I'd even argue that it's beneficial, because it might make me realise in time that the wrong printer is selected for slicing.

However, needing to have both the virtual printer and the normal printer in Bambu Studio, and having to switch between them constantly is not a good solution as a user. It introduces a major point of failure into the workflow, that will cause issues every once in a while. Bambuddy can't change how Bambu Studio works, but it can (and should) adapt to it, to provide a better user experience.

As far as I know, proxy mode is not really the solution either.
If I want to queue up multiple prints (which is one of, if not the most important feature of Bambuddy that you couldn't get without using it), proxy mode doesn't help, because the printer can only start 1 job at a time, and it has no concept of Bambuddy's archive.
Proxy mode is great for remote access, but if I already sit next to the printer, I might as well just use the printer directly. Unless I misunderstood the documentation, I see 0 potential gain by using the proxy mode, while sitting next to the printer.

As things stand, it seems like Bambu broke their promise by introducing more complexity into the slicing than it should have.
This used to be very easy: select the correct printer, nozzle and build plate, slice the file, and as long as you print it on the same printer model, nozzle, and build plate, it will work, regardless of which actual physical printer it is.
This is not the case by now, adding all these new hardware added more complexity on the slicing side, and now we have to consider much more things to get a correct slice.

I think if this is how it works right now, the best solution would be to sync every info from the printer to the virtual printer.
I don't see any other way to provide a good user experience outside of proxy mode.

Bambuddy can already auto-archive prints even if the user starts them on the printer directly from Bambu Studio.
I feel like this way, every currently available mode of the virtual printer is useless for me.
Proxy mode doesn't give me any useful features that I don't have without it, and the other modes only introduce a very big gotcha that I constantly have to keep in mind.

Without using the virtual printer, there's no easy way to use Bambuddy to queue up multiple prints.
I can of course upload the sliced files manually, but that's very tedious.
For me, this is a deal-breaker, that makes me consider not using Bambuddy at all.

Just to be very clear though:
I'm not demanding anything!
I'm only 1 user, there are plenty of others who might be perfectly happy with this as it is.
I just wanted to voice my opinion and reasoning, and see if maybe others will think the same in the future.

@mkavalecz commented on GitHub (May 2, 2026): If I'm being honest, I have mixed feelings about this. On one hand, this is exactly what I thought myself as well: this is a documentation issue. We can't change how Bambu Studio works, and the virtual printer is already documented to not send real device info, so this behaviour is somewhat expected. On the other hand, as a user I'd normally like to use Bambuddy this way: - Slice my files in Bambu Studio - Send them to Bambuddy's virtual printer - Use the Queue/Archive-reprint features within Bambuddy to handle the actual printing In this workflow, Bambu Studio's sole responsibility is slicing, everything else should be Bambuddy. When the virtual printer advertises incorrect or incomplete information about itself, it's not normally an issue, I'd even argue that it's beneficial, because it might make me realise in time that the wrong printer is selected for slicing. However, needing to have both the virtual printer and the normal printer in Bambu Studio, and having to switch between them constantly is not a good solution as a user. It introduces a major point of failure into the workflow, that **will** cause issues every once in a while. Bambuddy can't change how Bambu Studio works, but it can (and should) adapt to it, to provide a better user experience. As far as I know, proxy mode is not really the solution either. If I want to queue up multiple prints (which is one of, if not **the** most important feature of Bambuddy that you couldn't get without using it), proxy mode doesn't help, because the printer can only start 1 job at a time, and it has no concept of Bambuddy's archive. Proxy mode is great for remote access, but if I already sit next to the printer, I might as well just use the printer directly. Unless I misunderstood the documentation, I see 0 potential gain by using the proxy mode, while sitting next to the printer. As things stand, it seems like Bambu broke their promise by introducing more complexity into the slicing than it should have. This used to be very easy: select the correct printer, nozzle and build plate, slice the file, and as long as you print it on the same printer model, nozzle, and build plate, it will work, regardless of which actual physical printer it is. This is not the case by now, adding all these new hardware added more complexity on the slicing side, and now we have to consider much more things to get a correct slice. I think if this is how it works right now, the best solution would be to sync every info from the printer to the virtual printer. I don't see any other way to provide a good user experience outside of proxy mode. Bambuddy can already auto-archive prints even if the user starts them on the printer directly from Bambu Studio. I feel like this way, every currently available mode of the virtual printer is useless for me. Proxy mode doesn't give me any useful features that I don't have without it, and the other modes only introduce a very big gotcha that I constantly have to keep in mind. Without using the virtual printer, there's no easy way to use Bambuddy to queue up multiple prints. I can of course upload the sliced files manually, but that's very tedious. For me, this is a deal-breaker, that makes me consider not using Bambuddy at all. Just to be very clear though: I'm **not** demanding anything! I'm only 1 user, there are plenty of others who might be perfectly happy with this as it is. I just wanted to voice my opinion and reasoning, and see if maybe others will think the same in the future.

BreizhHardware commented

2026-05-06 12:33:31 +02:00

Author

Owner

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

You don't need to be connected to your physical printer for slicing. Just set the correct printer profile and add the required filaments - doesn't matter to which AMS slot. Then slice it and send it to Bambuddy. Bambuddy tries to find the correct AMS slots automatically, when starting a print or scheduling it.

@maziggy commented on GitHub (May 2, 2026): You don't need to be connected to your physical printer for slicing. Just set the correct printer profile and add the required filaments - doesn't matter to which AMS slot. Then slice it and send it to Bambuddy. Bambuddy tries to find the correct AMS slots automatically, when starting a print or scheduling it.

BreizhHardware commented

2026-05-06 12:33:31 +02:00

Author

Owner

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

Hmm, that is true, but I think I will be connected to the virtual printer automatically if it's in the list though. (and it will be, because the Studio auto detects it on the network)
And then we fall back to the same issue. Unless I remove the virtual printer, slice, then add it back to use the Send feature.

@mkavalecz commented on GitHub (May 2, 2026): Hmm, that is true, but I think I will be connected to the virtual printer automatically if it's in the list though. (and it will be, because the Studio auto detects it on the network) And then we fall back to the same issue. Unless I remove the virtual printer, slice, then add it back to use the Send feature.

BreizhHardware commented

2026-05-06 12:33:31 +02:00

Author

Owner

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

I don't know how to fix that, sorry. The non proxy mode is just "pseudo connection" to Bambuddy and it has no printer data at all. This can also not be changed, because it requires a lot more than just this single connection to Bambuddy.

@maziggy commented on GitHub (May 2, 2026): I don't know how to fix that, sorry. The non proxy mode is just "pseudo connection" to Bambuddy and it has no printer data at all. This can also not be changed, because it requires a lot more than just this single connection to Bambuddy.

BreizhHardware commented

2026-05-06 12:33:31 +02:00

Author

Owner

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

Actually, scratch what I just said, I do need to be connected to the physical printer to get the correct slicing, because of these modes in the slicer:

The slicer needs to know which AMS is connected to which nozzle to optimise the slicing, these options works completely differently with and without the track switch. This does indeed modify how the file is sliced.

Given that these options also modify where do the filament swaps happen in the g-code, because the same filament can be mapped to more than 1 nozzle during the same print (I think Bambu calls it dynamic filament mapping), it's not something that can be fully fixed with just a static filament mapping after slicing.

No matter how I try to twist this, Bambu Studio does require a proper connection to slice correctly.
Which renders every non-proxy virtual printer basically useless for FTS printers.

The H2D and H2C will also support the track switch soon, so I feel like this problem will need to be solved eventually somehow.
How to truly fix this, is not clear for me either.

@mkavalecz commented on GitHub (May 2, 2026): Actually, scratch what I just said, I **do** need to be connected to the physical printer to get the correct slicing, because of these modes in the slicer: <img width="362" height="374" alt="Image" src="https://github.com/user-attachments/assets/48934ef6-7940-4215-a8af-5e09647bcb3d" /> The slicer needs to know which AMS is connected to which nozzle to optimise the slicing, these options works completely differently with and without the track switch. This does indeed modify how the file is sliced. Given that these options also modify where do the filament swaps happen in the g-code, because the same filament can be mapped to more than 1 nozzle during the same print (I think Bambu calls it dynamic filament mapping), it's not something that can be fully fixed with just a static filament mapping after slicing. No matter how I try to twist this, Bambu Studio does require a proper connection to slice correctly. Which renders every non-proxy virtual printer basically useless for FTS printers. The H2D and H2C will also support the track switch soon, so I feel like this problem will need to be solved eventually somehow. How to truly fix this, is not clear for me either.

BreizhHardware commented

2026-05-06 12:33:31 +02:00

Author

Owner

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

I think I have an idea. Let me think about it.

@maziggy commented on GitHub (May 2, 2026): I think I have an idea. Let me think about it.

BreizhHardware commented

2026-05-06 12:33:31 +02:00

Author

Owner

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