1
0
Fork 0
mirror of https://github.com/maziggy/bambuddy.git synced 2026-05-09 08:25:54 +02:00

[GH-ISSUE #706] [Bug]: Bambu Slicer reports "incompatible printer on Send #471

Closed
opened 2026-05-07 00:10:33 +02:00 by BreizhHardware · 16 comments

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

Originally assigned to: @maziggy on GitHub.

Bug Description

When attempting to send to a queue virtual printer, the Bambu Slicer reports the depicted error message. No job appears in the queue.

Image

Expected Behavior

The print job should be accepted by the queue virtual printer.

Steps to Reproduce

  1. Select virtual printer
  2. Slice project
  3. Click "Send"
  4. A dialog box with the error message appears

Printer Model

X1 Carbon

Bambuddy Version

0.2.2b4

Printer Firmware Version

01.11.02.00

Installation Method

Manual (git clone)

Operating System

Linux (Ubuntu/Debian)

Relevant Logs / Support Package

bambuddy-support-20260314-194500.zip

Screenshots

Image

Additional Context

Bambu Slicer and Bambuddy are connected via a Tailnet.

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 @luckygreen on GitHub (Mar 14, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/706 Originally assigned to: @maziggy on GitHub. ### Bug Description When attempting to send to a queue virtual printer, the Bambu Slicer reports the depicted error message. No job appears in the queue. <img width="916" height="1139" alt="Image" src="https://github.com/user-attachments/assets/7b68c752-b501-4009-a4d4-29b9570a6425" /> ### Expected Behavior The print job should be accepted by the queue virtual printer. ### Steps to Reproduce 1. Select virtual printer 2. Slice project 3. Click "Send" 4. A dialog box with the error message appears ### Printer Model X1 Carbon ### Bambuddy Version 0.2.2b4 ### Printer Firmware Version 01.11.02.00 ### Installation Method Manual (git clone) ### Operating System Linux (Ubuntu/Debian) ### Relevant Logs / Support Package [bambuddy-support-20260314-194500.zip](https://github.com/user-attachments/files/25999173/bambuddy-support-20260314-194500.zip) ### Screenshots <img width="916" height="1139" alt="Image" src="https://github.com/user-attachments/assets/bbdc7759-2176-417e-93a1-bd1d2709377a" /> ### Additional Context Bambu Slicer and Bambuddy are connected via a Tailnet. ### 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
Author
Owner

@maziggy commented on GitHub (Mar 15, 2026):

First of all it looks like you didn't follow the installation instructions. Your installation is not running properly.

pip install warning: /opt/[user]/venv/bin/python: No module named pip

Secondly I doubt, that your slicer was connected to Bambuddy. It looks like you've used the wrong access code.

2026-03-14 18:52:10,116 WARNING [backend.app.services.virtual_printer.mqtt_server] MQTT auth failed for user 'bblp'

<!-- gh-comment-id:4062548378 --> @maziggy commented on GitHub (Mar 15, 2026): First of all it looks like you didn't follow the installation instructions. Your installation is not running properly. >pip install warning: /opt/[user]/venv/bin/python: No module named pip Secondly I doubt, that your slicer was connected to Bambuddy. It looks like you've used the wrong access code. >2026-03-14 18:52:10,116 WARNING [backend.app.services.virtual_printer.mqtt_server] MQTT auth failed for user 'bblp'
Author
Owner

@luckygreen commented on GitHub (Mar 16, 2026):

I indeed did not follow the installation instructions. I, as a matter of best practices operational principle, install all python modules using uv. My use of uv does not impact the operation of Bambuddy: it runs just fine and I can access the web interface without issues.

My slicer is obviously connected to Bambuddy. How else would the slicer know that a "Queue Lucky Bambu X1C" printer even exists, which is only defined in Bambuddy? See screenshot.

Image
<!-- gh-comment-id:4066869428 --> @luckygreen commented on GitHub (Mar 16, 2026): I indeed did not follow the installation instructions. I, as a matter of best practices operational principle, install all python modules using uv. My use of uv does not impact the operation of Bambuddy: it runs just fine and I can access the web interface without issues. My slicer is obviously connected to Bambuddy. How else would the slicer know that a "Queue Lucky Bambu X1C" printer even exists, which is only defined in Bambuddy? See screenshot. <img width="916" height="1139" alt="Image" src="https://github.com/user-attachments/assets/e50ad613-4083-4f09-99d7-179d9f94f344" />
Author
Owner

@maziggy commented on GitHub (Mar 16, 2026):

I don't know what happens on your system but Bambuddy logs show no connections at all.

Check via tcpdump?

<!-- gh-comment-id:4066943586 --> @maziggy commented on GitHub (Mar 16, 2026): I don't know what happens on your system but Bambuddy logs show no connections at all. Check via tcpdump?
Author
Owner

@maziggy commented on GitHub (Mar 16, 2026):

And yeah, if it's searching for pip and cannot find it.....that should be fixed anyway.

<!-- gh-comment-id:4066947773 --> @maziggy commented on GitHub (Mar 16, 2026): And yeah, if it's searching for pip and cannot find it.....that should be fixed anyway.
Author
Owner

@luckygreen commented on GitHub (Mar 16, 2026):

Adding further analysis after some deeper investigation, in case it helps track this down.

Slicer version: Bambu Studio Beta 2.5.1.52
Network: Slicer and Bambuddy connected via Tailscale (manual bind by IP, not SSDP)
Installation method: Native (uv on Ubuntu), not Docker

The bind handshake completes successfully on port 3002, and the virtual printer appears by name in the Device tab and in the Send dialog. The incompatibility error is pre-populated when the dialog opens, when the Send button is clicked a second time. Nothing happens when the Send button is clicked the first time. This suggests the check is performed client-side at dialog open time rather than triggered by the send action itself.

Reviewing the Bambuddy logs during multiple Send attempts, I notice that the slicer repeatedly sends pushall requests over MQTT but the virtual printer does not appear to generate a corresponding status response. The logs show get_version being handled correctly (product_name=X1C), but there is no log entry indicating a pushall response payload is ever sent back to the slicer:

INFO [virtual_printer.mqtt_server] MQTT publish to device/00M09A391800001/request: {"pushing":{"command":"pushall","push_target":1,"sequence_id":"20000","version":1}}...
INFO [virtual_printer.mqtt_server] MQTT publish to device/00M09A391800001/request: {"info":{"command":"get_version","sequence_id":"20001"}}...
INFO [virtual_printer.mqtt_server] Sent version response (product_name=X1C)

I suspect that Bambu Studio Beta 2.5.1.52 may now require a valid pushall status response — containing fields such as nozzle diameter, AMS configuration, and printer capabilities — before it will permit a send operation. My understanding is that a real X1C would reply to pushall with a full printer state payload, and I believe the slicer may be using that response to perform the compatibility check. Without it, the check may fail by default.

This could be a regression introduced in the Beta slicer, or it may indicate that the virtual printer's pushall response handling is not yet implemented or is returning an incomplete payload. Logs from the session are attached.

If it would be helpful, it might be worth examining whether the virtual printer's MQTT server should be responding to pushall with a synthetic printer state payload — even a minimal one containing nozzle diameter and a plausible AMS/capabilities structure — to satisfy whatever validation the Beta slicer performs at send time. I appreciate any insight you may have into whether this is on the slicer side or something that could be addressed in Bambuddy.

bambuddy-virtual-printer-pushall-bug-20260316T214352.log

<!-- gh-comment-id:4070576059 --> @luckygreen commented on GitHub (Mar 16, 2026): Adding further analysis after some deeper investigation, in case it helps track this down. **Slicer version:** Bambu Studio Beta 2.5.1.52 **Network:** Slicer and Bambuddy connected via Tailscale (manual bind by IP, not SSDP) **Installation method:** Native (`uv` on Ubuntu), not Docker The bind handshake completes successfully on port 3002, and the virtual printer appears by name in the Device tab and in the Send dialog. The incompatibility error is pre-populated when the dialog opens, when the Send button is clicked a second time. Nothing happens when the Send button is clicked the first time. This suggests the check is performed client-side at dialog open time rather than triggered by the send action itself. Reviewing the Bambuddy logs during multiple Send attempts, I notice that the slicer repeatedly sends `pushall` requests over MQTT but the virtual printer does not appear to generate a corresponding status response. The logs show `get_version` being handled correctly (`product_name=X1C`), but there is no log entry indicating a `pushall` response payload is ever sent back to the slicer: ``` INFO [virtual_printer.mqtt_server] MQTT publish to device/00M09A391800001/request: {"pushing":{"command":"pushall","push_target":1,"sequence_id":"20000","version":1}}... INFO [virtual_printer.mqtt_server] MQTT publish to device/00M09A391800001/request: {"info":{"command":"get_version","sequence_id":"20001"}}... INFO [virtual_printer.mqtt_server] Sent version response (product_name=X1C) ``` I suspect that Bambu Studio Beta 2.5.1.52 may now require a valid `pushall` status response — containing fields such as nozzle diameter, AMS configuration, and printer capabilities — before it will permit a send operation. My understanding is that a real X1C would reply to `pushall` with a full printer state payload, and I believe the slicer may be using that response to perform the compatibility check. Without it, the check may fail by default. This could be a regression introduced in the Beta slicer, or it may indicate that the virtual printer's `pushall` response handling is not yet implemented or is returning an incomplete payload. Logs from the session are attached. If it would be helpful, it might be worth examining whether the virtual printer's MQTT server should be responding to `pushall` with a synthetic printer state payload — even a minimal one containing nozzle diameter and a plausible AMS/capabilities structure — to satisfy whatever validation the Beta slicer performs at send time. I appreciate any insight you may have into whether this is on the slicer side or something that could be addressed in Bambuddy. [bambuddy-virtual-printer-pushall-bug-20260316T214352.log](https://github.com/user-attachments/files/26037470/bambuddy-virtual-printer-pushall-bug-20260316T214352.log)
Author
Owner

@maziggy commented on GitHub (Mar 17, 2026):

Did you also try with the latest non beta release of Bambu Studio? Would be good to know if there has anything changed for the new alpha/beta versions?

<!-- gh-comment-id:4074458955 --> @maziggy commented on GitHub (Mar 17, 2026): Did you also try with the latest non beta release of Bambu Studio? Would be good to know if there has anything changed for the new alpha/beta versions?
Author
Owner

@luckygreen commented on GitHub (Mar 17, 2026):

I haven't yet, unfortunately. To my knowledge, you can't run two Bambu Studio versions side by side on the same Win11 system, and I'm currently dependent on the Helio Plugin improvements in the beta for the high-temperature engineering filaments I'm printing with regularly.

That said, I'm happy to spin up a fresh Win11 VM and install the latest stable release there to test. It'll take me a little while to get that set up, so just let me know if you'd like me to go ahead and I'll get it done.

<!-- gh-comment-id:4074589472 --> @luckygreen commented on GitHub (Mar 17, 2026): I haven't yet, unfortunately. To my knowledge, you can't run two Bambu Studio versions side by side on the same Win11 system, and I'm currently dependent on the Helio Plugin improvements in the beta for the high-temperature engineering filaments I'm printing with regularly. That said, I'm happy to spin up a fresh Win11 VM and install the latest stable release there to test. It'll take me a little while to get that set up, so just let me know if you'd like me to go ahead and I'll get it done.
Author
Owner

@maziggy commented on GitHub (Mar 17, 2026):

Would be very helpful!

<!-- gh-comment-id:4074655456 --> @maziggy commented on GitHub (Mar 17, 2026): Would be very helpful!
Author
Owner

@maziggy commented on GitHub (Mar 17, 2026):

All good. Need to look into it now anyway. Will test with the final release of BS.

<!-- gh-comment-id:4075701994 --> @maziggy commented on GitHub (Mar 17, 2026): All good. Need to look into it now anyway. Will test with the final release of BS.
Author
Owner

@maziggy commented on GitHub (Mar 17, 2026):

Available in branch dev and available with the next release or daily build.

<!-- gh-comment-id:4075841996 --> @maziggy commented on GitHub (Mar 17, 2026): Available in branch dev and available with the next release or daily build.
Author
Owner

@maziggy commented on GitHub (Mar 17, 2026):

There one more issue. Still working on it.

<!-- gh-comment-id:4076530512 --> @maziggy commented on GitHub (Mar 17, 2026): There one more issue. Still working on it.
Author
Owner

@maziggy commented on GitHub (Mar 18, 2026):

Fixed in branch dev.

Please check docs/migration-vp-ftp-port.md for required changes and let me know if it works for you now.

<!-- gh-comment-id:4080503309 --> @maziggy commented on GitHub (Mar 18, 2026): Fixed in branch dev. Please check docs/migration-vp-ftp-port.md for required changes and let me know if it works for you now.
Author
Owner

@maziggy commented on GitHub (Mar 19, 2026):

I completely re-wrote the proxy to make it more reliable for different network setups. Please use latest daily build or dev branch and let me know if it works for you.

docker pull ghcr.io/maziggy/bambuddy:daily

Please note: requirements for the VP proxy have changed. Please check https://raw.githubusercontent.com/maziggy/bambuddy/refs/heads/dev/docs/migration-vp-ftp-port.md and updates Wiki docs.

<!-- gh-comment-id:4090717343 --> @maziggy commented on GitHub (Mar 19, 2026): I completely re-wrote the proxy to make it more reliable for different network setups. Please use latest daily build or dev branch and let me know if it works for you. docker pull ghcr.io/maziggy/bambuddy:daily Please note: requirements for the VP proxy have changed. Please check https://raw.githubusercontent.com/maziggy/bambuddy/refs/heads/dev/docs/migration-vp-ftp-port.md and updates Wiki docs.
Author
Owner

@luckygreen commented on GitHub (Mar 19, 2026):

Minimal change in behavior in v0.2.3b1.
The virtual queue printer continues to show up in Bambu Studio. See screeenshot below. Unlike before, slicing an object and hitting "Send" no longer brings up the printer mismatch dialog box. Not on the first Send, not on the second Send (as it did before), no Slicer GUI activity at all. No queued print job appears in Bambuddy.

Image
<!-- gh-comment-id:4090783246 --> @luckygreen commented on GitHub (Mar 19, 2026): Minimal change in behavior in v0.2.3b1. The virtual queue printer continues to show up in Bambu Studio. See screeenshot below. Unlike before, slicing an object and hitting "Send" no longer brings up the printer mismatch dialog box. Not on the first Send, not on the second Send (as it did before), no Slicer GUI activity at all. No queued print job appears in Bambuddy. <img width="941" height="548" alt="Image" src="https://github.com/user-attachments/assets/b5221854-63cf-4319-95b2-ed93d8b3a0d8" />
Author
Owner

@maziggy commented on GitHub (Mar 19, 2026):

Wait...when do you pulled branch dev?

<!-- gh-comment-id:4090806204 --> @maziggy commented on GitHub (Mar 19, 2026): Wait...when do you pulled branch dev?
Author
Owner

@maziggy commented on GitHub (Mar 24, 2026):

What's the status with latest version?

<!-- gh-comment-id:4116313618 --> @maziggy commented on GitHub (Mar 24, 2026): What's the status with latest version?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/bambuddy-maziggy-1#471
No description provided.