Real-world slicer exports fail on inheritance resolution and sentinel values

[maziggy]

Hi — first of all, thanks for this project. Nice clean wrapper and the containerization is a great touch.

I wanted to flag two distinct failure modes I hit when testing against real-world exports from the OrcaSlicer and BambuStudio GUIs, with
orca-slicer-api built from current main, OrcaSlicer 2.3.1 AppImage, on Linux x86_64. Both the upstream test fixtures in tests/files/input/ slice cleanly, so the setup is otherwise healthy.

## 1. Delta profiles with inherits: fail to parse

When I pass profiles that users exported from their slicer GUI ("Export preset to file"), the API returns:

500 — Slicing failed with error from slicer: The input preset file is invalid and can not be parsed.

Diffing the failing profiles against tests/files/input/{printer,process,filament}.json:

	tests/files/input	User export
Top-level keys	79 / 116 / 69	12 / 11 / 9
inherits: target	fdm_bbl_3dp_001_common (low-level internal template)	Bambu Lab X1 Carbon 0.4 nozzle (user-visible system preset)
filament	no inherits at all (fully flattened)	delta on Bambu PLA Basic @BBL X1C

It looks like the OrcaSlicer CLI can resolve inherits: against its bundled low-level fdm_* templates in resources/profiles/BBL.json, but
not against user-visible system presets living in resources/profiles/BBL/{machine,process,filament}/. The GUI resolves both. Your reference fixtures sidestep this by either inheriting from the low-level base or being fully flattened, which is why e2e passes but real exports don't.

Would you be open to having the API walk the inherits: chain against the AppImage's bundled profiles (they're right there in /app/squashfs-root/resources/profiles/BBL/) and hand a flattened JSON to the CLI? That would make the "upload your exported profile, slice a cube"
workflow actually work end-to-end for typical users. Happy to contribute a PR if that's a direction you'd accept.

## 2. 3MF slicing fails on sentinel -1 values

When I instead pass a 3MF file exported from the slicer GUI (with profile embedded, no explicit profile params on the request), the API returns:

500 — Slicing failed with error from slicer: Invalid parameter value(s) included in the 3mf file.

This happens with 3MFs exported from both OrcaSlicer and BambuStudio. The upstream tests/files/input/Cube.3mf slices fine in the same container.

Unzipping a failing 3MF and inspecting Metadata/project_settings.config (609 fields total, printer = Bambu Lab H2D, 13-slot filament config) surfaces these suspects:

prime_tower_brim_width = '-1'
filament_tower_interface_print_temp = ['-1', ..., '-1'] # 13 slots
internal_bridge_fan_speed = ['-1', ..., '-1']
ironing_fan_speed = ['-1', ..., '-1']
support_material_interface_fan_speed = ['-1', ..., '-1']

These are "-1 = auto / unset" sentinels. The GUI accepts them and interprets them at slice time; the CLI's strict validator rejects the
whole file.

This may be out of scope for the wrapper and actually a bug (or under-documented contract) on the OrcaSlicer CLI side. But it's worth
documenting in the README or flagging as a known limitation so others hitting this same wall can find it. A --sanitize-3mf option in the API
that strips/replaces known sentinel fields before invoking the CLI would be hugely valuable, even if it's best-effort.

## Reproduction

Both failures are reproducible in minutes against upstream main:

# 1. Boot the container
docker build --build-arg ORCASLICER_VERSION=2.3.0 --build-arg TARGETARCH=amd64 -t orca-slicer-api .
docker run -d -p 3000:3000 --name orca-slicer-api orca-slicer-api

# 2. Export any printer/process/filament preset from OrcaSlicer GUI as JSON
#    (you'll get delta files with inherits: pointing at user-visible presets)

# 3. Try to slice a cube with them — reproduces failure mode #1
curl -X POST http://localhost:3000/slice \
  -F "file=@cube.stl;type=model/stl" \
  -F "printerProfile=@exported-printer.json;type=application/json" \
  -F "presetProfile=@exported-process.json;type=application/json" \
  -F "filamentProfile=@exported-filament.json;type=application/json" \
  -F "exportType=3mf"

# 4. Export a 3MF from OrcaSlicer GUI (File → Save as 3MF) and slice it
#    with no profile params — reproduces failure mode #2
curl -X POST http://localhost:3000/slice \
  -F "file=@real-export.3mf;type=model/3mf" \
  -F "exportType=3mf"

Environment

- orca-slicer-api: main built from source
- OrcaSlicer: 2.3.1 AppImage (the one your Dockerfile downloads)
- Docker: recent, Linux x86_64, Debian host
- Slicer exports: OrcaSlicer 2.3.x and BambuStudio recent release

Let me know if either of these is something you'd like a PR on, or if they're already being tracked in #12 / #16. Thanks again for the project.

[AFKFelix]

Hey, thanks for testing and creating the issue.

