Moonraker compatibility #25

New Issue

slm4996 · 2026-05-18T23:09:06+02:00

slm4996 commented

2026-05-18 23:09:06 +02:00

I set this up, its amazing! I do wish you had a published docker image though.

Once setup I tested several moonraker interfaces and integrations.

Mainsail fails to load the printer after adding.
Fluidd seems to work fine.
Mobileraker complains about a gcode issue (will try to get screenshots).

My goal here is unified monitoring / remote monitoring across my printer ecosystem and mobile alerting / status checking while out and about.

I realize this is not the original goal of the projector, but it would fill a massive hole in my "single pane of glass" system i have now.

Also, and I can open another issue for this if needed, my Kobra X with 3 filaments going into the print head and a Ace 2 Pro with 4 colors, only shows the Ace 2 pro filaments in the web UI. The 3 native / print head filaments dont seem to show up in the web UI or orcas anywhere.

I set this up, its amazing! I do wish you had a published docker image though. Once setup I tested several moonraker interfaces and integrations. Mainsail fails to load the printer after adding. Fluidd seems to work fine. Mobileraker complains about a gcode issue (will try to get screenshots). My goal here is unified monitoring / remote monitoring across my printer ecosystem and mobile alerting / status checking while out and about. I realize this is not the original goal of the projector, but it would fill a massive hole in my "single pane of glass" system i have now. Also, and I can open another issue for this if needed, my Kobra X with 3 filaments going into the print head and a Ace 2 Pro with 4 colors, only shows the Ace 2 pro filaments in the web UI. The 3 native / print head filaments dont seem to show up in the web UI or orcas anywhere.

gangoke commented

2026-05-19 02:46:08 +02:00

ACE2 support being worked.
See #23

ACE2 support being worked. See #23

slm4996 commented

2026-05-19 05:07:59 +02:00

ACE2 support being worked.
See #23

Good news!

FYI, the Ace 2 pro slots / colors are reported correctly today. The built-in 3 other (4 minus the slot occupied by the ACE 2 pro) are not reported at all.

> ACE2 support being worked. > See #23 Good news! FYI, the Ace 2 pro slots / colors are reported correctly today. The built-in 3 other (4 minus the slot occupied by the ACE 2 pro) are not reported at all.

roketscyntist commented

2026-05-19 10:50:06 +02:00

Great software - I have done about 10 prints using the bridge with Orca and no real issues. I can confirm that Mobileraker complains about some gcode issue. Not a big deal for me, but here is the error:

Exception:
 MobilerakerException{Missing field: gCodeMove, parentException: null, parentStack: null}

#0      PrinterBuilder.build (package:common/data/dto/machine/printer_builder.dart:163)
#1      PrinterService.refreshPrinter (package:common/service/moonraker/printer_service.dart:223)
<asynchronous suspension>

Great software - I have done about 10 prints using the bridge with Orca and no real issues. I can confirm that Mobileraker complains about some gcode issue. Not a big deal for me, but here is the error: ``` Exception: MobilerakerException{Missing field: gCodeMove, parentException: null, parentStack: null} #0 PrinterBuilder.build (package:common/data/dto/machine/printer_builder.dart:163) #1 PrinterService.refreshPrinter (package:common/service/moonraker/printer_service.dart:223) <asynchronous suspension> ```

viewit commented

2026-05-20 13:08:33 +02:00

Quick progress update on the Moonraker-interface compatibility (Mainsail / Fluidd / Mobileraker). 👇

I dug into why Mainsail and Mobileraker were failing to load and fixed the protocol gaps on the bridge side:

gcode_move + configfile objects — Mobileraker hard-requires these (the Missing field: gCodeMove crash @roketscyntist posted) and Mainsail's init expects them too. They're now part of the emulated printer.objects.
Moonraker database + a few server.* RPCs — Mainsail stores its own UI state in the Moonraker DB and calls server.database.*, server.gcode_store, server.history.* etc. on startup. These now return correctly-shaped responses (backed by a small in-memory store), so the dashboard loads through.
Basic control via printer.gcode.script — Mainsail/Fluidd drive the printer with raw Klipper G-code, but the Kobra X doesn't speak Klipper — it speaks its own protocol. So I added a thin translation wrapper for the most common commands: homing (G28), hotend/bed temps (M104/M109/M140/M190), fan (M106/M107), speed factor (M220), relative jog moves (G1 under G91), and motors-off (M84).

A couple of honest caveats so nobody is surprised:

This is a wrapper around the most-used G-codes, not a full Klipper emulation. Anything outside that set (macros, arbitrary SET_* commands, absolute G1 positioning, etc.) is safely ignored rather than executed. The goal here matches your original ask — monitoring and basic remote control / mobile alerting across a single pane of glass — not turning the Kobra X into a full Klipper host.
It's an additive compatibility layer. It doesn't change how the bridge talks to the printer or how OrcaSlicer uses it; it just makes the existing MQTT controls reachable through the Moonraker interfaces those apps speak.

Tested locally against Mainsail (dashboard loads, temps/homing/jog reach the printer). Mobileraker's missing-field crash should be resolved by the gcode_move/configfile additions — if you get a chance to retest with a screenshot, that'd be a great confirmation.

This will ship in the next release. Thanks for the detailed report and the stacktrace — that's exactly what made these fixes pinpointable. 🙏

