Feature Request: Smart Upload-and-Print validation, UI layout adjustments & Native Spoolman/Slicing integration #67

New Issue

Alex_M · 2026-06-19T10:34:04+02:00

Alex_M commented

2026-06-19 10:34:04 +02:00

Following up on the ongoing work in ticket #57, I would like to propose a few more improvements regarding workflow safety, UI/UX optimization, and a major strategic direction for the backend of KX-Bridge.

Smart Filament Validation for "Upload and Print" Workflow
When sending a file via "direct Orca uploads" using the Upload button, the current behavior (triggering the Slot Mapper on the bridge) works great. However, I believe we should add a safety layer for the "Upload and Print" (Direct Print) button to prevent accidental printing errors (e.g., sending a cloud file with wrong profiles without realizing it).
My idea is to implement a background filament check before the print actually starts:
- Scenario A (Filaments Match): If the filaments defined in OrcaSlicer perfectly match the ones loaded on the KX-Bridge (ACE system), the file goes straight to print without any interruptions (fast workflow).
- Scenario B (Filaments Mismatch or Unknown): If the KX-Bridge detects any discrepancy between the G-code demands and the active ACE slots (e.g., G-code requests PETG but PLA is loaded), it should intercept and block the auto-start, and forcefully pop up the Slot Mapper window to warn me so I can map/correct them properly.
Unified "Axes Control" Window Layout
The current control layout is split into two separate cards ("XY AXES" and "Z AXIS"). This creates some UX inconsistencies: the Home Z button sits inside the XY card, and the Z-axis step size is locked to a separate text indicator.
I suggest merging them into a single, comprehensive "AXES CONTROL" panel with the following layout adjustments:
- Unified Step Sizes: A single row of step selectors (0.1, 1, 5, 10 mm) that dynamically applies to both XY and Z movements.
- Proximity Homing: Place the Home XY button under the XY direction pad, and the Home Z button right under the Z up/down arrows.
- Centered Global Commands: Position the global buttons—Home All and Motors Off—centered at the very bottom of this unified card, as they affect the entire machine rather than individual axes.
Streamlining UI: Move Language Selector to Settings
Currently, there is a language dropdown menu right in the top header bar of the main screen. Since language is an option that an average user configures only once, having it permanently on the main header takes up unnecessary space. I propose removing it from the top bar entirely and leaving it exclusively inside the global Settings -> Appearance panel to make the dashboard cleaner.
Spoolman Integration: Next Steps & Smart Pre-Print Verification
I am incredibly excited to see the recent PR #65 adding optional Spoolman integration for filament consumption tracking! It is a massive step forward for making KX-Bridge a self-contained ecosystem.
Building on top of this new implementation, I would like to propose the next logical evolution for this feature:
- Pre-Print Weight Validation (The "Safety Check"): When the Bridge can map active AMS/ACE slots to Spoolman spool IDs, it won't simply have to monitor consumption after or during printing. When a G-code is loaded, the Bridge can compare the estimated weight/length of filament required for the job with the remaining weight stored in Spoolman for that specific spool. If a spool is too low, Slot Mapper should intercept the workflow and warn before printing begins.
- Multi-Color Consumption Accuracy: I noticed the known limitation regarding the aggregate counter split equally among slots in multi-color prints. The suggested improvement path in the PR notes (tracking supplies_usage deltas against loaded_slot via MQTT every ~3 seconds, while filtering out purges via feed_status) sounds perfect. I highly support prioritizing this incremental per-slot tracking to match Klipper/Moonraker accuracy.
Autonomous Local Ecosystem via Integrated Slicing (Bambuddy Integration)
Tying Spoolman validation and the advanced Slot Mapper together, I would love to bring back slm4996's proposal in issue #62 regarding Bambuddy integrated slicing.
If KX-Bridge eventually incorporates an integrated slicing sidecar, it would elevate the project from a communication bridge to a fully autonomous local platform. This would unlock an incredible untethered workflow:
- I could upload a .3mf project or a raw .stl file directly from my smartphone or browser into the KX-Bridge UI.
- The Bridge would slice it in the background using pre-configured OrcaSlicer profiles.
- It would automatically cross-check the sliced data with Spoolman (to ensure enough filament is left) and handle the Slot Mapper autonomously.
- The print starts directly, without me ever needing to power on a computer or open the desktop slicer.

Sorry for the wall of text!