Regarding the first point: I am well aware of the situation with the profiles. From my testing, inheritance does not really work at all in the CLI if I remember correctly, which is a bit annoying, especially for real use. Originally this project was planned as a simple wrapper around the CLI, with the responsibility for the profiles on the upstream service so that the API receives full and valid profiles.
Anyway, I totally agree with you that the system profiles should be resolved. I have already looked into making the bundled profiles selectable/usable on the slice endpoint with an automatic resolver, and I like the idea of doing the same for user uploaded profiles. This would make the API much more user-friendly.

Regarding the second issue, I encountered the same problem with a few 3MF files, but I never investigated it in depth since it worked for most of my files. I really appreciate that you looked into it. I agree that it should be documented, but I'm not sure if it needs to be fixed in this project. From what I have experienced so far, the CLI sometimes behaves very differently to the GUI so at some point I feel it is building more than just a simple lightweight wrapper. I am not sure if that is what I want for this project, given that there are also other things, such as STEP import with the newer versions not working anymore, that then should be handled. It would for sure make it more user friendly, but it would also exceed the original project scope. What do you think? Do you think this project should handle all the special behaviors of the CLI?

If you would like to contribute, please feel free to do so. You can check the profile issue as example (#12)

Thanks again for testing and offering to contribute.

[maziggy]

Thanks for the response — appreciate you engaging on the scope question instead of just closing it out.

Quick context: we're Bambuddy, an open-source Bambu Lab printer manager. Slicing matters to us specifically for users running their printers in LAN-only mode, where the official cloud workflow is awkward. We did our own direct-CLI spike back in February and hit the same walls you're describing, so your wrapper is the natural integration path.

I've forked at maziggy/orca-slicer-api so we can iterate without blocking on upstream cadence. Hoping to upstream most of it, but want to be self-sufficient on the parts you'd rather not maintain.

On profile resolution (your first point, issue #12):

We have a working Python flattener from our earlier spike that resolves the inherits: chain against the bundled resources/profiles/BBL/ JSONs (machine, process, filament). It handles the "user pasted a delta profile referencing 'Bambu Lab X1 Carbon 0.4 nozzle'" case — walks the chain, merges child-over-parent, emits a CLI-loadable flat profile.

Happy to port to TypeScript and submit as a PR against #12. If you've already started on this, let me know and I'll either contribute on top or hold off.

On 3MF sentinel values (your second point):

Hear the scope concern. The pattern we hit: Metadata/project_settings.config from real GUI exports contains -1 ("auto") and empty-string values across ~600 fields, which the CLI rejects. Strictly speaking that's a CLI bug — but it'll keep happening for every user input until BambuStudio/OrcaSlicer ship a CLI-safe export mode (#4675 upstream, no movement).

Two ways this can land, your call:

1. Upstream as opt-in — a PR that adds a sanitize3mf=true request parameter (default off, your project stays a thin wrapper by default; users who need leniency turn it on). I'd commit to maintaining the sanitizer per slicer version with fixture-based regression tests.
2. Downstream only — we keep the sanitizer in Bambuddy's preprocessing layer, your project stays untouched. We'd document the approach clearly so other downstream consumers can copy it.

Either works for us — I just don't want to PR something you'd rather not maintain. Let me know which you prefer.

Regardless of where the sanitizer lands, the profile resolver PR is coming. Will tag #12 when it's ready for review.

Thanks again — the wrapper-around-CLI shape is exactly what we wanted to find.

[AFKFelix]

Hey, thanks for your response.
I have already checked Bambuddy and I have to say I think it is really cool. I am actually planning to try it out myself when I get some time, because I run my Bambu printer in LAN mode. To be honest, I would love to see the possibility to slice a model and send it to the printer, especially from the phone, similar to the Bambu Handy app at some day.

Regarding the profile resolution, I looked into it at the weekend and made some drafts, but nothing is final or fully functional yet. I am looking forward to seeing your implementation of the profile resolver and thank you in advance for taking the time to do it.

Regarding the 3MF topic, I want to investigate further before making a final decision. From my testing so far, it seems like it is only happening on some Bambu machines sometimes. I could only reproduce the error you mentioned with the H2D, but with other Bambus, depending on the slicer version in the API and the version exported from the slicer, I sometimes get the following error: There are some incorrect slicing parameters in the 3mf. Please verify the slicing of all plates in Orca Slicer before uploading. The same 3MF file works when a different printer (like P1S, i3 Mega S or Neptune 3 Pro) is selected. I am not sure if this is the same issue, as I didn't check the files yet.
Anyway, since the profile resolution is also being implemented here now, I think fully working 3MF support should also exist, to offer a complete working package. Also I have no problem maintaining it, since it may be useful to me in the future too.

I am very happy to hear that you like the wrapper :)

[maziggy]

Glad you're up for both — that simplifies things on our end.

Quick alignment on what we already have running, since we're a couple sessions deeper than the comment thread suggests:

Profile resolution: we ended up putting the resolver in the sidecar rather than the client. The Bambuddy backend just emits a stub {name, inherits: <system_preset_name>, from: "system", type} per slot, and the sidecar walks BUNDLED_PROFILES_PATH//.jsonand merges. That's on abambuddy/profile-resolver` branch on our fork (maziggy/orca-slicer-api). Effectively the same shape as #12 — happy to either send it as a PR or, if your draft is taking a different shape, walk through it on #12 first so we don't end up rebasing twice. I'll drop a more detailed note on #12 today.

3MF "sanitizer" is actually a misnomer for what we ship — we don't try to repair the sentinel values. We strip four metadata entries from the 3MF zip before forwarding (project_settings.config, model_settings.config, slice_info.config, cut_information.xml) and let the supplied profile triplet drive the slice via --load-settings. Geometry, thumbnails, color, and multi-part data stay intact. Simpler than value-replacement and we haven't seen a case it doesn't fix; might be worth keeping in mind before you commit to a value-substitution approach.

On the two error classes you saw: "Invalid parameter value(s) included in the 3mf file" is reproducible on H2D for us too — sentinel-value range checks against the embedded project_settings.config. The "There are some incorrect slicing parameters" variant we haven't seen yet but it sounds like the same root cause hit by a different validator. Happy to package up a fixture set (H2D + a P1S/X1C export + the strip-and-slice expected-pass equivalents) so you have ground truth — useful?

Re Bambuddy in LAN mode: yes, give it a shot. Slice-and-print from mobile is on the roadmap and the sidecar is the piece we needed — much appreciated. If anything bites during setup, ping me directly.

[AFKFelix]

Hey, thanks for working on the profile. I will check the comment on #12 as soon as I can. From what I have seen in the Bambuddy resolver, it is close to what I had in mind too.

Regarding the 3MF, it would be much appreciated if you could provide a fixture to test it, so that I have a solid base for testing. As I said I will also check it in more detail and if I find anything new, I will let you know.

Re Bambuddy, I have just a quick question: is there a way to install it in Home Assistant as an add-on or app?

[maziggy]

1. 3MF fixture set — yes, will package and send.

Quick context on what we actually ship downstream so the fixtures match what's useful: we don't sanitize or strip from the 3MF. We forward the source file verbatim and let our supplied profile triplet override the offending fields via --load-settings — Metadata/{project_settings,model_settings,slice_info}.config and Metadata/cut_information.xml all stay in the zip. We tried stripping them in an earlier iteration and the CLI silently exited right after Initializing StaticPrintConfigs, so we reverted; an integration test asserts they're still present in what we POST. So our "fix" is shaped differently from your value-substitution sanitizer — useful as a known data point either way.

That means the fixture set is just the failing inputs, since our pass path is "supply a profile triplet" rather than "transform the 3MF":

• fail/h2d-orcaslicer.3mf — H2D export from OrcaSlicer GUI; reproduces "Invalid parameter value(s) included in the 3mf file" (the sentinel -1 path).
• fail/h2d-bambustudio.3mf — same printer, BambuStudio GUI export; both slicers hit the same validator.
• fail/p1s-orcaslicer.3mf (or X1C) — to probe whether the "There are some incorrect slicing parameters" variant you described is reproducible from the export side, since we haven't seen that path ourselves.
• README.md — what each fixture exercises, the exact error string the CLI returns, and a one-liner curl snippet that POSTs each to /slice so the set doubles as a smoke test for Improve profile management #12 work going forward.

Aiming for end of this week.

2. Home Assistant add-on — yes, currently being built by another community member.

It's not something I maintain directly, but there's an HA add-on in the works that you'd add to HA's Add-on Store (Settings → Add-ons → ... → Repositories). Once it's mature enough I'll likely link it from the Bambuddy README; in the meantime it's reachable if you search the HA addon community.

Heads-up on something we just shipped this week (0.2.4b2, in dev now): Bambuddy now detects when it's running under HA Supervisor (via the SUPERVISOR_TOKEN env var) and defers the update UI to HA — the in-app "Update available" banner is suppressed when running as an addon (Supervisor surfaces its own update notification natively, so the in-app one would just be duplicate noise), and Settings → Updates renders "Updates are managed by the Home Assistant Supervisor" with a pointer to the right HA UI path. Came out of issue #1167. So once your container picks up the 0.2.4b2 release the addon experience should feel more native.

If you hit anything during setup ping me directly. Slice-and-print from a phone is the same shape we want for our LAN users — interested to hear how it feels for you in practice once you've poked at it.

BTW: Please ping me by the end of the week if I didn't provide the 3mf fixture set. My task lists is packed :)

[AFKFelix]

1. Okay, got it. Thank you again and please no stress take your time.

2. I installed the add-on and it's really nice, to be honest. So far, I have only added my printer and taken a quick look at it, but it has so many great features. I can't believe I didn't try it out earlier! Thanks a lot for this project! I love the Maker World import btw. I had been wondering for a long time if this would be possible and there it is. I think it would be so awesome combined with the slicing.