viewit/KX-Bridge-Release
11
13
Fork 6
Code Issues 4 Pull Requests Actions Packages Projects Releases 39 Wiki Activity

Bug: Filament sync maps custom user profiles back to vendor parent profile (e.g. Anycubic) instead of user preset name #52

New Issue
Open
opened 2026-06-09 11:42:19 +02:00 by Alex_M · 1 comment
Alex_M commented 2026-06-09 11:42:19 +02:00
Copy Link

Hi viewit,

Following up on the filament synchronization fixes from issue #38, I am still experiencing a mismatch issue specifically with custom user filament profiles created inside OrcaSlicer-KX, depending on which preset they inherit from.

The Problem
As seen in the attached screenshot

image.png

I have a custom filament profile named "Tinmorry PLA Matte". This profile was created in OrcaSlicer by modifying and saving over a default "Anycubic PLA Matte" profile, and it is properly imported and assigned to a slot in the KX-Bridge interface.

However, after performing a sync in OrcaSlicer-KX, the filament slot gets mapped back as "Anycubic PLA Matte" instead of "Tinmorry PLA Matte".

The bridge database stores and sends the custom fields correctly for that slot (curl output):

JSON
{
  "id": "3",
  "tray_info_idx": "GFPLA Matte",
  "tray_type": "PLA",
  "tray_sub_brands": "Tinmorry",
  "name": "Tinmorry PLA Matte",
  "vendor_name": "Tinmorry",
  "filament_id": "GFPLA Matte",
  "filament_vendor": "Tinmorry",
  "filament_name": "Tinmorry PLA Matte",
  "preset": "Tinmorry PLA Matte"
}

The Breakdown: Comparing the JSON Profiles
To isolate why OrcaSlicer overrides this specific profile, I performed a test creating a second custom profile named "Test Tinmorry generic", but this time inheriting from the default "Generic PLA @System" instead of a vendor-specific profile.

Surprisingly, the second test ("Test Tinmorry generic") syncs and displays completely fine!

Here is the direct comparison between the two Orca Cloud/Slicer JSON profiles:

❌ PROFILE THAT FAILS (Maps back to Anycubic PLA Matte):

JSON
{
  "name": "Tinmorry PLA Matte",
  "type": "filament",
  "base_id": "c3921a23-e71a-53a7-ab78-b58250dcb39a",
  "version": "1.3.2512.5",
  "inherits": "Anycubic PLA Matte @Anycubic Kobra X 0.4 nozzle",
  "filament_vendor": "Tinmorry",
  "filament_settings_id": "\"Tinmorry PLA Matte\"",
  "default_filament_colour": "#000000"
}

PROFILE THAT WORKS (Maps correctly as Test Tinmorry generic):

JSON
{
	"compatible_printers": [
		"Anycubic Kobra X 0.4 nozzle"
	],
	"default_filament_colour": [
		"#000000"
	],
	"filament_extruder_variant": [
		"Direct Drive Standard"
	],
	"filament_id": "PC17030C",
	"filament_settings_id": [
		"Test Tinmorry generic"
	],
	"filament_vendor": [
		"Tinmorry"
	],
	"from": "User",
	"inherits": "Generic PLA @System",
	"name": "Test Tinmorry generic",
	"version": "2.4.0.0"
}

Conclusion
The receive-side patch in OrcaSlicer-KX works as intended when a user profile inherits from a clean @System generic preset. However, if the user profile inherits from a vendor-specific preset (like Anycubic PLA Matte @Anycubic Kobra X 0.4 nozzle), OrcaSlicer's internal mapping logic triggers a hard fallback to the vendor's parent preset, completely ignoring the filament_name or preset string sent by the bridge.

Could the logic in MoonrakerPrinterAgent.cpp be adjusted to strictly prioritize a match against the user's custom filament_settings_id or name before OrcaSlicer evaluates its internal vendor-hierarchy fallback?

Thank you for your incredible work on this project!