Following up on the ongoing work in ticket #57, I would like to propose a few more improvements regarding workflow safety, UI/UX optimization, and a major strategic direction for the backend of KX-Bridge. 1. Smart Filament Validation for "Upload and Print" Workflow When sending a file via "direct Orca uploads" using the Upload button, the current behavior (triggering the Slot Mapper on the bridge) works great. However, I believe we should add a safety layer for the "Upload and Print" (Direct Print) button to prevent accidental printing errors (e.g., sending a cloud file with wrong profiles without realizing it). My idea is to implement a background filament check before the print actually starts: * Scenario A (Filaments Match): If the filaments defined in OrcaSlicer perfectly match the ones loaded on the KX-Bridge (ACE system), the file goes straight to print without any interruptions (fast workflow). * Scenario B (Filaments Mismatch or Unknown): If the KX-Bridge detects any discrepancy between the G-code demands and the active ACE slots (e.g., G-code requests PETG but PLA is loaded), it should intercept and block the auto-start, and forcefully pop up the Slot Mapper window to warn me so I can map/correct them properly. 2. Unified "Axes Control" Window Layout The current control layout is split into two separate cards ("XY AXES" and "Z AXIS"). This creates some UX inconsistencies: the Home Z button sits inside the XY card, and the Z-axis step size is locked to a separate text indicator. I suggest merging them into a single, comprehensive "AXES CONTROL" panel with the following layout adjustments: * Unified Step Sizes: A single row of step selectors (0.1, 1, 5, 10 mm) that dynamically applies to both XY and Z movements. * Proximity Homing: Place the Home XY button under the XY direction pad, and the Home Z button right under the Z up/down arrows. * Centered Global Commands: Position the global buttons—Home All and Motors Off—centered at the very bottom of this unified card, as they affect the entire machine rather than individual axes. 3. Streamlining UI: Move Language Selector to Settings Currently, there is a language dropdown menu right in the top header bar of the main screen. Since language is an option that an average user configures only once, having it permanently on the main header takes up unnecessary space. I propose removing it from the top bar entirely and leaving it exclusively inside the global Settings -> Appearance panel to make the dashboard cleaner. 4. Spoolman Integration: Next Steps & Smart Pre-Print Verification I am incredibly excited to see the recent PR #65 adding optional Spoolman integration for filament consumption tracking! It is a massive step forward for making KX-Bridge a self-contained ecosystem. Building on top of this new implementation, I would like to propose the next logical evolution for this feature: * Pre-Print Weight Validation (The "Safety Check"): When the Bridge can map active AMS/ACE slots to Spoolman spool IDs, it won't simply have to monitor consumption after or during printing. When a G-code is loaded, the Bridge can compare the estimated weight/length of filament required for the job with the remaining weight stored in Spoolman for that specific spool. If a spool is too low, Slot Mapper should intercept the workflow and warn before printing begins. * Multi-Color Consumption Accuracy: I noticed the known limitation regarding the aggregate counter split equally among slots in multi-color prints. The suggested improvement path in the PR notes (tracking supplies_usage deltas against loaded_slot via MQTT every ~3 seconds, while filtering out purges via feed_status) sounds perfect. I highly support prioritizing this incremental per-slot tracking to match Klipper/Moonraker accuracy. 5. Autonomous Local Ecosystem via Integrated Slicing (Bambuddy Integration) Tying Spoolman validation and the advanced Slot Mapper together, I would love to bring back slm4996's proposal in issue #62 regarding Bambuddy integrated slicing. If KX-Bridge eventually incorporates an integrated slicing sidecar, it would elevate the project from a communication bridge to a fully autonomous local platform. This would unlock an incredible untethered workflow: * I could upload a .3mf project or a raw .stl file directly from my smartphone or browser into the KX-Bridge UI. * The Bridge would slice it in the background using pre-configured OrcaSlicer profiles. * It would automatically cross-check the sliced data with Spoolman (to ensure enough filament is left) and handle the Slot Mapper autonomously. * The print starts directly, without me ever needing to power on a computer or open the desktop slicer. Sorry for the wall of text!

👍 1

p2l commented

2026-06-19 13:45:57 +02:00

I have a branch with some UI changes in it, I never quite got it where I wanted but I agree right now it's sub-optimal depending on how you're viewing the page.

The Spoolman PR is something I will spend more time on but I wanted to at least put it out there for visibility as it's likely to be several days before I can spend any significant time on it again.