(Separately: the "native toolhead filaments not showing alongside the ACE 2 Pro" point is a different issue in the ACE2 slot aggregation — tracking that on its own, since it needs the multi-box hybrid path that wasn't testable without exactly your hardware combo.)

Quick progress update on the Moonraker-interface compatibility (Mainsail / Fluidd / Mobileraker). 👇 I dug into why Mainsail and Mobileraker were failing to load and fixed the protocol gaps on the bridge side: - **`gcode_move` + `configfile` objects** — Mobileraker hard-requires these (the `Missing field: gCodeMove` crash @roketscyntist posted) and Mainsail's init expects them too. They're now part of the emulated `printer.objects`. - **Moonraker database + a few `server.*` RPCs** — Mainsail stores its own UI state in the Moonraker DB and calls `server.database.*`, `server.gcode_store`, `server.history.*` etc. on startup. These now return correctly-shaped responses (backed by a small in-memory store), so the dashboard loads through. - **Basic control via `printer.gcode.script`** — Mainsail/Fluidd drive the printer with raw Klipper G-code, but the Kobra X doesn't speak Klipper — it speaks its own protocol. So I added a **thin translation wrapper** for the most common commands: homing (`G28`), hotend/bed temps (`M104/M109/M140/M190`), fan (`M106/M107`), speed factor (`M220`), relative jog moves (`G1` under `G91`), and motors-off (`M84`). A couple of honest caveats so nobody is surprised: - This is **a wrapper around the most-used G-codes, not a full Klipper emulation.** Anything outside that set (macros, arbitrary `SET_*` commands, absolute `G1` positioning, etc.) is safely ignored rather than executed. The goal here matches your original ask — **monitoring and basic remote control / mobile alerting** across a single pane of glass — not turning the Kobra X into a full Klipper host. - It's an **additive compatibility layer.** It doesn't change how the bridge talks to the printer or how OrcaSlicer uses it; it just makes the existing MQTT controls reachable through the Moonraker interfaces those apps speak. Tested locally against Mainsail (dashboard loads, temps/homing/jog reach the printer). Mobileraker's missing-field crash should be resolved by the `gcode_move`/`configfile` additions — if you get a chance to retest with a screenshot, that'd be a great confirmation. This will ship in the next release. Thanks for the detailed report and the stacktrace — that's exactly what made these fixes pinpointable. 🙏 (Separately: the "native toolhead filaments not showing alongside the ACE 2 Pro" point is a different issue in the ACE2 slot aggregation — tracking that on its own, since it needs the multi-box hybrid path that wasn't testable without exactly your hardware combo.)

viewit commented

2026-05-20 14:07:55 +02:00

Update on the Moonraker-interface support (Mainsail / Fluidd / Mobileraker).

After building it out and testing it end-to-end, I've decided not to ship official support for third-party Moonraker UIs — and I've reverted the work. Here's the honest reasoning:

The bridge already ships its own web UI (Fluidd-inspired) that talks the printer's native protocol directly. It supports more, more reliably, than a Klipper emulation can: AMS/ACE Pro 2, per-object skip (exclude object), multi-printer, live camera, filament mapping. Re-implementing all of that a second time through a Klipper/Moonraker shim means two code paths to maintain and a worse result.
Mobileraker actually froze the host during testing — it hammered an unknown RPC (server.files.metadata) in a tight loop (~326k calls), saturating the bridge. Chasing every quirk of every third-party client to avoid that is a maintenance sink with little payoff.
A Klipper emulation will always be a leaky abstraction here: these clients send raw Klipper G-code / macros, but the Kobra X doesn't speak Klipper. Mapping a subset works for basic cases and breaks in surprising ones (exactly what you and the others hit).

So the recommendation for your "single pane of glass": use the bridge's own UI at http://<bridge-ip>:7125. If there's real demand for mobile monitoring/alerting later, I'd rather build that as a first-class, properly-tested feature than rely on emulating clients we can't control.

One good thing came out of this and stays in: a fix so the bridge correctly reports paused/printing state (it was reading the device-level state instead of the nested print-job state). That improves the bridge's own UI and ships in the next release.

Thanks for the detailed report and the testing — genuinely useful, even though the conclusion is "different direction." 🙏

Closing this as wontfix for the third-party-UI part. The ACE2 native-vs-hub slot display you mentioned is a separate, valid issue and I'm tracking that independently.

Update on the Moonraker-interface support (Mainsail / Fluidd / Mobileraker). After building it out and testing it end-to-end, I've decided **not to ship official support for third-party Moonraker UIs** — and I've reverted the work. Here's the honest reasoning: - **The bridge already ships its own web UI** (Fluidd-inspired) that talks the printer's native protocol directly. It supports more, more reliably, than a Klipper emulation can: AMS/ACE Pro 2, per-object skip (exclude object), multi-printer, live camera, filament mapping. Re-implementing all of that a second time through a Klipper/Moonraker shim means two code paths to maintain and a worse result. - **Mobileraker actually froze the host** during testing — it hammered an unknown RPC (`server.files.metadata`) in a tight loop (~326k calls), saturating the bridge. Chasing every quirk of every third-party client to avoid that is a maintenance sink with little payoff. - A Klipper emulation will always be a leaky abstraction here: these clients send raw Klipper G-code / macros, but the Kobra X doesn't speak Klipper. Mapping a subset works for basic cases and breaks in surprising ones (exactly what you and the others hit). So the recommendation for your "single pane of glass": use the bridge's own UI at `http://<bridge-ip>:7125`. If there's real demand for mobile monitoring/alerting later, I'd rather build that as a first-class, properly-tested feature than rely on emulating clients we can't control. One good thing came out of this and **stays in**: a fix so the bridge correctly reports paused/printing state (it was reading the device-level state instead of the nested print-job state). That improves the bridge's own UI and ships in the next release. Thanks for the detailed report and the testing — genuinely useful, even though the conclusion is "different direction." 🙏 Closing this as wontfix for the third-party-UI part. The ACE2 native-vs-hub slot display you mentioned is a separate, valid issue and I'm tracking that independently.

viewit closed this issue

2026-05-20 14:07:55 +02:00

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#25