starred/bambuddy

Fork 0

mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 05:35:30 +02:00

[GH-ISSUE #708] [Feature]: Differentiate Print vs Send behavior on Proxy mode virtual printers #472

New issue

Open

opened 2026-05-06 12:29:57 +02:00 by BreizhHardware · 5 comments

BreizhHardware commented

2026-05-06 12:29:57 +02:00

Owner

Originally created by @nerdspar on GitHub (Mar 14, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/708

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

To support both immediate printing and queue-based dispatch from the slicer, I currently have to maintain two separate virtual printers, one in Proxy mode and one in Print Queue mode (with Auto-dispatch disabled), and manually switch between them depending on my intent. The slicer already has a natural way to express this distinction: Print means "start now" and Send means "stage it for later," but there's no way to leverage that on a single virtual printer today.

Proposed Solution

If possible, add a hybrid behavior option to Proxy mode virtual printers where:

Print → relays the job directly to the target printer (existing proxy behavior, unchanged)
Send → intercepts the job and adds it to the Bambuddy print queue as a pending item, equivalent to Print Queue mode with Auto-dispatch disabled

This would eliminate the two-virtual-printer workaround and make the Print vs Send distinction meaningful and useful for proxy users.

Alternatives Considered

No response

Feature Category

Print Queue & Scheduling

Priority

Would improve my workflow

Mockups or Examples

No response

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @nerdspar on GitHub (Mar 14, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/708 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case To support both immediate printing and queue-based dispatch from the slicer, I currently have to maintain two separate virtual printers, one in Proxy mode and one in Print Queue mode (with Auto-dispatch disabled), and manually switch between them depending on my intent. The slicer already has a natural way to express this distinction: Print means "start now" and Send means "stage it for later," but there's no way to leverage that on a single virtual printer today. ### Proposed Solution If possible, add a hybrid behavior option to Proxy mode virtual printers where: - Print → relays the job directly to the target printer (existing proxy behavior, unchanged) - Send → intercepts the job and adds it to the Bambuddy print queue as a pending item, equivalent to Print Queue mode with Auto-dispatch disabled This would eliminate the two-virtual-printer workaround and make the Print vs Send distinction meaningful and useful for proxy users. ### Alternatives Considered _No response_ ### Feature Category Print Queue & Scheduling ### Priority Would improve my workflow ### Mockups or Examples _No response_ ### Contribution - [ ] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested

BreizhHardware added the

enhancement

label

2026-05-06 12:29:57 +02:00

BreizhHardware commented

2026-05-06 12:29:58 +02:00

Author

Owner

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

I love the concept of unifying proxy and server modes so the slicer always has the full printer experience (AMS data, status, etc.) and the user decides at print time whether to send directly or queue via Bambuddy.

I did some protocol analysis to see if this is feasible, and unfortunately there's a fundamental timing problem that makes this very difficult to implement cleanly.

What we found:

The slicer uses the same FTP flow for both Print and Send — the only difference is that Print sends an MQTT project_file command after the FTP upload completes, while Send does not. There's no signal before or during the FTP upload that tells us the user's intent.

Why this matters:

In proxy mode, FTP is a transparent TCP passthrough (end-to-end encrypted between slicer and printer). Bambuddy can't intercept or read the file. In server mode, Bambuddy runs its own FTP server and receives the file directly. Both can't run on the same IP and port simultaneously.

We considered:

Always receiving files via Bambuddy's FTP server, then waiting for the MQTT signal to decide what to do — but for Print, this would mean Bambuddy has to re-upload the file to the printer and replicate the full MQTT command exchange that the transparent proxy currently handles automatically. That's a massive reimplementation effort with lots of edge cases.
Switching FTP handling based on MQTT commands — but the signal comes after the FTP upload, so we can't route the connection in advance.

Current workaround:

Setting up two virtual printers (one proxy, one queue mode) is currently the way to get both behaviors. I know it's not ideal, but the protocol unfortunately doesn't give us a clean way to do this with a single VP.

I'm keeping this issue open since it's a great concept. If anyone has ideas on alternative approaches, I'm all ears!

@maziggy commented on GitHub (Apr 4, 2026): I love the concept of unifying proxy and server modes so the slicer always has the full printer experience (AMS data, status, etc.) and the user decides at print time whether to send directly or queue via Bambuddy. I did some protocol analysis to see if this is feasible, and unfortunately there's a fundamental timing problem that makes this very difficult to implement cleanly. What we found: The slicer uses the same FTP flow for both Print and Send — the only difference is that Print sends an MQTT project_file command after the FTP upload completes, while Send does not. There's no signal before or during the FTP upload that tells us the user's intent. Why this matters: In proxy mode, FTP is a transparent TCP passthrough (end-to-end encrypted between slicer and printer). Bambuddy can't intercept or read the file. In server mode, Bambuddy runs its own FTP server and receives the file directly. Both can't run on the same IP and port simultaneously. We considered: - Always receiving files via Bambuddy's FTP server, then waiting for the MQTT signal to decide what to do — but for Print, this would mean Bambuddy has to re-upload the file to the printer and replicate the full MQTT command exchange that the transparent proxy currently handles automatically. That's a massive reimplementation effort with lots of edge cases. - Switching FTP handling based on MQTT commands — but the signal comes after the FTP upload, so we can't route the connection in advance. Current workaround: Setting up two virtual printers (one proxy, one queue mode) is currently the way to get both behaviors. I know it's not ideal, but the protocol unfortunately doesn't give us a clean way to do this with a single VP. I'm keeping this issue open since it's a great concept. If anyone has ideas on alternative approaches, I'm all ears!

BreizhHardware commented

2026-05-06 12:29:58 +02:00

Author

Owner

@leoshusar commented on GitHub (Apr 4, 2026):

I'm also following this issue, this is pretty much the only reason I'm not using virtual printers. I sometimes even forget to switch print plates, remembering to also select a correct printer based on if I want to print or archive/queue would be even worse for me :)

Just an idea - what about some kind of "emulator" virtual printer? Bambuddy would receive all the data (without proxying) and then upload them to the printer if the user pressed "print".
Basically adding a "print" button support to "Immediate" and "Print Queue" virtual printers, or creating separate "Immediate Emulator" or "Print Queue Emulator" virtual printers (I don't use the print queue, I just want to upload and archive when I press "send"). Do you think this would be possible?

It's not exactly what this issue is about (using proxy mode), but in the end the effect should be the same.

This would also solve my other issue. I'm using the auto archive by downloading 3mf from the printer, but I find it quite unreliable on my A1 mini for bigger 3mf files.

Just now when I was printing a slightly bigger 3mf (6.2 MB), Bambuddy couldn't download it from the printer:

Logs say it was trying for 3 minutes straight while receiving HTTP 425 and then it failed.

Logs

...
2026-04-03 22:23:34,017 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)2026-04-03 22:23:34,156 INFO [backend.app.services.bambu_ftp] FTP download failed for /Easter_eggs.3mf: 425 
2026-04-03 22:23:34,354 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf attempt 2/4 returned failure 
2026-04-03 22:23:34,354 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf will retry in 2.0s...
2026-04-03 22:23:37,501 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)
2026-04-03 22:23:37,684 INFO [backend.app.services.bambu_ftp] FTP download failed for /Easter_eggs.3mf: 425
2026-04-03 22:23:37,733 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf attempt 3/4 returned failure2026-04-03 22:23:37,733 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf will retry in 2.0s...
2026-04-03 22:23:40,797 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)
2026-04-03 22:23:40,955 INFO [backend.app.services.bambu_ftp] FTP download failed for /Easter_eggs.3mf: 425  
2026-04-03 22:23:41,035 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf attempt 4/4 returned failure
2026-04-03 22:23:41,035 ERROR [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf failed after 4 attempts
2026-04-03 22:23:41,035 INFO [backend.app.main] Direct FTP download failed, searching directories for 'easter_eggs'
2026-04-03 22:23:42,106 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)
2026-04-03 22:23:42,241 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /cache: 425 
2026-04-03 22:23:43,353 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)
2026-04-03 22:23:43,661 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /model: 425
2026-04-03 22:23:44,797 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)
2026-04-03 22:23:44,856 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /data: 550
2026-04-03 22:23:45,937 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)
2026-04-03 22:23:46,031 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /data/Metadata: 550
2026-04-03 22:23:47,170 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)
2026-04-03 22:23:47,316 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /: 425
2026-04-03 22:23:47,466 WARNING [backend.app.main] Could not find 3MF file for print: Easter_eggs.gcode.3mf
2026-04-03 22:23:47,471 INFO [backend.app.main] Created fallback archive 36 for Easter_eggs (no 3MF available)