I have a branch with some UI changes in it, I never quite got it where I wanted but I agree right now it's sub-optimal depending on how you're viewing the page. The Spoolman PR is something I will spend more time on but I wanted to at least put it out there for visibility as it's likely to be several days before I can spend any significant time on it again.

viewit commented

2026-06-19 14:36:09 +02:00

:This feature goes far beyond the basic concept of the kx bridge. But I'm planning a standalone fork of Orca Slicer combined with Obicoo and SpoolManager. That will take a while, though. First, I want to make the kx bridge completely bug-free, except for a few minor features.
The remaining features will be implemented in future versions, though.

5. :This feature goes far beyond the basic concept of the kx bridge. But I'm planning a standalone fork of Orca Slicer combined with Obicoo and SpoolManager. That will take a while, though. First, I want to make the kx bridge completely bug-free, except for a few minor features. The remaining features will be implemented in future versions, though.

Alex_M commented

2026-06-19 17:25:25 +02:00

Thanks for sharing your vision, @viewit! A specialized ecosystem sounds powerful.

However, looking at it from a long-term maintenance perspective, managing a standalone Orca fork can become incredibly time-consuming, as it often struggles to keep up with the fast-paced upstream releases from official OrcaSlicer (as we can see with Orca-KX currently being on dev while official Orca is already in Beta).

Personally, I see a huge potential in making KX-Bridge the ultimate, powerful "Universal Hub" instead. If the Bridge focuses on exposing standard APIs (similar to how Moonraker handles Klipper), it would allow users to always use the official, up-to-date OrcaSlicer (or any other standard slicer) while leaving all the heavy lifting—like Spoolman validation, Obico/webcam, and the Slot Mapper—to the Bridge backend.

Keeping the intelligence in the Bridge makes the ecosystem future-proof and independent of slicer update cycles.
Just food for thought! Either way, focusing on making KX-Bridge stable and bug-free right now is definitely the right move.

Thanks for sharing your vision, @viewit! A specialized ecosystem sounds powerful. However, looking at it from a long-term maintenance perspective, managing a standalone Orca fork can become incredibly time-consuming, as it often struggles to keep up with the fast-paced upstream releases from official OrcaSlicer (as we can see with Orca-KX currently being on dev while official Orca is already in Beta). Personally, I see a huge potential in making **KX-Bridge the ultimate, powerful "Universal Hub"** instead. If the Bridge focuses on exposing standard APIs (similar to how Moonraker handles Klipper), it would allow users to always use the official, up-to-date OrcaSlicer (or any other standard slicer) while leaving all the heavy lifting—like Spoolman validation, Obico/webcam, and the Slot Mapper—to the Bridge backend. Keeping the intelligence in the Bridge makes the ecosystem future-proof and independent of slicer update cycles. Just food for thought! Either way, focusing on making KX-Bridge stable and bug-free right now is definitely the right move.

viewit commented

2026-06-23 14:04:23 +02:00

Hi @Alex_M,

Thank you for this — as always, extremely well-structured feedback. Let me go through each point and give you an honest assessment of where things stand.

1. Smart filament validation before "Upload and Print"

Feasible, and actually quite natural to implement given what the bridge already knows. The GCode metadata (filament types per slot) is already parsed on upload. The ACE slot state is live. A pre-print check that compares the two and intercepts if there is a mismatch would slot neatly into the existing maybeGateWebUpload flow. This is on the roadmap.

2. Unified Axes Control panel

Clean UX improvement, purely frontend. No objections — this is the kind of thing that makes daily use smoother. Will be picked up.

3. Language selector → Settings only

Agreed. The header toggle was a convenience shortcut from an earlier version; now that the Settings panel has a proper Appearance section, it is redundant in the header. Will move it.

4. Spoolman — what it does and where we stand

For anyone reading along: Spoolman is a self-hosted spool inventory manager. You register your filament spools (brand, material, diameter, weight), and other tools report consumption back to it so it tracks how much is left on each spool. Moonraker has native Spoolman support for Klipper printers.

PR #65 by @p2l already brings Spoolman integration to KX-Bridge. Here is how it works:

The Kobra X reports a supplies_usage field in every print/report MQTT message — a cumulative extrusion counter in mm, reset at the start of each print. This is accurate to within ~1% of the slicer estimate.
The bridge reports this length to Spoolman via PUT /api/v1/spool/{id}/use, and Spoolman converts mm → weight using the spool profile density.
Before each print, you can assign a Spoolman spool ID to each AMS slot in the print dialog. The assignment persists across prints.
For multi-colour prints, supplies_usage is a single aggregate counter. PR #65 currently splits it equally across all mapped spools. The proper fix — accumulating deltas against loaded_slot from multiColorBox/report at each poll tick (~3 s) while filtering out purges via feed_status — is already described as the follow-up path and is technically straightforward.

Pre-print weight validation (your point 4):
Also feasible. The GCode store already has filament_used_mm per file. Spoolman exposes remaining_weight per spool. A pre-print check that compares the two and warns in the Slot Mapper if a spool is running low would be a natural extension of the Spoolman integration — essentially the same gate as point 1 but with a weight/length threshold instead of a material mismatch.

PR #65 is currently under review and will be merged in a near-term release once tested.

5. Integrated slicing (Bambuddy / OrcaSlicer sidecar)

This is the most ambitious item and deserves an honest answer: it is technically possible but it is a large step beyond what KX-Bridge currently is.

OrcaSlicer can run in CLI mode (--slice), so in principle the bridge could accept a .3mf or .stl, invoke OrcaSlicer with a pre-configured profile, and send the resulting GCode to the printer. The challenges are:

OrcaSlicer is a 200 MB+ binary; shipping it as a sidecar changes the Docker image footprint significantly.
Profile management (printer, filament, process) would need to be exposed in the bridge UI.
Slicing is CPU-intensive and can take minutes on ARM hardware (Raspberry Pi, NAS).

This is worth tracking as a long-term direction, but it will not land in the near term. I have noted it.

Bottom line: points 1–4 are realistic near-term additions. Point 5 is a longer-term vision. Thank you for thinking this through so carefully — every one of these reports moves the project forward.