Hi viewit, Following up on the filament synchronization fixes from issue #38, I am still experiencing a mismatch issue specifically with custom user filament profiles created inside OrcaSlicer-KX, depending on which preset they inherit from. The Problem As seen in the attached screenshot ![image.png](/attachments/aa7ad3cc-9fe0-4e42-a805-8d0a8c5fb4c1) I have a custom filament profile named "Tinmorry PLA Matte". This profile was created in OrcaSlicer by modifying and saving over a default "Anycubic PLA Matte" profile, and it is properly imported and assigned to a slot in the KX-Bridge interface. However, after performing a sync in OrcaSlicer-KX, the filament slot gets mapped back as "Anycubic PLA Matte" instead of "Tinmorry PLA Matte". The bridge database stores and sends the custom fields correctly for that slot (curl output): ``` JSON { "id": "3", "tray_info_idx": "GFPLA Matte", "tray_type": "PLA", "tray_sub_brands": "Tinmorry", "name": "Tinmorry PLA Matte", "vendor_name": "Tinmorry", "filament_id": "GFPLA Matte", "filament_vendor": "Tinmorry", "filament_name": "Tinmorry PLA Matte", "preset": "Tinmorry PLA Matte" } ``` The Breakdown: Comparing the JSON Profiles To isolate why OrcaSlicer overrides this specific profile, I performed a test creating a second custom profile named "Test Tinmorry generic", but this time inheriting from the default "Generic PLA @System" instead of a vendor-specific profile. Surprisingly, the second test ("Test Tinmorry generic") syncs and displays completely fine! Here is the direct comparison between the two Orca Cloud/Slicer JSON profiles: ❌ PROFILE THAT FAILS (Maps back to Anycubic PLA Matte): ``` JSON { "name": "Tinmorry PLA Matte", "type": "filament", "base_id": "c3921a23-e71a-53a7-ab78-b58250dcb39a", "version": "1.3.2512.5", "inherits": "Anycubic PLA Matte @Anycubic Kobra X 0.4 nozzle", "filament_vendor": "Tinmorry", "filament_settings_id": "\"Tinmorry PLA Matte\"", "default_filament_colour": "#000000" } ``` PROFILE THAT WORKS (Maps correctly as Test Tinmorry generic): ``` JSON { "compatible_printers": [ "Anycubic Kobra X 0.4 nozzle" ], "default_filament_colour": [ "#000000" ], "filament_extruder_variant": [ "Direct Drive Standard" ], "filament_id": "PC17030C", "filament_settings_id": [ "Test Tinmorry generic" ], "filament_vendor": [ "Tinmorry" ], "from": "User", "inherits": "Generic PLA @System", "name": "Test Tinmorry generic", "version": "2.4.0.0" } ``` Conclusion The receive-side patch in OrcaSlicer-KX works as intended when a user profile inherits from a clean @System generic preset. However, if the user profile inherits from a vendor-specific preset (like Anycubic PLA Matte @Anycubic Kobra X 0.4 nozzle), OrcaSlicer's internal mapping logic triggers a hard fallback to the vendor's parent preset, completely ignoring the filament_name or preset string sent by the bridge. Could the logic in MoonrakerPrinterAgent.cpp be adjusted to strictly prioritize a match against the user's custom filament_settings_id or name before OrcaSlicer evaluates its internal vendor-hierarchy fallback? Thank you for your incredible work on this project!
image.png
23 KiB
viewit commented 2026-06-10 15:37:37 +02:00
Owner
Copy Link

Thank you @Alex_M for the detailed analysis — you identified the root cause precisely.

Root cause confirmed:
When a user preset inherits from a vendor-specific preset (e.g. "Anycubic PLA Matte @Anycubic Kobra X 0.4 nozzle"), OrcaSlicer’s internal preset.config.opt_string("filament_vendor") resolves the value from the parent preset ("Anycubic"), not from the user preset itself. The KX matcher filters by the bridge-supplied vendor ("Tinmorry"), sees a mismatch, skips the user preset in all three passes, and falls back to the generic vendor preset.

A preset derived from "Generic PLA @System" works because the parent has no vendor — the vendor filter is not triggered and name matching proceeds normally.

Fix in progress:
The matcher in MoonrakerPrinterAgent.cpp will be updated to skip the vendor filter for user presets, since the name match itself is strict enough to prevent false positives. This will be part of the next OrcaSlicer-KX build.

Workaround until then:
Re-create the preset using "Generic PLA @System" (or another @System preset) as the base instead of the Anycubic vendor preset. The temperature and other settings can be copied over manually. The resulting preset will sync correctly.

Thank you @Alex_M for the detailed analysis — you identified the root cause precisely. **Root cause confirmed:** When a user preset inherits from a vendor-specific preset (e.g. `"Anycubic PLA Matte @Anycubic Kobra X 0.4 nozzle"`), OrcaSlicer’s internal `preset.config.opt_string("filament_vendor")` resolves the value from the **parent** preset (`"Anycubic"`), not from the user preset itself. The KX matcher filters by the bridge-supplied vendor (`"Tinmorry"`), sees a mismatch, skips the user preset in all three passes, and falls back to the generic vendor preset. A preset derived from `"Generic PLA @System"` works because the parent has no vendor — the vendor filter is not triggered and name matching proceeds normally. **Fix in progress:** The matcher in `MoonrakerPrinterAgent.cpp` will be updated to skip the vendor filter for user presets, since the name match itself is strict enough to prevent false positives. This will be part of the next OrcaSlicer-KX build. **Workaround until then:** Re-create the preset using `"Generic PLA @System"` (or another `@System` preset) as the base instead of the Anycubic vendor preset. The temperature and other settings can be copied over manually. The resulting preset will sync correctly.
viewit added the
bug
 label 2026-06-10 15:38:54 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
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
bug
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#52
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?