It would be great to avoid first uploading to the "not very fast" ESP32 and then immediately downloading from it, and instead upload to Bambuddy and then upload only once to the printer.

@leoshusar commented on GitHub (Apr 4, 2026): I'm also following this issue, this is pretty much the only reason I'm not using virtual printers. I sometimes even forget to switch print plates, remembering to also select a correct printer based on if I want to print or archive/queue would be even worse for me :) Just an idea - what about some kind of "emulator" virtual printer? Bambuddy would receive all the data (without proxying) and *then* upload them to the printer if the user pressed "print". Basically adding a "print" button support to "Immediate" and "Print Queue" virtual printers, or creating separate "Immediate Emulator" or "Print Queue Emulator" virtual printers (I don't use the print queue, I just want to upload and archive when I press "send"). Do you think this would be possible? It's not *exactly* what this issue is about (using proxy mode), but in the end the effect should be the same. --- This would also solve my other issue. I'm using the auto archive by downloading 3mf from the printer, but I find it quite unreliable on my A1 mini for bigger 3mf files. Just now when I was printing a slightly bigger 3mf (6.2 MB), Bambuddy couldn't download it from the printer: <img width="611" height="643" alt="Image" src="https://github.com/user-attachments/assets/7486a479-f0bc-4394-aba8-964a380a9164" /> Logs say it was trying for 3 minutes straight while receiving HTTP 425 and then it failed. <details> <summary>Logs</summary> ``` ... 2026-04-03 22:23:34,017 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False)2026-04-03 22:23:34,156 INFO [backend.app.services.bambu_ftp] FTP download failed for /Easter_eggs.3mf: 425 2026-04-03 22:23:34,354 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf attempt 2/4 returned failure 2026-04-03 22:23:34,354 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf will retry in 2.0s... 2026-04-03 22:23:37,501 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False) 2026-04-03 22:23:37,684 INFO [backend.app.services.bambu_ftp] FTP download failed for /Easter_eggs.3mf: 425 2026-04-03 22:23:37,733 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf attempt 3/4 returned failure2026-04-03 22:23:37,733 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf will retry in 2.0s... 2026-04-03 22:23:40,797 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False) 2026-04-03 22:23:40,955 INFO [backend.app.services.bambu_ftp] FTP download failed for /Easter_eggs.3mf: 425 2026-04-03 22:23:41,035 INFO [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf attempt 4/4 returned failure 2026-04-03 22:23:41,035 ERROR [backend.app.services.bambu_ftp] Download 3MF from /Easter_eggs.3mf failed after 4 attempts 2026-04-03 22:23:41,035 INFO [backend.app.main] Direct FTP download failed, searching directories for 'easter_eggs' 2026-04-03 22:23:42,106 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False) 2026-04-03 22:23:42,241 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /cache: 425 2026-04-03 22:23:43,353 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False) 2026-04-03 22:23:43,661 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /model: 425 2026-04-03 22:23:44,797 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False) 2026-04-03 22:23:44,856 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /data: 550 2026-04-03 22:23:45,937 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False) 2026-04-03 22:23:46,031 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /data/Metadata: 550 2026-04-03 22:23:47,170 INFO [backend.app.services.bambu_ftp] FTP connected successfully to 10.0.2.68 (model=A1 Mini, prot_c=False) 2026-04-03 22:23:47,316 INFO [backend.app.services.bambu_ftp] FTP list_files failed for /: 425 2026-04-03 22:23:47,466 WARNING [backend.app.main] Could not find 3MF file for print: Easter_eggs.gcode.3mf 2026-04-03 22:23:47,471 INFO [backend.app.main] Created fallback archive 36 for Easter_eggs (no 3MF available) ``` </details> It would be great to avoid first uploading to the "not very fast" ESP32 and then immediately downloading from it, and instead upload to Bambuddy and then upload only once to the printer.

BreizhHardware commented

2026-05-06 12:29:58 +02:00

Author

Owner

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

Just now when I was printing a slightly bigger 3mf (6.2 MB), Bambuddy couldn't download it from the printer:
Logs say it was trying for 3 minutes straight while receiving HTTP 425 and then it failed.

That's a known issue for the A1, it's FTP related.

Just an idea - what about some kind of "emulator" virtual printer? Bambuddy would receive all the data (without proxying) and then upload them to the printer if the user pressed "print".

Exactly that was the idea, but it's not simply "send the file to the printer". We would need to emulate the slicer <-> printer communication EXACTLY. Since they can differ from model to model, this would need very intensive reverse engineering and would presumably be very fragile and intensive to errros.

So currently I have no idea how to get this implemented in a proper way.

@maziggy commented on GitHub (Apr 4, 2026): >Just now when I was printing a slightly bigger 3mf (6.2 MB), Bambuddy couldn't download it from the printer: >Logs say it was trying for 3 minutes straight while receiving HTTP 425 and then it failed. That's a known issue for the A1, it's FTP related. >Just an idea - what about some kind of "emulator" virtual printer? Bambuddy would receive all the data (without proxying) and then upload them to the printer if the user pressed "print". Exactly that was the idea, but it's not simply "send the file to the printer". We would need to emulate the slicer <-> printer communication EXACTLY. Since they can differ from model to model, this would need very intensive reverse engineering and would presumably be very fragile and intensive to errros. So currently I have no idea how to get this implemented in a proper way.

BreizhHardware commented

2026-05-06 12:29:58 +02:00

Author

Owner

@leoshusar commented on GitHub (Apr 4, 2026):

Ohh, I didn't realize it's not about just the MQTT project_file command, but also about everything else, like AMS etc.

Okay, here's a crazy idea - what about slicer-side support, if nothing better comes up? Maybe OrcaSlicer devs would be willing to merge some Bambuddy support.

Switching FTP handling based on MQTT commands — but the signal comes after the FTP upload, so we can't route the connection in advance.

I'm thinking just some checkbox in Bambu printer settings which would send a custom(?) MQTT command before the FTP upload, then Bambuddy could switch the FTP handling properly. In this particular idea I'm not sure if a 3rd party setting fits the "basic" printer settings though.

@leoshusar commented on GitHub (Apr 4, 2026): Ohh, I didn't realize it's not about just the MQTT project_file command, but also about everything else, like AMS etc. Okay, here's a crazy idea - what about slicer-side support, if nothing better comes up? Maybe OrcaSlicer devs would be willing to merge some Bambuddy support. > Switching FTP handling based on MQTT commands — but the signal comes after the FTP upload, so we can't route the connection in advance. I'm thinking just some checkbox in Bambu printer settings which would send a custom(?) MQTT command before the FTP upload, then Bambuddy could switch the FTP handling properly. In this particular idea I'm not sure if a 3rd party setting fits the "basic" printer settings though.

BreizhHardware commented

2026-05-06 12:29:58 +02:00

Author

Owner

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

Okay, here's a crazy idea - what about slicer-side support, if nothing better comes up? Maybe OrcaSlicer devs would be willing to merge some Bambuddy support.

We need to support both slicers, since Bambu Studio is the most used slicer.

@maziggy commented on GitHub (Apr 5, 2026): >Okay, here's a crazy idea - what about slicer-side support, if nothing better comes up? Maybe OrcaSlicer devs would be willing to merge some Bambuddy support. We need to support both slicers, since Bambu Studio is the most used slicer.

BreizhHardware referenced this issue

2026-05-06 12:34:42 +02:00

[PR #476] [CLOSED] feat(smart-plug): Add REST API plug type (Option 2 from #472) #1050

BreizhHardware referenced this issue

2026-05-06 12:35:21 +02:00

[PR #1029] [MERGED] v0.2.3 final #1149