Skip to content

Profiles

Status: PROPOSED

Profile chips, the picker, persistence, and printer push are planned in docs/ui/ui-plan.md:173–180,266–273,284–286. Current analysis/profile and metadata facts are marked HOW IT IS with code citations.

Prepare shows three compact selectors: Printer, Filament, and Process. Each opens the same searchable picker on the relevant tab.

At a glance

Profile Planned responsibility What is real today
Printer Machine identity, geometry, and non-planar clearance defaults No printer-profile setter or UI. Inferred-printer ABI output exists.
Filament Material identity and temperatures used by analysis Analyze already packs a real NpsMaterialProfile, but both apps currently pass hard-coded PLA 210/60.
Process Named projection onto the four demo-process inputs and planned non-planar fields The four demo-process inputs work; named presets and delta tracking do not.

Profile chips

PROPOSED — each chip shows the current selection and state:

Chip state Display
Stored selection Profile name, for example X1 Carbon or PLA Basic
Parsed inference Value plus (inferred)
Edited after apply Delta dot on the chip
Required data missing Not selected and an explanation on open
Simulator-mode Prepare Read-only/reduced presentation where editing belongs in Slicer mode

Clicking a chip opens the picker; applying a profile updates visible fields but does not silently generate. If a generated path exists, a relevant change makes it dirty.

Searchable picker

PROPOSED — one dialog has three tabs:

Tab Search keys Apply result Custom editing
Printer vendor, model, build volume Select preset; fill clearance defaults Machine identity and supported geometry fields
Filament vendor, material, profile name Select material and analysis temperatures Material fields supported by NpsMaterialProfile
Process name, layer height, purpose Project preset values into Process and non-planar controls Save the current visible values as a host preset

The dialog is searchable and keyboard accessible. Esc closes it without applying. Apply is explicit; selecting a row for inspection is not enough.

Filament profile: real analysis path

HOW IT ISEngineSession.Analyze(MaterialProfileOptions) constructs and marshals NpsMaterialProfile, then calls AnalyzeGcode (src/Nps.EngineHost/EngineSession.cs:416–452). The current host fills material type, melt temperature, and glass transition; the other struct fields remain at their defaults (src/Nps.EngineHost/EngineSession.cs:421–430).

HOW IT IS — both apps currently analyze with the literal MaterialProfileOptions("PLA", 210, 60) (src/SlicerApp/MainWindow.axaml.cs:502; src/SimulatorApp/MainWindow.axaml.cs:408,578). There is no current filament picker.

PROPOSED — applying a Filament profile replaces those hard-coded options with the selected profile. A parsed (inferred) value is a suggestion/display source; it does not overwrite an explicit user selection without an Apply action.

Inferred metadata

The engine already exposes three string outputs:

Metadata Existing export Planned consumer
Material GetInferredMaterialType (src/Nps.EngineHost/NpsAbi.cs:276–277) Filament chip and metadata block
Source slicer GetInferredSlicerType (src/Nps.EngineHost/NpsAbi.cs:279–280) Read-only metadata block above Findings
Printer GetInferredPrinter (src/Nps.EngineHost/NpsAbi.cs:282–285) Printer chip and metadata block

HOW IT IS — these ABI exports exist and the printer output is documented as coming from parsed slicer header data (src/Nps.EngineHost/NpsAbi.cs:282–285). They have no production UI consumer today.

PROPOSED — after external G-code is parsed, an inferred metadata block shows:

Material: PETG (inferred) · Slicer: OrcaSlicer · Printer: X1 Carbon (inferred)

Unknown/empty values display Unknown; the UI does not claim a profile match when the engine returned none. Clicking an inferred Printer or Filament value opens the picker with matching candidates, but still requires Apply.

Printer profile honesty

PROPOSED — Printer profiles live in a host JSON store at first. They drive UI defaults such as nozzle/gantry clearance and appear in the chip/picker.

The planned additive engine hook is:

SetPrinterProfile(NpsPrinterProfile)

Until that export exists and is called, the selected printer is host-only. The UI must not imply that the engine used build volume, kinematics, nozzle geometry, or printer limits merely because a chip is selected.

Process profiles

PROPOSED — a Process profile is a named projection, not a hidden engine object. Applying one fills:

  • the four current demo parameters: layer height, feedrate, volumetric flow scale, and layer count;
  • planned non-planar angle, amplitude, thickness, clearance, detection, and seam fields when the profile defines them.

HOW IT IS — the four current values already flow through SliceParams into GcodeGenOptions (src/SlicerApp/SliceParams.cs:88–96) and are packed for GenerateGcode (src/Nps.EngineHost/EngineSession.cs:341–364). Named presets, non-planar projections, and persistence are PROPOSED.

Apply and delta tracking

flowchart LR
  P["Open profile picker"] --> A["Apply profile"]
  A --> F["Populate visible fields"]
  F --> E["Edit one field"]
  E --> D["Delta dot + field badge"]
  D --> S["Slice / Re-slice"]

PROPOSED rules:

  1. Apply writes visible controls and records the applied baseline.
  2. A field that differs from the baseline gets a delta badge.
  3. The owning chip gets a delta dot.
  4. Reverting to the profile value clears that field’s delta.
  5. Applying another profile replaces the baseline.
  6. Delta state describes settings, not whether generation succeeded.
  7. Any relevant post-generation edit also activates the dirty banner.

Storage and portability

PROPOSED — the first profile catalog is a host JSON store. That means:

  • it is not engine canonical state;
  • printer and process profiles can exist before new ABI exports;
  • persistence failures are reported, not silently ignored;
  • importing/exporting profile JSON is a separate user action, not G-code Export;
  • the docs continue to label host-only selections honestly.

No cloud sync or cross-machine catalog is promised by this prototype.

See also