# Description
<!--
> Please provide a summary of the changes made in this PR. Include
details such as:
> * What issue does this PR address or fix?
> * What new features or enhancements does this PR introduce?
> * Are there any breaking changes or dependencies that need to be
considered?
-->
Changing the IP address input dialog and `connect_printer` API in
preparation for configurable Moonraker/Orca printer agent connections.
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
<img width="460" height="699" alt="image"
src="https://github.com/user-attachments/assets/35e3ce17-7594-4401-b140-100dea082221"
/>
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
<!--
> A guide for users on how to download the artifacts from this PR.
-->
[How to Download Pull Requests Artifacts for
Testing](https://www.orcaslicer.com/wiki/how_to_download_pr_artifacts)
The Polymaker, BETA, COEX, Overture, addnorth, Numakers, FusRock and
AliZ presets that BambuStudio does not ship now live under
OrcaFilamentLibrary/filament/<Brand>/BBL. The BBL bundle now holds
only the filament presets BambuStudio ships, plus a few Bambu and
generic ones.
New "<product> @BBL base" presets carry the values these presets used
to get from BBL's own bases, so their settings on Bambu Lab printers
are unchanged.
The nightly found its build with a filtered run listing (branch=main,
status=success) and trusted the first result. GitHub serves filtered
listings from a run search index that has intermittently returned
weeks-old results, so some nights tested a build from weeks earlier and
reported its differences as regressions. The same filter also matched
fork PR builds whose branch is named main.
The build is now picked from the unfiltered listing, which stays
current, and filtered here: a successful build_all run of this
repository on the requested branch. Fork PR builds are excluded by
repository. A feature branch is normally built only for its PR, so this
repository's own PR builds stay eligible, but a PR build compiles the PR
merged into its base rather than the head commit the later jobs check
out, so a push or dispatch build of the branch is preferred when the same
page of the listing has one. A scheduled run fails instead of testing a
build more than 48 hours old, and every run names the build it tested
in the job summary.
Manual runs scan further back, so a branch that last built weeks ago
can still be tested, and a new build_run_id input pins one build_all
run, read directly rather than through a search.
# Description
This PR introduces lifecycle events to the plugin API.
For all plugin capabilities, you can define a `on_lifecycle_event`
function in the plugin that takes in a event enum and a small payload
for some generic information on the lifecycle event.
The idea is to keep the payload generic and small, and if you want to
get more information, you should invoke other more targeted APIs to get
more information.
For example, lets say you are keeping track of the the `ObjectAdded*`
event hook for model transformation, addition or deletion. The payload
would tell you the name of the model, and you should use a targeted API
such as `orca.host.plater().model()` to get more information on the
model. This is the overall design principle of the API.
Currently the lifecycle events are the following:
```cpp
enum class LifecycleEvent {
// Project (3mf)
NewProject,
ProjectOpened,
ProjectBeforeSave,
ProjectAfterSave,
ProjectClosed,
ProjectDirtyChanged,
// Slicing pipeline
SliceStarted,
SliceGeometryFinished,
GCodeExportStarted,
GCodeExportFinished,
SlicingJobComplete,
// Plate/model editing
ObjectAdded,
ObjectDeleted,
ObjectTransformed,
ObjectChanged,
ObjectRenamed,
PlateCreated,
PlateDeleted,
PlateSelected,
PlateRenamed,
// Preset
PresetSelected,
PresetSaved,
// Printer/device
PrintStateChanged,
DeviceOnlineChanged,
DeviceDiscovered,
DeviceSelected,
DeviceConnected,
DeviceDisconnected,
UploadStarted,
UploadFinished,
// Print/send jobs
PrintJobStarted,
PrintJobFinished,
SendJobStarted,
SendJobFinished,
};
```
This is an initial draft and lifecycle events can be included later on.
[orca_telegram_notifier_plugin_any.py](https://github.com/user-attachments/files/31220973/orca_telegram_notifier_plugin_any.py)
If you're familiar with telegram bots, after you install the telegram
bot, in the config of this plugin, you can enter the Bot ID and the Chat
ID with said bot.
# Screenshots/Recordings/Graphs
<!--
> Please attach relevant screenshots to showcase the UI changes.
> Please attach images that can help explain the changes.
-->
## Tests
<!--
> Please describe the tests that you have conducted to verify the
changes made in this PR.
-->
For this plugin, I am testing it with a telegram bot that sends me a
message on lifecycle event.
<!--
> A guide for users on how to download the artifacts from this PR.
-->
[How to Download Pull Requests Artifacts for
Testing](https://www.orcaslicer.com/wiki/how_to_download_pr_artifacts)
The CLI turned "align to Y axis" on for every i3 printer with no way to opt
out. With rotations forbidden the pre-rotation is the result, so every object
ends up turned 90 degrees from how it was loaded. The GUI defaults the
checkbox the same way for i3 printers, but lets the user untick it.
Add --align-to-y-axis. When it is not given the printer-structure rule still
applies, so existing calls are unchanged; the CLI's own options are filled
with defaults after parsing, so the keys the user typed are remembered to
tell the two apart.
* Answer the Preview's Per-Frame Time Query From a Cached Sum
The G-code preview's cost is linear in the number of toolpath vertices, and on a
tall multi-filament print the wipe tower dominates that count: it emits a roughly
constant 160-180 moves on every layer whatever the object is, measured at 57-61%
of all moves on a three-filament print.
Four places scanned or allocated across the whole vertex array. None of them
needed to.
get_estimated_time_at re-accumulated the estimated time from vertex 0 on every
call, and its caller is the tool marker tooltip, which ImGui re-renders every
frame while the properties panel is unfolded. It now starts from a running sum
kept at each layer's first vertex, built at load in vertex order, and adds only
that layer's vertices: the same additions in the same order, so the float result
is unchanged, at a cost of one float per layer and time mode rather than per
vertex. At the 351k vertices of a 636-layer test print the call scanned the whole
print (238us); it now scans one layer.
update_view_full_range walked from vertex 0 to find where the layer range starts,
on every slider tick. It now starts at the first vertex of that layer. The index
is derived from the vertices rather than from Layers::Item::range, because
Layers::update folds a vertex whose layer_id arrives out of order into whichever
bucket is open, which makes that range the wrong answer in general; the index
costs four bytes per layer, not per vertex.
update_colors_texture allocated one float per vertex of the whole print on every
slider tick. It now reuses a buffer.
render_legend fetched the layer Zs and the per-layer times from inside loops over
the custom G-code items, and built whole vectors only to test them for emptiness.
The times are hoisted, the Zs are built lazily so a print with no colour change
does not pay for them at all, and the emptiness tests use the existing counters.
No rendering behaviour changes.
* Draw the Preview's Toolpath Segments From an Index Buffer
The preview's frame cost is dominated by one call: a single instanced draw of
every visible toolpath segment. On a tall multi-filament print the wipe tower
supplies most of those segments, which is why the preview of a large tower is
slow and why shrinking the layer range speeds it up again.
That draw is not fill bound. Shrinking the model to about a fortieth of its
screen area moved the frame from 419 ms to 401 ms, so the cost is per segment,
not per pixel, and it is paid in the vertex shader: five texelFetch calls plus
several cross/normalize per invocation.
Each segment is a box of eight corners, but it was submitted with
glDrawArraysInstanced over a 24 entry array, so every corner was transformed
once per triangle that touches it and the shader ran 24 times per segment. The
same 24 entries are now an element buffer over the eight distinct corners, which
lets the post-transform cache reuse them and drops the shader to 8 runs per
segment. The triangles, their winding and the vertex_id each corner receives are
unchanged.
Measured over 100 frames on the 636-layer, 351k-vertex three-filament fixture,
the segment draw goes from 381 ms to 322 ms per frame. That is a software
rasterizer, where triangle setup dominates and understates the win; the drop in
shader invocations is the transferable part.
Verified by loading the same project in this build and in a build of the parent
commit and comparing the canvas across three states - the default view, a
rotated camera, and a reduced layer range: pixel identical in all three. The
rotated case matters because the shader picks its corner offsets from the camera
direction. The only pixels that differ anywhere on screen are in the G-code text
panel, which prints a per-process object id that varies between any two runs.
* Add Prusa CORE One MMU3 profiles
Dedicated MMU3 CoreOne profiles (like those used on prusaslicer 3).
Tested with latest coreone and mmu3 firmware, and works as well as prusaslicer.
Correct model default materials to reference compatible MMU3 filaments.
Co-authored-by: Codex <noreply@openai.com>
* Consolidate the CORE One MMU3 generic filaments
The bundle shipped two families covering the same four MMU3 variants for
each generic material: a standalone `Generic X @MMU3` and a
`Prusa Generic X @CORE One MMU3`. The `Prusa Generic` spelling was renamed
away from the rest of the tree, so re-name the CORE One-tuned family to
`Generic X @Prusa CORE One MMU3` (they inherit the CORE One tune and now the
shared generic product id) and drop the standalone files, which only carried
raw material-base values. Repoint the model default_materials and re-register
the index.
* Fix the CORE One MMU3 0.4 default process
default_print_profile named `0.20mm Speed @COREONE0.4 + MMU3`, but the
preset is `0.20mm SPEED @COREONE0.4 + MMU3`. Preset lookup is case-sensitive,
so the intended default never resolved and compatibility selection silently
picked another tier.
* Normalise the CORE One MMU3 process names
Match the bundle's all-caps quality ladder: `Fast Detail` -> `FAST DETAIL`,
`Speed` -> `SPEED`, `Structural` -> `STRUCTURAL`, `Balanced` -> `BALANCED`.
Filenames now equal their preset name, as every pre-existing Prusa process
file does, and the index is rebuilt for the renamed entries.
---------
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: SoftFever <103989404+SoftFever@users.noreply.github.com>
Co-authored-by: SoftFever <softfeverever@gmail.com>
#15668 saves the compiler cache on cancelled and failed builds and then
drops the older entries for the leg on the ref. actions/cache/save only
warns when its tar fails, so a cancelled build whose ccache directory
was still being written saved nothing, the drop ran anyway and deleted
the leg's last good entry. The next run on main restored nothing and
compiled cold, and so did every PR that restored in the gap. Run
35405244634 (Flatpak x86_64, 2026-09-18) did this to
ccache-Flatpak-x86_64-35397824860-1; between 13 and 18 September 9 of
87 cancelled main build jobs did the same.
Look the new entry up before deleting anything, and keep the older ones
when it is not there.
Adds the LulzBot Mini 1 (single extruder, 0.5 mm nozzle, 2.85 mm filament)
to the existing Lulzbot vendor, which previously shipped only TAZ models.
Values are taken from LulzBot's own current slicer configuration
(github.com/lulzbot3d/CuraLE) rather than estimated:
- geometry and custom g-code from resources/definitions/single_mini_mini_1.def.json
and resources/gcodes/mini_1/{mini_1_start,mini_1_end}.gcode
- filament temperatures and cooling from resources/materials/*.xml.fdm_material,
overridden by resources/quality/single_mini/<material>/*.inst.cfg
The start g-code reproduces the Mini's nozzle wipe and four-washer G29 probe,
with the filament-type temperature conditionals used by the sibling TAZ profiles.
One deliberate departure from current CuraLE: the pre-wipe retract is 30 mm,
the value used by Cura LE 4.13.x, rather than the 4 mm current CuraLE uses.
The Mini probes by electrical contact between nozzle and washer, so the nozzle
must stay clean through the wipe and all four touches. At 4 mm the melt zone
stays full and can ooze onto a washer, which caused auto-levelling failures on
hardware; 30 mm empties it. The cost is a ~24 s purge at print start.
The three filament presets follow docs/HLSD/filament_id.md rule 4: a vendor
tuning a generic material inherits Generic X @System, keeps the Generic X base
name and declares no filament_id, so identity stays with OrcaFilamentLibrary.
Their compatible_printers is the Mini alone, disjoint from Generic X @Lulzbot
(TAZ only) as rule 3 requires. They exist because temperature is a filament-scope
setting, so LulzBot's values need printer-scoped presets. All six plate types
carry the same temperature, because the Mini has a single bed and curr_bed_type
can hold a stale value carried over from another printer.
Strictly additive: no existing profile is modified, so TAZ behaviour is
unchanged and no migration is required. Lulzbot.json is bumped to 02.04.00.05.
Verified with scripts/orca_profile_tool.py check and scripts/check_profile.sh
on the full tree (profile tool, system validation, slice, filament subtypes and
custom-preset fixtures all pass), by diffing sliced output against LulzBot's own
Cura LE g-code for the same model and filament (temps, retraction, speeds and
the full wipe/probe sequence match), and by printing a 3DBenchy on a Mini 1 over
OctoPrint.
Claude-Session: https://claude.ai/code/session_012aLyqsXB7FKqwQdE2QF7Et
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: SoftFever <103989404+SoftFever@users.noreply.github.com>
Preset::get_printer_type matches a preset's printer_model against every vendor's model names and returns the first hit, so two bundles declaring one name make the lookup order-dependent, and the Add Printer list shows the printer twice. The existing name check is per bundle, because base profiles share names across vendors by design; this one covers the global machine_model namespace and runs over the whole tree, like the setting_id and filament_id checks.
* Rework Ultimaker profiles
The Ultimaker profiles where not usable by default
* Fixes
* couple small fixes
* Rework Ultimaker profiles
The Ultimaker profiles where not usable by default
* Fixes
* couple small fixes
* Fixes
* fix errors
---------
Co-authored-by: yw4z <ywsyildiz@gmail.com>
Co-authored-by: SoftFever <softfeverever@gmail.com>
Fixed bug to ensure filename format respects multi-extruder filament selection
Improved filename format to ensure that the selected filament is included in the filename and not the [0] filament
Co-authored-by: SoftFever <103989404+SoftFever@users.noreply.github.com>
This is needed for the AnkerMake M5 and M5c to have correct print time estimates. Fixes a random super-long time on the M5 touchscreen.
Co-authored-by: SoftFever <103989404+SoftFever@users.noreply.github.com>
Fix incorrect printable_area for Raise3D Pro3 and Pro3 Plus profiles
All Raise3D Pro3/Pro3 Plus machine profiles (Left, Right, Dual) shared
the same 340x300 printable_area regardless of single vs dual extruder
use. This overstated single-extruder X travel by 40mm and failed to
shrink the Dual profile to the real nozzle-overlap zone.
Corrected to Raise3D's published build volume specs:
- Single extruder (Left/Right): 300 x 300 mm
- Dual extruder: 255 x 300 mm
printable_height (300 for Pro3, 605 for Pro3 Plus) and origin (0,0)
are unchanged; both were already correct.
Source: https://www.raise3d.com/pro3-series/
Co-authored-by: Jon Ashton <ashtonj@zentechman.com>
Co-authored-by: SoftFever <103989404+SoftFever@users.noreply.github.com>
* Increase max volumetric speed for CR-ABS filament
* Update filament settings for CR-PETG profile
* Increase max volumetric speed from 16 to 18
* Increase max volumetric speed from 16 to 18
* Increase max volumetric speed for CR-PLA Matte
* Adjust filament temperature and speed settings
* Update filament settings for ENDER FAST PLA profile
* Modify pressure advance and filament load settings
* Adjust filament cost, speeds, and pressure advance
Updated filament settings for Hyper PETG @K2 Plus.
* Update filament cost and pressure advance values
* Increase max volumetric speed from 10 to 14
* Enable pressure advance in filament profile
---------
Co-authored-by: yw4z <ywsyildiz@gmail.com>
Co-authored-by: SoftFever <softfeverever@gmail.com>
Ian Chua