Automatic Filament Mapping for Custom profiles #101

New Issue

Blaim · 2026-07-24T17:34:56+02:00

Blaim commented

2026-07-24 17:34:56 +02:00

Description

This could either be a bug report or an enhancement so I'm not sure which one is correct, but since it's a bit offside the official way I gonna make this as an enhancement request.

Please add support for automatic custom filament profile mapping when using third-party RFID tags generated by apps like "ACE RFID". Currently, when loading a spool with a custom-written tag (e.g., "GEEETECH PLA Bas"), the bridge fails to automatically match it to the correct user profile which I uploaded via KX Bridge. Instead of mapping to the intended profile, it falls back to a default like "Generic ABS" and syncs this incorrect data to OrcaSlicer. I have to manually reassign the slot in the bridge UI to fix the sync.

Example:

Red is fixed via manually selecting the correct profile and the Hub Display correctly displays the brand (Geeetech)

If I dont do it (For White in this example) it's unable to map the profile and filament type:

The issue seems to stem from how Anycubic and ACE RFID handle custom tags: they map Vendor, Type, and Serial (e.g., "Basic") into a single "Type" string. So instead of the type just being "PLA", the printer reports a combined string like "GEEETECH PLA Bas". Because KX-Bridge sees this entire string as an unknown material type, it fails to map it and falls back to a default like "Generic ABS". I then have to manually reassign the slot in the bridge UI to sync it with OrcaSlicer.

Funny enough Anycubic Slicer Next has no Problem at all with his behavior and correctly maps custom profiles with custom RFID Tags.

ACE RFID

Motivation

I'm not sure if many users rely on custom RFID tags to automate filament loading for third-party brands in the ACE 2 Unit / Ace 2 Pro. When the bridge fails to map these custom strings to the uploaded OrcaSlicer user profiles, it defeats the automation purpose of the RFID tags and creates friction. Proper handling of these custom strings would allow a fully seamless "plug and play" experience for third-party filaments, preventing failed syncs or accidental prints with "Generic ABS" settings.

Proposed Implementation

String Parsing for the "Type" Field: Since the RFID tag concatenates Vendor, Material, and Serial into one string (e.g., "Geeetech PLA Bas"), update the bridge's parsing logic to split or regex-match this combined string to extract the core material type (e.g., "PLA") and the vendor. If it just says "PLA/ ABS etc" default to Anycubic Profiles.
Improve OrcaSlicer Profile Matching: Once the combined string is split into usable fragments (Vendor + Material), pass those fragments through the existing OrcaSlicer-KX matching logic so it correctly auto-selects the imported user profile.

