viewit/KX-Bridge-Release
10
15
Fork 9
Code Issues 4 Pull Requests Actions 1 Packages Projects Releases 58 Wiki Activity

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

Merged
viewit merged 1 commits from walterioo/KX-Bridge-Release:fix/per-printer-filament-profiles into nightly 2026-06-30 10:21:57 +02:00
Conversation 1 Commits 1 Files Changed 5 +156 -28
walterioo commented 2026-06-30 07:13:13 +02:00
Contributor
Copy Link

Description

In a multi-printer setup (one bridge, several [printer_N]), the per-slot
filament→profile mapping and visible_vendors were stored in a single global
[filament_profiles] section. Configuring one printer overwrote the other, and
after a restart both printers loaded whichever mapping was saved last.

This makes each printer keep its own [filament_profiles_<id>] section by
threading the existing self._printer_id through the four config_loader
helpers. A read-fallback to the legacy global [filament_profiles] section keeps
single-printer setups and existing configs working with no migration step.

It also fixes a related UI symptom: the header printer-dropdown and the
printers-management "switch" link navigated within the same port (/printerN),
so viewing another printer pulled its profile names cross-instance from the local
origin — the AMS colors were correct but the profile names were the local
printer's. The links now point at each printer's own bridge_url, so every
printer is viewed same-origin on its own port.

Notes:

  • printer_id=None keeps the original global section → fully backward compatible.
  • New annotations use Optional[...] (no X | Y) per the contributor guide.

Related Issue

Closes #74

Type

  • Bug fix

Tested with

  • OrcaSlicer Version: OrcaSlicer-KX 2.4.0-kx1
  • Printer: 2× Anycubic Kobra X (one bridge, ports 7125 / 7126)
  • Moonraker/Klipper Version: bridge built-in

Checklist

  • Tests added/updated (tests/test_filament_profiles_per_printer.py)
  • CHANGELOG.md updated
  • No debug code included
## Description In a multi-printer setup (one bridge, several `[printer_N]`), the per-slot filament→profile mapping and `visible_vendors` were stored in a single global `[filament_profiles]` section. Configuring one printer overwrote the other, and after a restart both printers loaded whichever mapping was saved last. This makes each printer keep its own `[filament_profiles_<id>]` section by threading the existing `self._printer_id` through the four `config_loader` helpers. A read-fallback to the legacy global `[filament_profiles]` section keeps single-printer setups and existing configs working with no migration step. It also fixes a related UI symptom: the header printer-dropdown and the printers-management "switch" link navigated within the same port (`/printerN`), so viewing another printer pulled its profile names cross-instance from the local origin — the AMS colors were correct but the profile names were the local printer's. The links now point at each printer's own `bridge_url`, so every printer is viewed same-origin on its own port. Notes: - `printer_id=None` keeps the original global section → fully backward compatible. - New annotations use `Optional[...]` (no `X | Y`) per the contributor guide. ## Related Issue Closes #74 ## Type - [x] Bug fix ## Tested with - OrcaSlicer Version: OrcaSlicer-KX 2.4.0-kx1 - Printer: 2× Anycubic Kobra X (one bridge, ports 7125 / 7126) - Moonraker/Klipper Version: bridge built-in ## Checklist - [x] Tests added/updated (`tests/test_filament_profiles_per_printer.py`) - [x] CHANGELOG.md updated - [x] No debug code included
walterioo added 1 commit 2026-06-30 07:13:13 +02:00
fix: isolate filament profiles per printer in multi-printer bridge (#74)
Some checks are pending
PR Check / lint-and-test (pull_request) Blocked by required conditions
Details
0e1d46ee7f 
Per-printer [filament_profiles_<id>] sections so configuring one printer no
longer overwrites another (read-fallback to the legacy global section keeps
single-printer setups unchanged). Dropdown/switch links now navigate to each
printer's own bridge_url. Adds pytest coverage and a CHANGELOG entry.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
viewit merged commit 771599be0c into nightly 2026-06-30 10:21:57 +02:00
viewit commented 2026-06-30 10:22:22 +02:00
Owner
Copy Link

Merged — thank you @walterioo!

Clean approach: the _filament_section() helper keeps the logic in one place, and the read-fallback to the legacy global [filament_profiles] section means existing single-printer configs need zero migration. The bridge_url-based navigation fix for the printer dropdown is a nice catch on top.

Tests cover all the relevant cases (isolation, fallback order, vendor-seed on first per-printer write). Will go out with the next nightly build.

Merged — thank you @walterioo! Clean approach: the `_filament_section()` helper keeps the logic in one place, and the read-fallback to the legacy global `[filament_profiles]` section means existing single-printer configs need zero migration. The `bridge_url`-based navigation fix for the printer dropdown is a nice catch on top. Tests cover all the relevant cases (isolation, fallback order, vendor-seed on first per-printer write). Will go out with the next nightly build.
❤️ 1
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
bug
Something is not working
bug
documentation
duplicate
This issue or pull request already exists
enhancement
New feature
enhancement
help wanted
Need some help
invalid
Something is wrong
known-issue
question
More information is needed
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
viewit
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#75
No description provided.
Delete Branch "walterioo/KX-Bridge-Release:fix/per-printer-filament-profiles"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?