Hi @Alex_M, Thank you for this — as always, extremely well-structured feedback. Let me go through each point and give you an honest assessment of where things stand. --- **1. Smart filament validation before "Upload and Print"** Feasible, and actually quite natural to implement given what the bridge already knows. The GCode metadata (filament types per slot) is already parsed on upload. The ACE slot state is live. A pre-print check that compares the two and intercepts if there is a mismatch would slot neatly into the existing `maybeGateWebUpload` flow. This is on the roadmap. **2. Unified Axes Control panel** Clean UX improvement, purely frontend. No objections — this is the kind of thing that makes daily use smoother. Will be picked up. **3. Language selector → Settings only** Agreed. The header toggle was a convenience shortcut from an earlier version; now that the Settings panel has a proper Appearance section, it is redundant in the header. Will move it. --- **4. Spoolman — what it does and where we stand** For anyone reading along: [Spoolman](https://github.com/Donkie/Spoolman) is a self-hosted spool inventory manager. You register your filament spools (brand, material, diameter, weight), and other tools report consumption back to it so it tracks how much is left on each spool. Moonraker has native Spoolman support for Klipper printers. PR #65 by @p2l already brings Spoolman integration to KX-Bridge. Here is how it works: - The Kobra X reports a `supplies_usage` field in every `print/report` MQTT message — a cumulative extrusion counter in mm, reset at the start of each print. This is accurate to within ~1% of the slicer estimate. - The bridge reports this length to Spoolman via `PUT /api/v1/spool/{id}/use`, and Spoolman converts mm → weight using the spool profile density. - Before each print, you can assign a Spoolman spool ID to each AMS slot in the print dialog. The assignment persists across prints. - For multi-colour prints, `supplies_usage` is a single aggregate counter. PR #65 currently splits it equally across all mapped spools. The proper fix — accumulating deltas against `loaded_slot` from `multiColorBox/report` at each poll tick (~3 s) while filtering out purges via `feed_status` — is already described as the follow-up path and is technically straightforward. **Pre-print weight validation (your point 4):** Also feasible. The GCode store already has `filament_used_mm` per file. Spoolman exposes `remaining_weight` per spool. A pre-print check that compares the two and warns in the Slot Mapper if a spool is running low would be a natural extension of the Spoolman integration — essentially the same gate as point 1 but with a weight/length threshold instead of a material mismatch. PR #65 is currently under review and will be merged in a near-term release once tested. --- **5. Integrated slicing (Bambuddy / OrcaSlicer sidecar)** This is the most ambitious item and deserves an honest answer: it is technically possible but it is a large step beyond what KX-Bridge currently is. OrcaSlicer can run in CLI mode (`--slice`), so in principle the bridge could accept a `.3mf` or `.stl`, invoke OrcaSlicer with a pre-configured profile, and send the resulting GCode to the printer. The challenges are: - OrcaSlicer is a 200 MB+ binary; shipping it as a sidecar changes the Docker image footprint significantly. - Profile management (printer, filament, process) would need to be exposed in the bridge UI. - Slicing is CPU-intensive and can take minutes on ARM hardware (Raspberry Pi, NAS). This is worth tracking as a long-term direction, but it will not land in the near term. I have noted it. --- Bottom line: points 1–4 are realistic near-term additions. Point 5 is a longer-term vision. Thank you for thinking this through so carefully — every one of these reports moves the project forward.

Alex_M commented

2026-06-24 19:40:41 +02:00

Hi @viewit,

Thank you for such an incredibly thorough, transparent, and honest breakdown! It's amazing to see how well-aligned we are on points 1 to 4. Seeing that pre-print validation (both for material mismatch and Spoolman weight thresholds) is coming to the near-term roadmap is fantastic news for the whole community.

I completely agree with your assessment of Point 5 (Integrated Slicing). The technical overhead you mentioned—especially the Docker image footprint, profile management complexity, and CPU-intensive slicing on Raspberry Pi/ARM hardware-makes it totally understandable why this should remain a long-term, low-priority vision. Keeping the Bridge stable and lightweight is definitely the right choice.

Speaking of OrcaSlicer, thank you for pushing the new 2.5.0-dev-kx1 build so quickly!

While testing it, I noticed some rough edges with the filament/slot sync window that now pops up when syncing filaments. Right now, it doesn't seem to correctly align/match with the bridge slots.

Is this sync behavior currently a work-in-progress on your end, or would you like me to gather more details, logs, or screenshots to open a dedicated issue for it?

Thanks again for the amazing dedication to this project!

Hi @viewit, Thank you for such an incredibly thorough, transparent, and honest breakdown! It's amazing to see how well-aligned we are on points 1 to 4. Seeing that pre-print validation (both for material mismatch and Spoolman weight thresholds) is coming to the near-term roadmap is fantastic news for the whole community. I completely agree with your assessment of Point 5 (Integrated Slicing). The technical overhead you mentioned—especially the Docker image footprint, profile management complexity, and CPU-intensive slicing on Raspberry Pi/ARM hardware-makes it totally understandable why this should remain a long-term, low-priority vision. Keeping the Bridge stable and lightweight is definitely the right choice. Speaking of OrcaSlicer, thank you for pushing the new `2.5.0-dev-kx1` build so quickly! While testing it, I noticed some rough edges with the **filament/slot sync window** that now pops up when syncing filaments. Right now, it doesn't seem to correctly align/match with the bridge slots. Is this sync behavior currently a work-in-progress on your end, or would you like me to gather more details, logs, or screenshots to open a dedicated issue for it? Thanks again for the amazing dedication to this project!

Alex_M commented

2026-06-25 12:40:24 +02:00

In the meantime, I've done some deeper testing regarding the sync issue and mapped out exactly how to reproduce it. Here is what I discovered, which might help isolate the bug.

It appears that OrcaSlicer-KX's sync routine gets confused when handling physical empty slots (like Slot 1 in my setup) while trying to match them against an active project's filament list or an empty list, causing the array index to shift incorrectly.

Here is the step-by-step breakdown:

Scenario A: Model loaded on the build plate (Sync window appears)

Bridge Status: Slot 1 is Empty. Slots 2 to 6 are populated with various PLA/PETG profiles.

Orca Sync Window: When clicking sync, Orca tries to map the filaments, but the mapping shifts. For example, the first available ACE slot is being pushed downstream into the 4th slot of the printer.

Result in Orca: After syncing, "Creality PLA Ender" (which is physically in Slot 6 / ACE Slot 3) gets forced into Orca's Slot 1. This slot should probably map to the empty physical slot or keep the previous logical order, so this layout shift seems to mess everything up.

Bridge Sync Window Interception: This incorrect sequence is then reflected back into the Bridge slot mapper during the upload phase. Manually re-mapping Slot 6 to the first color inside this window allowed the print to succeed.

Scenario B: Empty plate (No model loaded)

If no object is loaded on the plate and I hit sync, the pop-up sync window does not appear, and the filaments in the sidebar sync correctly, safely skipping the first empty physical slot.

If I load a model after this clean sync, the layout remains correct.
However, if I delete all filaments in OrcaSlicer manually and hit sync again with the model on the plate, the mapping instantly breaks again, falling back to the broken state shown in Scenario A (image 3).

In the meantime, I've done some deeper testing regarding the sync issue and mapped out exactly how to reproduce it. Here is what I discovered, which might help isolate the bug. It appears that OrcaSlicer-KX's sync routine gets confused when handling physical empty slots (like Slot 1 in my setup) while trying to match them against an active project's filament list or an empty list, causing the array index to shift incorrectly. Here is the step-by-step breakdown: #### Scenario A: Model loaded on the build plate (Sync window appears) 1. **Bridge Status:** Slot 1 is Empty. Slots 2 to 6 are populated with various PLA/PETG profiles. ![image 1.png](/attachments/a1ab2c61-0508-4893-a56b-3f69787e4a6d) 2. **Orca Sync Window:** When clicking sync, Orca tries to map the filaments, but the mapping shifts. For example, the first available ACE slot is being pushed downstream into the 4th slot of the printer. ![image.png](/attachments/76aaf269-99dc-4b46-ace1-d81cd3f4044e) 3. **Result in Orca:** After syncing, "Creality PLA Ender" (which is physically in Slot 6 / ACE Slot 3) gets forced into Orca's Slot 1. This slot should probably map to the empty physical slot or keep the previous logical order, so this layout shift seems to mess everything up. ![image.png](/attachments/46a0d27a-dc5e-4fdf-82ef-fa04de860509) 4. **Bridge Sync Window Interception:** This incorrect sequence is then reflected back into the Bridge slot mapper during the upload phase. Manually re-mapping Slot 6 to the first color inside this window allowed the print to succeed. ![image.png](/attachments/3000a88d-6f26-47d9-b9df-916a734b6595) #### Scenario B: Empty plate (No model loaded) * If **no object** is loaded on the plate and I hit sync, the pop-up sync window does not appear, and the filaments in the sidebar sync **correctly**, safely skipping the first empty physical slot. ![image.png](/attachments/be19adc9-33fb-4a99-b111-372fed09c754) * If I load a model *after* this clean sync, the layout remains correct. * However, if I **delete all filaments** in OrcaSlicer manually and hit sync again with the model on the plate, the mapping instantly breaks again, falling back to the broken state shown in Scenario A (image 3).

image.png

34 KiB

image.png

110 KiB

image.png

27 KiB

image.png

56 KiB

image.png

16 KiB

Alex_M commented

2026-06-25 12:42:01 +02:00

Additional Bug: "Overwriting" Mode Hard Crash

While trying to troubleshoot the issue using the Sync Window (as shown in image_30213d.png), I tried switching the top toggle from Mapping to Overwriting to see if forced synchronization would bypass the array shift.

As soon as I hit sync using the Overwriting option, OrcaSlicer-KX instantly crashed with the following unhandled standard exception:

{020E23C5-109E-40C1-B38F-1AEB86B436B2}.png

This crash heavily points towards a core configuration mismatch or missing default vector values when Orca tries to dynamically rebuild/resize its filament list based on the Bridge's custom Moonraker multi-pass response data.

Hopefully, these reproduction steps and the exception log help you trace the mapping logic issue! Let me know if you still need any specific debug logs.

Additional Bug: "Overwriting" Mode Hard Crash While trying to troubleshoot the issue using the Sync Window (as shown in image_30213d.png), I tried switching the top toggle from **Mapping** to **Overwriting** to see if forced synchronization would bypass the array shift. As soon as I hit sync using the **Overwriting** option, OrcaSlicer-KX instantly crashed with the following unhandled standard exception: <img width="298" alt="{020E23C5-109E-40C1-B38F-1AEB86B436B2}.png" src="attachments/32a23dd5-9bd5-4412-8137-e9df8e7f5018"> This crash heavily points towards a core configuration mismatch or missing default vector values when Orca tries to dynamically rebuild/resize its filament list based on the Bridge's custom Moonraker multi-pass response data. Hopefully, these reproduction steps and the exception log help you trace the mapping logic issue! Let me know if you still need any specific debug logs.

{020E23C5-109E-40C1-B38F-1AEB86B436B2}.png

8.1 KiB

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#67