## Description This could either be a bug report or an enhancement so I'm not sure which one is correct, but since it's a bit offside the official way I gonna make this as an enhancement request. Please add support for automatic custom filament profile mapping when using third-party RFID tags generated by apps like "ACE RFID". Currently, when loading a spool with a custom-written tag (e.g., "GEEETECH PLA Bas"), the bridge fails to automatically match it to the correct user profile which I uploaded via KX Bridge. Instead of mapping to the intended profile, it falls back to a default like "Generic ABS" and syncs this incorrect data to OrcaSlicer. I have to manually reassign the slot in the bridge UI to fix the sync. Example: <img width="274" alt="image.png" src="attachments/6eb2b7f2-7261-41f0-8716-1cb4b06f15a8"> <img width="250" alt="image.png" src="attachments/29e45a60-a966-41af-b12b-7c4e44daaf05"> Red is fixed via manually selecting the correct profile and the Hub Display correctly displays the brand (Geeetech) If I dont do it (For White in this example) it's unable to map the profile and filament type: <img width="237" alt="image.png" src="attachments/0f4af4f5-4ef4-47e6-82b3-991262f41162"> The issue seems to stem from how Anycubic and ACE RFID handle custom tags: they map Vendor, Type, and Serial (e.g., "Basic") into a single "Type" string. So instead of the type just being "PLA", the printer reports a combined string like "GEEETECH PLA Bas". Because KX-Bridge sees this entire string as an unknown material type, it fails to map it and falls back to a default like "Generic ABS". I then have to manually reassign the slot in the bridge UI to sync it with OrcaSlicer. Funny enough Anycubic Slicer Next has no Problem at all with his behavior and correctly maps custom profiles with custom RFID Tags. ACE RFID <img width="353" alt="image.png" src="attachments/d259f095-98b0-40d0-9661-225d6252e2ee"> <img width="319" alt="image.png" src="attachments/86a86d97-9f24-4354-8e0d-c3498fa44c71"> ## Motivation I'm not sure if many users rely on custom RFID tags to automate filament loading for third-party brands in the ACE 2 Unit / Ace 2 Pro. When the bridge fails to map these custom strings to the uploaded OrcaSlicer user profiles, it defeats the automation purpose of the RFID tags and creates friction. Proper handling of these custom strings would allow a fully seamless "plug and play" experience for third-party filaments, preventing failed syncs or accidental prints with "Generic ABS" settings. ## Proposed Implementation - String Parsing for the "Type" Field: Since the RFID tag concatenates Vendor, Material, and Serial into one string (e.g., "Geeetech PLA Bas"), update the bridge's parsing logic to split or regex-match this combined string to extract the core material type (e.g., "PLA") and the vendor. If it just says "PLA/ ABS etc" default to Anycubic Profiles. - Improve OrcaSlicer Profile Matching: Once the combined string is split into usable fragments (Vendor + Material), pass those fragments through the existing OrcaSlicer-KX matching logic so it correctly auto-selects the imported user profile.

image.png

20 KiB

image.png

15 KiB

image.png

16 KiB

image.png

128 KiB

image.png

55 KiB

Blaim added the

enhancement

label 2026-07-24 17:34:56 +02:00

viewit commented

2026-07-26 23:19:51 +02:00

