Multi-printer: filament profiles aren't isolated per printer (shared [filament_profiles] section + dropdown mixes printers) #74

New Issue

walterioo · 2026-06-30T06:33:59+02:00

walterioo commented

2026-06-30 06:33:59 +02:00

Hey, running 0.9.27 with two Kobra X printers in one bridge (printer_1 on :7125, printer_2 on :7126). I hit two problems with the per-slot filament profiles that turned out to be related — both come down to the filament side not being split per printer the way the connection is.

1) The slot → profile mapping lives in one global [filament_profiles] section

It's shared between both printers. If I set up the slots on printer 1 and then on printer 2, printer 2 clobbers printer 1, and after a restart (Watchtower updates mine hourly) both come back up with the same mapping — whichever I saved last. visible_vendors does the same thing.

Quick repro:

On :7125 set slot 0 to "Anycubic PLA+".
On :7126 set slot 0 to "SUNLU PLA Basic".
Restart the container — now both ports show the same mapping.

You can also see it live without a restart: GET /kx/filament/slots on both ports returns identical filament_id / vendor / name per slot, even though each printer has different filaments loaded.

Looks like the connection got namespaced per printer ([printer_N] + self._printer_id) but the filament config didn't:

config_loader.py — list/save_filament_profiles and list/save_visible_vendors all use a hardcoded [filament_profiles] section with no printer id, and save_filament_profiles removes + rewrites the whole section, so the last printer to save wins.
kobrax_moonraker_bridge.py — KobraXBridge.init loads list_filament_profiles() with no id, and handle_kx_filament_slot_profile / handle_kx_visible_vendors save with no id.

This one only becomes visible once #1 is worked around and the two printers actually have different mappings. Open the :7125 page, pick "Kobra 2" in the dropdown, and the filament panel shows Kobra 2's real AMS colors but Kobra 1's profile names. In my case K2's gates are yellow/brown/white/black, but the names read KINGROON / KINGROON / SUNLU / CONJURE, which are K1's profiles.

The dropdown links are href="/printerN", so they navigate within the same port (you end up on :7125/printer2). The page then has to pull Kobra 2's data cross-instance from :7126 via bridge_url, but the /kx/filament/slots (profile name) fetch ends up hitting the local origin (:7125 = K1) — either it isn't using bridge_url or it races initPrinters() setting _activePrinter. So you get K2's colors with K1's names. The mmu/AMS data itself is correct per port; it's just the profile names that leak. Opening :7126 directly is always correct (same origin).

Suggested fixes

Namespace the filament config per printer, e.g. [filament_profiles_], by threading self._printer_id into those four config_loader functions (fall back to the global [filament_profiles] when there's no id, for single-printer / back-compat), and migrate the existing section into per-printer ones on first run.
Make the dropdown links point at each printer's own bridge_url (its own port) instead of /printerN, so switching printers lands you same-origin on the right port and there's no cross-instance fetch/race.

I patched both on my box with a boot-time hook and it's been solid — happy to share if it helps.

Thanks for the bridge, it's great otherwise.

Hey, running 0.9.27 with two Kobra X printers in one bridge (printer_1 on :7125, printer_2 on :7126). I hit two problems with the per-slot filament profiles that turned out to be related — both come down to the filament side not being split per printer the way the connection is. ## 1) The slot → profile mapping lives in one global [filament_profiles] section It's shared between both printers. If I set up the slots on printer 1 and then on printer 2, printer 2 clobbers printer 1, and after a restart (Watchtower updates mine hourly) both come back up with the same mapping — whichever I saved last. visible_vendors does the same thing. Quick repro: 1. On :7125 set slot 0 to "Anycubic PLA+". 2. On :7126 set slot 0 to "SUNLU PLA Basic". 3. Restart the container — now both ports show the same mapping. You can also see it live without a restart: GET /kx/filament/slots on both ports returns identical filament_id / vendor / name per slot, even though each printer has different filaments loaded. Looks like the connection got namespaced per printer ([printer_N] + self._printer_id) but the filament config didn't: - config_loader.py — list/save_filament_profiles and list/save_visible_vendors all use a hardcoded [filament_profiles] section with no printer id, and save_filament_profiles removes + rewrites the whole section, so the last printer to save wins. - kobrax_moonraker_bridge.py — KobraXBridge.__init__ loads list_filament_profiles() with no id, and handle_kx_filament_slot_profile / handle_kx_visible_vendors save with no id. ## 2) The header dropdown shows the other printer's profiles This one only becomes visible once #1 is worked around and the two printers actually have different mappings. Open the :7125 page, pick "Kobra 2" in the dropdown, and the filament panel shows Kobra 2's real AMS colors but Kobra 1's profile names. In my case K2's gates are yellow/brown/white/black, but the names read KINGROON / KINGROON / SUNLU / CONJURE, which are K1's profiles. The dropdown links are href="/printerN", so they navigate within the same port (you end up on :7125/printer2). The page then has to pull Kobra 2's data cross-instance from :7126 via bridge_url, but the /kx/filament/slots (profile name) fetch ends up hitting the local origin (:7125 = K1) — either it isn't using bridge_url or it races initPrinters() setting _activePrinter. So you get K2's colors with K1's names. The mmu/AMS data itself is correct per port; it's just the profile names that leak. Opening :7126 directly is always correct (same origin). ## Suggested fixes - Namespace the filament config per printer, e.g. [filament_profiles_<id>], by threading self._printer_id into those four config_loader functions (fall back to the global [filament_profiles] when there's no id, for single-printer / back-compat), and migrate the existing section into per-printer ones on first run. - Make the dropdown links point at each printer's own bridge_url (its own port) instead of /printerN, so switching printers lands you same-origin on the right port and there's no cross-instance fetch/race. I patched both on my box with a boot-time hook and it's been solid — happy to share if it helps. Thanks for the bridge, it's great otherwise.

walterioo commented

2026-06-30 06:37:38 +02:00

Sorry about the AI write up, not very technical and Claude helped me fix this issue

walterioo referenced a pull request that will close this issue

2026-06-30 07:13:13 +02:00

fix: isolate filament profiles per printer in multi-printer bridge #75

walterioo commented

2026-06-30 07:16:14 +02:00

Opened #75 with a fix for this — per-printer [filament_profiles_<id>] sections plus the dropdown port fix. Targets nightly.

Opened #75 with a fix for this — per-printer `[filament_profiles_<id>]` sections plus the dropdown port fix. Targets `nightly`.

viewit closed this issue

2026-06-30 10:21:57 +02:00