Bug with Ace 2 Pro ?! #47
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
It seems, that Orca use the wrong filament slots in the Ace .. All shiftet by one ..
Are you sure, that slot 4 is first slot in Ace Pro ? It seems it must be skipped ..
so 1-3 > Kobra x
5-8 > Ace and 4 should be skipped..
(it use slot 5 in ace and it should use slot 6 in ace ...)
KX-Bridge V v0.9.19.1
Thanks for the detailed report!
You are correct — the slot numbering for the Ace Pro appears to be off by one. The internal mapping in KX-Bridge needs to skip slot 4 (which is unused in the Ace Pro configuration) so that:
This is a bug in the KX-Bridge slot mapping, not in OrcaSlicer.
Could you share the KX-Bridge logs (the section around the AMS sync) so we can verify the exact offset? That will help us pinpoint the fix.
Bridge version v0.9.19.1 confirmed.
Hold on, this was intended. If we label the first Slot in the ACE2 as Slot 5, it's still going to sync to Filament 4 in Orca. It was better to label it as Slot 4 to match Orca filament count. AnyCubicSlicerNext also marks first ACE slot as Filament 4
Thanks @gangoke for catching that!
You are right — I was too quick to confirm this as a bug. The current mapping (ACE0 starting at slot 4 in the global index) is consistent with how OrcaSlicer counts the AMS slots internally.
@peterjoachim Can you clarify exactly what you are seeing?
A screenshot of the OrcaSlicer AMS panel alongside the bridge UI would help a lot here. No code change will be made until we have confirmed the actual behavior.
One more note: we currently do not have an ACE 2 Pro unit available for testing, which makes it difficult to reproduce and verify slot-mapping issues directly. Any logs, screenshots or detailed step-by-step reproduction steps from users who own the hardware are therefore especially valuable for us to diagnose and fix this correctly.
thats wrong .. puple should be B4 (not B3)
So slot 1-3 of Kobra X is filled .. Ace2Pro is connected to slot 4 and all 4 slots are FULL in Ace 2 Pro ..
So Color should be
1 PVA
2 White PLA
3 Green PLA
4 Empty (Ace 2 Pro connected)
ace 2 pro
1 Red PLA
2 Blue PLA
3 Gray PLA
4 Purple PLA
Screenshot from Anycubic Slicer
Der Kommentar steht bereits oben in meiner vorletzten Antwort — in der Kommentar-Box mit dem „Copy"-Button. Hier nochmal als reiner Text zum Kopieren:
After researching how OrcaSlicer handles slot mapping for multi-AMS / multi-material setups, I'm closing this as wontfix. The reasoning, with concrete comparisons:
OrcaSlicer has no concept of "the ACE as a separate AMS" over Moonraker.
The A1–A4 / B1–B4 grouping you're expecting only exists when Orca talks to a printer over Bambu's proprietary MQTT protocol. There the printer pushes its full AMS topology (which unit, which tray) and Orca builds an interactive mapping dialog from it. As Bambu's own docs state, the filament index in the slicer "has nothing to do with the AMS slot number" — the two are linked only at send time.
KX-Bridge exposes filaments over Moonraker as a flat, linear list. No MQTT topology, no per-unit hierarchy, no send-time mapping dialog. Orca simply sees filaments 1–8 in a row. There is no mechanism over Moonraker to tell it "slot 4 is a connection port, the ACE starts at 5."
The Happy Hare comparison is the most relevant one, since it's the same Klipper/Moonraker base doing real multi-material. It uses a two-stage model
The tool-to-gate (TTG) mapping that connects them lives entirely in the Klipper firmware, never in the slicer. Even a 9-gate MMU presents to Orca as a flat T0–T8 list. And when multiple Box Turtle units are combined, they're merged firmware-side into one logical unit — exactly the model KX-Bridge uses for "Kobra X internal + ACE = one flat list."
Why the current mapping is correct:
This matches Orca's linear filament indexing and matches AnycubicSlicerNext (first ACE slot = filament 4), as @gangoke correctly pointed out. Reserving slot 4 as an empty "connection placeholder" and shifting the ACE to 5–8 would waste a usable filament index and leave a permanently-empty slot in Orca — worse, not better.
The decisive point: the prints are correct.
If the right spool loads and the color is right on the physical print, the mapping is functionally correct. The off-by-one is a labeling difference between how you mentally model the hardware (ACE = its own unit starting fresh) and how Orca indexes a flat filament list. It's a display expectation, not a slicing or loading bug.
A true "ACE-as-separate-AMS" representation would need a dedicated topology protocol plus Orca-side support — neither of which exists over Moonraker, for any printer.
@icebear, @gangoke — the screenshots and the correction were both useful in confirming the behavior is by design. Closing as wontfix; happy to reopen if anyone can demonstrate an actual mis-loaded spool (wrong physical filament on the print) rather than a slot-number labeling mismatch.