Thanks for the clear writeup and the proposed implementation direction, @Blaim — you correctly identified the mechanism (Anycubic's ACE RFID system concatenating vendor+material+serial into one type string).

Implemented roughly as you proposed:

Parsing: a new _parse_combined_rfid_type() splits the raw type string and checks whether the first token matches a known vendor — checked against your imported profile library too (not just the built-in vendor list), so a custom vendor like "Geeetech" that only exists because you uploaded it via the ZIP import is recognized. The remaining tokens are reduced to the material family (PLA/PETG/ABS/etc.) via the existing family-detection logic. A plain type="PLA" report (no vendor prefix) is left completely untouched — no vendor match, no behavior change for the normal case.
Matching: since the truncated RFID string ('Bas' for 'Basic') never contains the full profile name, matching is done by (vendor, material family) rather than exact name — so "GEEETECH PLA Bas" resolves to whatever Geeetech PLA profile you've imported, regardless of its exact display name.
This runs as a third resolution layer in _build_lane_data, after your existing manual per-slot override (still takes priority if set) and before the Generic-library fallback (still used if no matching vendor/profile is found). It's not persisted to config.ini — it re-derives fresh every time, so loading a different tag later can't leave a stale mapping behind.

Added a test suite covering the exact "GEEETECH PLA Bas" scenario plus regression checks for plain type="PLA" and unknown-vendor cases. Committed locally on nightly, going out with the next nightly build — would appreciate it if you could confirm it resolves the auto-sync for your Geeetech slot once you get a chance to test it.

Thanks for the clear writeup and the proposed implementation direction, @Blaim — you correctly identified the mechanism (Anycubic's ACE RFID system concatenating vendor+material+serial into one `type` string). Implemented roughly as you proposed: 1. **Parsing**: a new `_parse_combined_rfid_type()` splits the raw `type` string and checks whether the first token matches a known vendor — checked against your *imported* profile library too (not just the built-in vendor list), so a custom vendor like "Geeetech" that only exists because you uploaded it via the ZIP import is recognized. The remaining tokens are reduced to the material family (PLA/PETG/ABS/etc.) via the existing family-detection logic. A plain `type="PLA"` report (no vendor prefix) is left completely untouched — no vendor match, no behavior change for the normal case. 2. **Matching**: since the truncated RFID string ('Bas' for 'Basic') never contains the full profile name, matching is done by (vendor, material family) rather than exact name — so "GEEETECH PLA Bas" resolves to whatever Geeetech PLA profile you've imported, regardless of its exact display name. 3. This runs as a third resolution layer in `_build_lane_data`, after your existing manual per-slot override (still takes priority if set) and before the Generic-library fallback (still used if no matching vendor/profile is found). It's *not* persisted to `config.ini` — it re-derives fresh every time, so loading a different tag later can't leave a stale mapping behind. Added a test suite covering the exact `"GEEETECH PLA Bas"` scenario plus regression checks for plain `type="PLA"` and unknown-vendor cases. Committed locally on `nightly`, going out with the next nightly build — would appreciate it if you could confirm it resolves the auto-sync for your Geeetech slot once you get a chance to test it.

viewit referenced this issue from a commit

2026-07-26 23:38:43 +02:00

feat(filament): auto-match combined ACE-RFID vendor+type strings (Issue #101)

Blaim commented

2026-07-27 02:12:19 +02:00

Thanks for this quick implementation!

I was reading through your implementation details, and I realized there might be one edge case with the (vendor, material family) matching logic: What happens when I have multiple profiles for the same brand and material?

For example, I use both Geeetech PLA Basic and Geeetech PLA Matte. If the system drops the third token and only matches on Vendor + Material, I assume it won't be able to tell the difference between the two and might just pick whichever profile it loads first?

For context on why it’s truncated to Bas: I actually had to abbreviate "Basic" because Anycubic has a strict maximum character limit for the RFID tag strings so even if I would write Basic out, Anycubic would truncate it on its own.

To help distinguish between sub-types, do you think we could handle it in one of these two ways?

Substring matching: Could the logic use that third token (Bas, Matte, etc.) to do a partial text match against the uploaded profile names? (e.g., checking if the profile name contains "Bas")?
Tag formatting adjustment (on my end): If substring matching is too messy to implement, I can easily abbreviate the vendor to free up characters. I could flash the tags as GT PLA Basic and GT PLA Matte. If I do that, could the parsing logic use the exact third token to match the sub-type? Thats also why I named the Profile the exact way the string gets submitted as this worked for Anycubic's Slicer Next automatching aswell.

Let me know what you think makes the most sense! And will give the nightly a try :)

Thanks for this quick implementation! I was reading through your implementation details, and I realized there might be one edge case with the (vendor, material family) matching logic: What happens when I have multiple profiles for the same brand and material? For example, I use both Geeetech PLA Basic and Geeetech PLA Matte. If the system drops the third token and only matches on Vendor + Material, I assume it won't be able to tell the difference between the two and might just pick whichever profile it loads first? For context on why it’s truncated to Bas: I actually had to abbreviate "Basic" because Anycubic has a strict maximum character limit for the RFID tag strings so even if I would write Basic out, Anycubic would truncate it on its own. To help distinguish between sub-types, do you think we could handle it in one of these two ways? - Substring matching: Could the logic use that third token (Bas, Matte, etc.) to do a partial text match against the uploaded profile names? (e.g., checking if the profile name contains "Bas")? - Tag formatting adjustment (on my end): If substring matching is too messy to implement, I can easily abbreviate the vendor to free up characters. I could flash the tags as GT PLA Basic and GT PLA Matte. If I do that, could the parsing logic use the exact third token to match the sub-type? Thats also why I named the Profile the exact way the string gets submitted as this worked for Anycubic's Slicer Next automatching aswell. Let me know what you think makes the most sense! And will give the nightly a try :)

Blaim commented

2026-07-27 02:52:42 +02:00

I'm on v0.9.28-nightly45 and it doesn't seem to work sadly

I'm on v0.9.28-nightly45 and it doesn't seem to work sadly <img width="275" alt="image.png" src="attachments/6bf57b00-924e-4497-bc9c-e7a7e87d62bf">

image.png

17 KiB

Sign in to join this conversation.