starred/bambuddy

Fork 0

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

[GH-ISSUE #853] [Bug]: When using the external spool on a Bambu Lab P2S + AMS 2 Pro, filament usage is incorrectly attributed to AMS Slot 1 instead of the external spool. #579

New issue

Closed

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

BreizhHardware commented

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

Owner

Originally created by @anunayk on GitHub (Mar 31, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/853

Originally assigned to: @maziggy on GitHub.

Bug Description

In usage_tracker.py:872-882, when determining which tray a print used:

# Position-based default: sort available tray IDs so external spools (254/255)
# naturally follow standard AMS trays, matching slicer slot numbering
if global_tray_id is None:
    _state = printer_manager.get_status(printer_id)
    _raw = getattr(_state, "raw_data", None) if _state else None
    if _raw:
        from backend.app.services.spoolman_tracking import build_ams_tray_lookup

        available_trays = sorted(build_ams_tray_lookup(_raw).keys())
        if slot_id <= len(available_trays):
            global_tray_id = available_trays[slot_id - 1]

When you have an AMS 2 Pro with 4 trays (IDs 0, 1, 2, 3) plus the external spool (ID 254), the sorted list becomes:

available_trays = [0, 1, 2, 3, 254]

If the slicer says you're using slot 1 (the first slot, which should be the external spool), the code does:

global_tray_id = available_trays[1 - 1] # = available_trays[0] = 0

This maps the external spool usage to AMS 0, Tray 0 (the first AMS slot) instead of global_tray_id 254 (the external spool). The position-based mapping assumes that:

External spools (254, 255) come after all AMS trays in the sorted list
The slicer assigns slots sequentially starting from 1

For a P2S with AMS 2 Pro + External Spool, the slicer sees:

Slot 1-4: AMS trays
Slot 5: External spool

But Bambuddy's sorted list is [0, 1, 2, 3, 254], so:

Slot 1 → 0 (AMS tray 1)
Slot 2 → 1 (AMS tray 2)
Slot 3 → 2 (AMS tray 3)
Slot 4 → 3 (AMS tray 4)
Slot 5 → 254 (External spool)

BUT if you print using only the external spool (slot 1 in the 3MF, because it's the only filament), the mapping becomes:

Slot 1 → available_trays[0] → 0

Expected Behavior

Bambuddy should correctly map the used filament from the external spool.

Steps to Reproduce

Use a P2S with an AMS 2 Pro.
Load filament from the external spool.
Bambuddy will incorrectly map the filament in use to AMS Slot 1.

Printer Model

P2S

Bambuddy Version

0.2.2.2

Printer Firmware Version

01.01.03.00

Installation Method

Docker

Operating System

Docker

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 @anunayk on GitHub (Mar 31, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/853 Originally assigned to: @maziggy on GitHub. ### Bug Description In `usage_tracker.py:872-882,` when determining which tray a print used: ``` # Position-based default: sort available tray IDs so external spools (254/255) # naturally follow standard AMS trays, matching slicer slot numbering if global_tray_id is None: _state = printer_manager.get_status(printer_id) _raw = getattr(_state, "raw_data", None) if _state else None if _raw: from backend.app.services.spoolman_tracking import build_ams_tray_lookup available_trays = sorted(build_ams_tray_lookup(_raw).keys()) if slot_id <= len(available_trays): global_tray_id = available_trays[slot_id - 1] ``` When you have an AMS 2 Pro with 4 trays (IDs 0, 1, 2, 3) plus the external spool (ID 254), the sorted list becomes: `available_trays = [0, 1, 2, 3, 254]` If the slicer says you're using slot 1 (the first slot, which should be the external spool), the code does: `global_tray_id = available_trays[1 - 1] # = available_trays[0] = 0` This maps the external spool usage to AMS 0, Tray 0 (the first AMS slot) instead of global_tray_id 254 (the external spool). The position-based mapping assumes that: * External spools (254, 255) come after all AMS trays in the sorted list * The slicer assigns slots sequentially starting from 1 For a P2S with AMS 2 Pro + External Spool, the slicer sees: * Slot 1-4: AMS trays * Slot 5: External spool But Bambuddy's sorted list is [0, 1, 2, 3, 254], so: * Slot 1 → 0 (AMS tray 1) * Slot 2 → 1 (AMS tray 2) * Slot 3 → 2 (AMS tray 3) * Slot 4 → 3 (AMS tray 4) * Slot 5 → 254 (External spool) BUT if you print using only the external spool (slot 1 in the 3MF, because it's the only filament), the mapping becomes: * Slot 1 → available_trays[0] → 0 ### Expected Behavior Bambuddy should correctly map the used filament from the external spool. ### Steps to Reproduce * Use a P2S with an AMS 2 Pro. * Load filament from the external spool. * Bambuddy will incorrectly map the filament in use to AMS Slot 1. ### Printer Model P2S ### Bambuddy Version 0.2.2.2 ### Printer Firmware Version 01.01.03.00 ### Installation Method Docker ### Operating System Docker ### 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:31:05 +02:00

closed this issue
added the
bug
label

BreizhHardware commented

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

Author

Owner

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

Thanks for the detailed analysis! The position-based fallback code you identified (lines 872-882) is indeed conceptually flawed — sorted tray IDs don't always map 1:1 to slicer slot positions, and your walkthrough of that logic is correct.

However, for the specific scenario you describe (single-filament 3MF using only the external spool), a different code path should handle it:

For single-filament prints where no explicit mapping is available, the usage tracker uses tray_now from the printer state directly (line 862), not the position-based fallback
When the external spool is active, the P2S reports tray_now=254, which is captured at print start and used for attribution
The position-based fallback (lines 872-882) is only reached when tray_now is unavailable AND the print has multiple filament slots

Could you share a support package (-> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging) from a print where this happened? The [UsageTracker] 3MF: log lines at print completion will show exactly which mapping source and code path was used, so I can confirm whether the position-based fallback was actually hit or if something else went wrong.

@maziggy commented on GitHub (Mar 31, 2026): Thanks for the detailed analysis! The position-based fallback code you identified (lines 872-882) is indeed conceptually flawed — sorted tray IDs don't always map 1:1 to slicer slot positions, and your walkthrough of that logic is correct. However, for the specific scenario you describe (single-filament 3MF using only the external spool), a different code path should handle it: 1. For single-filament prints where no explicit mapping is available, the usage tracker uses tray_now from the printer state directly (line 862), not the position-based fallback 2. When the external spool is active, the P2S reports tray_now=254, which is captured at print start and used for attribution 3. The position-based fallback (lines 872-882) is only reached when tray_now is unavailable AND the print has multiple filament slots Could you share a support package (-> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging) from a print where this happened? The [UsageTracker] 3MF: log lines at print completion will show exactly which mapping source and code path was used, so I can confirm whether the position-based fallback was actually hit or if something else went wrong.

BreizhHardware commented

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

Author

Owner

@anunayk commented on GitHub (Mar 31, 2026):

I loaded filament from an external spool but Bambuddy assigned the loaded filament to AMS slot 1 (see screenshot). This is prior to printing from the external spool.

Here is a support package: bambuddy-support-20260401-022055.zip. I hope it helps!

@anunayk commented on GitHub (Mar 31, 2026): I loaded filament from an external spool but Bambuddy assigned the loaded filament to AMS slot 1 (see screenshot). This is prior to printing from the external spool. <img width="260" height="248" alt="Image" src="https://github.com/user-attachments/assets/f6016ba0-737a-44f9-9040-6c46ea45e6fd" /> Here is a support package: [bambuddy-support-20260401-022055.zip](https://github.com/user-attachments/files/26389416/bambuddy-support-20260401-022055.zip). I hope it helps!

BreizhHardware commented

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

Author

Owner

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

Please use ghcr.io/maziggy/bambuddy:daily and check again.

@maziggy commented on GitHub (Apr 1, 2026): Please use ghcr.io/maziggy/bambuddy:daily and check again.

BreizhHardware commented

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

Author

Owner

@anunayk commented on GitHub (Apr 1, 2026):

Tried ghcr.io/maziggy/bambuddy:daily just now (I was on 0.2.2.2) but to no avail. Upon loading filament from the external spool, Bambuddy incorrectly recognizes it as AMS Slot 1.

@anunayk commented on GitHub (Apr 1, 2026): Tried `ghcr.io/maziggy/bambuddy:daily` just now (I was on 0.2.2.2) but to no avail. Upon loading filament from the external spool, Bambuddy incorrectly recognizes it as AMS Slot 1. <img width="669" height="557" alt="Image" src="https://github.com/user-attachments/assets/e978bc5e-8aa1-413e-8295-9aa0c125199d" />

BreizhHardware commented

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

Author

Owner

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

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

@maziggy commented on GitHub (Apr 2, 2026): Available/Fixed in branch dev and available with the next release or daily build. Please let me know if it works for ou now.