Two defects found by auditing the body-focus x-ray path, which shipped compiled
but never exercised. Neither is reachable from the happy path its test plan
walks, which is why compiling it proved nothing.
1. A STALE FOCUS KILLED THE VIEWPORT. The focus is a body INDEX held by the panel
across recomputes, so it outlives the body it names: delete a body and the
stored index can point past the end. body_pickable() then rejected EVERY body,
because none of them equals an index that no longer exists — a viewport that
silently accepts no clicks at all, with nothing on screen saying why. Out of
range now means no restriction. Fail open, never dead.
2. THE COMBO AND THE FOCUS COULD DISAGREE. refresh_cs_body_choice() rebuilds the
Body combo and, when the body list shrank, silently reset the selection to
"(all)" — while the viewport stayed focused on the old index. Every other body
kept its 25% alpha and picking stayed restricted to a body that might be gone.
That is the exact mirror of the open_tool ordering bug this feature already
fixed once: that one showed "Body N" over an opaque scene, this one shows
"(all)" over a dimmed one. They are one state and are now written together.
Guarded on CoordSys being the active tool, since it is the only card that owns
this focus. In the edit path the function runs BEFORE open_tool with the
previous tool still active, so the guard is false and the caller's explicit
set_xray_focus still wins.
Also confirmed while reading, since the header asserts it: set_solid_pick() does
NOT touch m_pick_only_body, so the focus really does survive the mesh feed. That
claim now has a check behind it rather than a comment.
Reviewed and compiled (libslic3r_gui, RC=0); not exercised. snaporca-bgvk.
Two open findings from the first rig judgement of the connector glyph.
F4 — the quadrant collapses to a blob at grazing angles, which is exactly when
the roll is hardest to read. Adds a radial tick along +X extending past the disc
rim. As the disc flattens to a line the sector loses all its area, but a radial
spoke keeps its length and its direction along the one axis that still projects.
The alternative on the issue was to billboard the quadrant while the disc stayed
in-plane. Rejected, and not on taste: at true grazing the view direction lies IN
the connector's plane, so every in-plane direction projects onto the same screen
line and the roll is geometrically unrecoverable. Billboarding would not recover
it — it would face the camera and read as a definite orientation that is not the
frame's. Degrading to a direction that can still be trusted beats drawing a
confident lie. The tick is additive, so unlike billboarding it cannot make the
non-grazing case worse; it still wants judging on the rig at a true grazing view
before F4 is called closed.
F5 — roll-undefined was a loud red: the strongest colour in the viewport spent on
the least important connector, pulling the eye off the mate being made. It marks
"this one could not be derived", not an error. Muted amber says look-here without
shouting.
No tick is drawn when the roll is undefined — a tick there would assert a
direction that does not exist, which is the silent guess the hatched quadrant
exists to avoid.
Reviewed and compiled (libslic3r_gui, RC=0); not exercised. snaporca-wgsc.
Rib's depth already reused the Extrude arrow. Its thickness could not: the arrow
points along the plane normal, and thickness is an offset either side of the rib
line, IN the plane. Different direction, different handle.
Two square handles at mid ± perp·half, plus the slab's actual footprint drawn as
a thin closed rectangle — the footprint matters more than the dots, because what
a rib thickness means is how wide that slab lands on the body, and until now
there was no way to see it before committing.
A drag on either handle sets the FULL thickness, twice the perpendicular distance
from the line, because the slab is centred on the line and the handle sits at
half. Both handles behave identically for the same reason, so they share one
colour rather than pretending to be two different actions.
A zero-length line has no direction to grow a slab perpendicular to, so the
shared rib_frame() helper returns false and render and drag both draw nothing
rather than dividing by zero. Non-Line entities clear the gizmo instead of
guessing: the kernel is line-only and a gizmo that guesses would be lying about
what Confirm will build.
Unlike the helix callback this one goes through refresh_preview(), because Rib
builds a real solid ghost that has to rebuild. The helix has none and skips it
deliberately.
Both gizmos coexist and resolve the sketch and entity the same way, so the depth
arrow and the thickness handles can never disagree about which line they are on.
Reviewed and compiled (libslic3r_gui, RC=0); not exercised. snaporca-plew.
Driving the control socket: hexagon prism, six vertical fillets, four chamfers
on the already-filleted rim, an M8 hole. Afterwards describe_scene reported
bodies=3 and error='' — entirely healthy — while body 2's TopoDS_Shape was null.
Only mass_properties on that one body revealed anything was wrong.
So a feature destroyed a body, recompute() returned true, and the document went
on advertising it. Any downstream consumer — slicing, STEP export, a mass
properties report — met a null shape with no warning. That is the silent
corruption class, which is the one class this project does not tolerate.
recompute() now scans the freshly built bodies for a null shape, names the body
and the feature that destroyed it, and returns false. Returning false rather than
just setting error is the point: it hands the caller its normal rollback path, so
the operation that destroyed the body is undone instead of committed.
The message says "an unidentified feature" when source_feature is -1. "feature 0"
would be a lie, and a message that exists to tell you where to look has to be
trusted.
TEST IS A POSITIVE CONTRACT, AND THE REASON MATTERS. The reported order was
driven headlessly first, as the better test: it does NOT reproduce. The dress-up
step throws "fillet radius too large", which is an already-loud already-caught
path, so recompute fails honestly and never nulls a body. No public-API sequence
found so far reaches the guard's branch without a GUI, and faking a null into
`bodies` after the fact would not exercise it — the guard runs on `built`, before
the swap. So the test asserts what can be asserted: a box + fillet recomputes
true, error is empty, and no body is null. The guard's own branch is defensive
and currently unexercised; that is stated here rather than implied by a green
suite.
Kernel suite: 2217 assertions in 161 test cases, all passing. No existing test
relied on a null body surviving a recompute, so hardening this broke nothing.
snaporca-5425 (part a). Part b — why the chamfer chain degenerates on an
already-filleted rim — is untouched and stays open.
grep -i helix over the viewport code returned nothing at all. The tool was four
coupled numbers and a Confirm button — you typed radius, pitch, height and taper
blind and pressed OK to find out what you had made. So this is not only the
charter's L2 failure; the tool had no visible state whatsoever while it was open.
Adds a plane-anchored helix gizmo built on the datum-plane gizmo as its template,
being the closest existing thing: also plane-anchored, also driven by a card while
the sketch tool is inactive, also a render / hit-test / drag triad.
It draws the live curve and the axis, and puts a handle on each of the three
lengths: radius on the base circle, height at the top of the axis, pitch at the
end of the first turn — which is exactly where one pitch of rise lands, so the
handle means what it is standing on. Below one full turn the pitch handle moves
to the end of the curve rather than floating off a curve that does not exist yet.
Taper and handedness stay on the card. One is a shape modifier and the other a
flag; L2 governs numbers you can point at.
A drag reports the whole (radius, pitch, height) triple rather than one value,
because pitch and height are coupled through the turn count and writing one alone
would redraw a stale curve. The callback re-feeds the gizmo directly instead of
going through refresh_preview(), since Helix takes the produces-no-solid early
return and refresh_preview would rewrite the status line on every mouse move.
REVIEW CATCH, fixed here: the first cut read taper as a fraction of the radius
consumed over the turn count. It is an ANGLE IN DEGREES — helix_spine() builds a
Geom_ConicalSurface of half-angle taper and takes the top radius as R+H*tan(taper),
growing with the height risen. The wrong reading drew a preview that collapsed to
a point for any non-zero taper while the committed feature was perfectly fine. A
preview that lies is worse than no preview, which is what this commit replaced.
Reviewed and compiled (libslic3r_gui, RC=0); not exercised. snaporca-i3jc.
Rib's depth is a distance along the sketch plane normal, so it is the Extrude
arrow for the fourth time — anchored at the midpoint of the line the rib is
built on, because a rib's line IS its profile.
This is half of Rib's L2 failure. The thickness is an in-plane offset either
side of that line and no existing gizmo draws that; it needs a handle that does
not exist yet, filed as snaporca-plew rather than left implied. One of two
numbers draggable is strictly better than neither, and saying which half is
missing is the point.
Reviewed and compiled (libslic3r_gui, RC=0); not exercised. snaporca-i3jc.
Both tools produce exactly one number — a distance along a known normal — and
neither had a handle for it. That is the same shape as the Extrude depth arrow,
which was already written, already draggable and already had an editable label
on the geometry. So this adds no gizmo: it points the existing one at two more
tools.
SurfaceExtrude anchors on its sketch's plane, at the profile centroid.
Thicken anchors on the picked face, and reuses the face-as-profile recipe from
the Extrude path verbatim — including the two things that path learned the hard
way: look the face up on its OWNER body rather than the whole-document compound,
and carry that body's display Move transform onto both the origin and the
normal, or the arrow draws on the bed instead of on the face.
The drag callback routes by active tool. `second` stays Extrude's alone: it is
the two-sided pair, and the other two have a single distance each.
SurfaceOffset is the third tool in this group and is deliberately NOT here. Its
target is an arbitrary sheet body, which has no single normal to anchor an arrow
on — that is a design decision, not typing, and it stays on the audit.
Reviewed and compiled (libslic3r_gui, RC=0); not exercised. snaporca-i3jc.
The Placement > Transform verb opened a card of spin controls — dx/dy/dz, an
axis combo, an angle — with nothing on the geometry. The 3-axis drag gizmo the
charter asks for already existed and was fully implemented (arrows, rotation
rings, click-to-type per axis), reachable only from a small icon button in the
tree card header. The prominent verb opened the form; the geometry-first
control was hidden behind an icon. That was backwards.
Transform now arms that same gizmo on the target body. The card stays as L2's
typed half: the drag writes dx/dy/dz, the axis and the angle, and the pivot is
seeded from the body's centroid so the parametric feature reproduces exactly
what was dragged.
Decomposition is exact for the interaction that matters — the gizmo's rings are
per-world-axis, so a ring drag is an axial rotation. A pose composed from two
rings is not axial and the card can only name one axis, so it reports the
dominant one rather than refusing to answer.
Three things this had to get right:
- The gizmo bakes its drag into the display transform so the body follows the
cursor, and the feature performs the same motion parametrically. Committing
without reverting first would move the body twice.
- tool_confirm() and tool_cancel() both tested moving_body() BEFORE the active
tool, so with the gizmo armed Confirm would have dropped the gizmo and never
created the feature. Both are now guarded on Tool::None.
- close_tool() is the single revert point. Esc, Cancel and switching tools all
pass through it, so a Transform that was never committed cannot leave the body
displaced.
Edit mode is untouched: re-seeding the gizmo from a stored feature is a separate
problem, so editing an existing Transform still gets the card alone.
Reviewed and compiled (libslic3r_gui, RC=0); not exercised. snaporca-qtf4.
Three defects behind one report ("bodies cannot be moved or hidden/shown or
deleted, colour does not work"). They are unrelated to each other; only the
symptom was shared.
1. The Color tool wrote a per-body override that was correct end to end —
stored on CadBody, carried across recompute (CadDocument.cpp:3381), read
back by DesignCanvas::body_color() — and then overpainted every frame.
m_body_selected is a DOCUMENT-WIDE flag raised whenever a non-Sketch
feature row is selected, which is the resting state after any modelling
operation, and while it was true every body rendered gold. An explicit
colour now outranks the selection tint; unpainted bodies still tint, which
is all the tint was ever for.
2. The eye toggle re-selected the body row through m_tree, using item ids that
belong to m_parts. The row came back unselected, so the second press found
tree_body_selection() == -1 and fell through to the feature-level branch
instead of un-hiding. Hide worked exactly once. The sibling call in
refresh_parts() had it right.
3. The tree card's Delete button answered a selected body row with "select the
FEATURE that created this body" — an instruction the user cannot act on,
because the tree does not say which feature that is. on_delete_body()
already resolves CadBody::source_feature and confirms by name; it was
reachable only from the right-click offer. The button now routes to it.
Reviewed and compiled (libslic3r_gui, RC=0); not exercised — needs a session at
the machine to confirm all three in the viewport. snaporca-zjvg.
DesignCanvas::set_view() and fit_view() were both written and then never called
from anywhere in the tree. The Design viewport has had no way back to a standard
view since it existed: no key, no button, nothing but orbiting by hand until the
model happens to drift into frame.
That is worse than a missing convenience. A camera left pointing along the bed
plane renders a scene that looks exactly like a failed renderer — geometry
present, nothing visible — and an hour went into blaming the software GL stack
before the real cause turned out to be two uncalled functions.
Home rather than a letter: every letter A-Z is already a Shift+letter tool
shortcut. Home is also the reset-the-view key most users arrive with. The
dispatcher needed no change, it keys on the raw wx keycode. set_view() already
does select_view + zoom_to_volumes, so this is fit and orient in one call.
Doc row added to the View toggles table in docs/design_tab.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
tests/libslic3r/CMakeLists.txt added only test_caddocument.cpp under
SLIC3R_CAD. The other five shipped in the tree and were never compiled, so
49 TEST_CASE blocks looked like coverage and were not: sketch constraints,
sketch editing, sketch import, inference, and the libslvs constraint set.
They also still targeted Catch2 v2 — mainline is on v3, where the umbrella
header is catch2/catch_all.hpp and Approx lives in the Catch namespace rather
than at global scope. Both fixed; nothing else in the files changed.
Found by building the tree rather than reading it. Suite goes from 374 to 423
test cases, 54,424 to 54,620 assertions, all passing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two enabled mates driving the same body is not an error today — the later one
just wins, and the earlier mate looks ignored with nothing said. A cycle in the
mate graph is worse: composition still produces a result, but an arbitrary,
order-dependent one.
recompute() now fills a mate_conflicts vector of (feature index, reason) before
the geometry pass, so it survives a throw further down. It catches a second mate
on the same target body, a mate positioning a body against itself, and a cycle,
via an iterative three-colour DFS over the body graph. Broken mates are skipped
silently — apply_mate() already errors on those.
Deliberately non-fatal: recompute() still returns true and error stays empty.
Deliberately not "over-constraint" — that word promises DOF analysis from a
solver this kernel does not have.
Port of snaporca ec4ffeb979. Kernel half of snaporca-bioq.
Suite: 2213 assertions / 160 cases green on this fork too.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
In an assembly the face you want for a mate connector is nearly always behind
another body, and a click only ever returns the frontmost hit. Hiding the
occluder from the Parts list works but means leaving the tool mid-pick.
The CoordSys card now carries a Body chooser. Pick a body and every other one
drops to 0.25 alpha AND stops catching clicks, so the wanted face is both
visible and reachable in one gesture. "(all)" restores normal picking.
Deliberately NOT hit cycling: repeated-click cycling was removed from solid
picking as a charter L5/§10 violation (DesignSketchTool.cpp, "NO CYCLE"), and
re-introducing it here would make "click a face" a multi-click gesture again.
Mechanics: DesignSketchTool::set_pick_only_body() gates body_pickable(), which
every pick path already consults; DesignCanvas::set_xray_focus() drives both it
and the per-body alpha in reload(). The chooser stays a pick FILTER only --
coordsys_body still comes from the actual pick, so nothing in the kernel moves.
Body focus follows the CoordSys card: open_tool() reads it back from the combo
rather than clearing outright, because editing a CoordSys feature loads the card
(and its body) before open_tool runs.
snaporca-bgvk. NOT COMPILED: deps/build lacks OpenVDB so the GUI tree will not
configure here; reviewed by diff only.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mate_cs_a/mate_cs_b are feature indices. remove_feature() remapped sketch_ref
through the deletion but not the mate connectors, and move_feature() swapped
sketch_ref but not the mate connectors. Deleting or reordering any feature
ahead of a connector slid both references onto whatever features landed on
those slots.
Nothing reported it. recompute() only rejects out-of-range and non-CoordSys
targets, and a shifted index normally lands on the assembly's other CoordSys —
an assembly carries at least two by construction. So the mate resolved against
the wrong frames and moved the wrong body, silently.
Extracted a remap lambda in remove_feature() and a swap_ref lambda in
move_feature(), applied to sketch_ref and both mate connectors.
Two tests, both confirmed red before the fix. [mate] tags green here:
395 assertions / 29 cases — the first end-to-end kernel compile of this fork.
Ported from snaporca; CadDocument.cpp is byte-identical across forks again.
Refs: snaporca-kqih
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Move Generic vendor above Bambu vendor in AMS material setting.
* Remove hardcoded sorted_names. Alphabetically sort Bambu with all vendors
* Fix sorting with case insensitive comparison
* Use arithmetic to get rank distance because priorities are stored in a vector. This lets us remove the <interator> include.
* Move currently active filaments added to the Prepare sidebar to the top of the AMS Material Selection combo box.
It is likely the user wants to set the material to the currently active filament.
* Reduce logging verbosity.
* Refactor current active preset filament finding to find nested preset inheritance.
* Initialize pointer to null before usage.
* Remove old commit code
* Remove new line
---------
Co-authored-by: Ioannis Giannakas <59056762+igiannakas@users.noreply.github.com>
Co-authored-by: yw4z <ywsyildiz@gmail.com>
* Fix detached copies of system presets
* Clarify detached preset compatibility
* Show unique preset state in save dialog
* Update SavePresetDialog.cpp
---------
Co-authored-by: yw4z <ywsyildiz@gmail.com>
* re:3D profile updates.
- Replace vendor-specific "re3D Greengate rPETG" filament with a generic "re3D rPETG" (base + @0.8/@1.75 nozzle variants), matching the naming convention used for rPLA/rPETG elsewhere in the re:3D vendor
pack.
- Add fdm_filament_pp as a proper filament-type parent and switch re3D rPP to inherit from it instead of overriding filament_type on top of fdm_filament_pet.
- Added filament_type to the specific printer JSON file and removed from the base printer JSON file [fixes Issue#14693]
- Updates to speeds and accelerations for re:3D profiles, moved from common to machine processes [closed: PR#14259]
- Updates to fdm profile filename format so that it lists the filename and extruder number in the sliced .gcode file
* Fix setting IDs
* Add rename from for changed material names.
Follow-up to #14785. Routes the tests that still hand-rolled temp paths through
the shared helpers and unifies the temp guards.
- Add ScopedTemporaryDir and a shared ScopedTemporaryPath base under it and
ScopedTemporaryFile.
- Move test_3mf's round-trip .3mf output out of the TEST_DATA_DIR source tree
(a fixed-name leak) and test_toolordering's fixed-name temp .gcode (a sharding
collision) onto ScopedTemporaryFile.
- Move test_config, test_slicing_pipeline_bindings, the test_3mf backup dirs, and
test_preset_bundle_loading onto the guards.
- Make slic3rutils ScopedDataDir compose ScopedTemporaryDir; dedupe
test_network_versions' fixture and delete test_plugin_lifecycle's duplicate.
* fix(GUI): honor "Ignore" when layer height exceeds the configured maximum
Entering a layer height above the printer's max_layer_height on the Print
Settings tab fired two guards in sequence. Tab::on_value_change prompts
"...Adjust to the set range automatically?" with an Adjust/Ignore choice, and
ConfigManipulation::update_print_fff_config then showed an OK-only "Too large
layer height. Reset to X" dialog whose result was never checked, so it always
reset the value. The second guard overrode the user's "Ignore", resetting the
layer height regardless.
Changes:
- Extract the shared Adjust/Ignore dialog into
ConfigManipulation::layer_height_out_of_range_dialog, reused by the tab
(Tab::on_value_change) and the per-object/part settings panels. The dialog now
names the value it will clamp to and reads correctly for too-low as well as
too-high.
- The tab/plate path is already covered by Tab::on_value_change, so the
duplicate reset is dropped from update_print_fff_config.
- The per-object/part panels have no on_value_change hook, so add
ConfigManipulation::check_object_layer_height and call it from the object
settings update paths, gated on the edited option (changed_opt_key ==
"layer_height"). It prompts once per layer-height edit and does not re-prompt
when unrelated object settings change after the user chose "Ignore".
Fixes#14214
* refactor(GUI): unify the layer-height range check across tab and object panels
Copilot review of #14369 noted that the per-object check only guarded the
max at extruder 0 and skipped the too-low case, diverging from the tab.
Move the whole range check into ConfigManipulation::check_layer_height,
used by both Tab::on_value_change and the per-object/part panels. It takes
the widest [min, max] window across the printer's extruders, offers
Adjust/Ignore in both directions, and resets a near-zero value. The tab's
inline block collapses to one call, dropping the duplicated limit logic.
* fix(GUI): only enforce layer-height limits that are actually set
max_layer_height defaults to 0 (unset), so the unconditional range check
offered to clamp any layer height to 0 on presets that don't define it.
Guard each branch (near-zero, too-high, too-low) so an unset limit disables
that direction; the slice-time nozzle-diameter check still applies.
Also run check_layer_height before update_print_fff_config in the object
panels so a near-zero per-object value prompts the same way the tab does,
with update_print_fff_config's fallback still covering the no-minimum case.
_update_select_plate_toolbar_stats_item(true) runs from
on_action_slice_all before the select-plate toolbar has necessarily been
initialized. m_all_plates_stats_item is only assigned in
_init_select_plate_toolbar, so slicing a multi-plate project shortly
after startup (before the Preview tab has rendered) leaves the pointer
null while show_stats_item is true, and the branch dereferences it,
crashing with SIGSEGV.
Every other dereference of this pointer already null-checks it. Add the
same check here so the all-plates stats item is left unselected until the
toolbar is initialized instead of crashing.
Fixes#15116
min_length_factor and is_top_or_bottom_layer had no default initializers, and the FillConcentric/FillConcentricInternal callers never set them, so WallToolPaths::removeSmallLines() thresholded on stack garbage. Which short extrusion lines it dropped then depended on memory layout, so concentric solid-infill output was nondeterministic between runs and across machines. Give every member a default, matching the adjacent FillParams. The perimeter path was already fine because it builds the struct via make_paths_params().
* Add the Qidi Plus 5
* Remove ignored profiles
Qidi didn't register these, so they are essentially dead weight.
* Set Qidi profile version to 02.04.00.10
* Review AI changes
* Part 2
* Part 3
* Part 4
God bless Ian Alexis
* Part 5
* Final part!
* Catches by Gemma
This 6-minute check probably saved me a week
* Tweak
* Update OrcaSlicer_ru.po
## Problem
`Toolchange temperature commands are unchanged when the wipe tower wait
is off`
(added in #15144) fails on both Linux runners and passes on Windows and
macOS.
It is the only failing test in the suite, and it has been failing on
main since
that PR merged.
| Job | Result |
| --- | --- |
| Windows x64 / Unit Tests | pass |
| Windows arm64 / Unit Tests | pass |
| macOS arm64 / Unit Tests | pass |
| Linux x86_64 / Unit Tests | **fail** |
| Linux aarch64 / Unit Tests | **fail** |
From the merge commit
([Linux
x86_64](https://github.com/OrcaSlicer/OrcaSlicer/actions/runs/31072382258/job/92531704095),
[Linux
aarch64](https://github.com/OrcaSlicer/OrcaSlicer/actions/runs/31072382258/job/92531704075)),
still reproducing on current main:
```
first difference at trace entry 29
main: M104 S240 T0 ; preheat T0 time: 31s lead 30.9s
branch: M104 S240 T0 ; preheat T0 time: 30s lead 30.3s
```
## Cause
Each preheat entry records the same quantity twice: `lead` at one
decimal, and
`time:` inside the command text as that value rounded to a whole second.
`split_lead` already compares `lead` with a 0.5s tolerance and explains
why the
estimate moves. `time:` sits in the exactly-compared command text, so it
never
got that tolerance — and being rounded, it flips on a drift far below
0.5s
(30.4 and 30.6 render as `30s` and `31s`). Entry 29 is the only entry in
the
163-entry golden whose lead rounds up; every other preheat sits at
30.0–30.4 and
rounds down, which is why it is the only one that fails.
The variation is per-toolchain, not run to run. Both Linux arches
produce
exactly `lead 30.3s`; Windows x64/arm64 and macOS arm64 all produce
exactly
`30.9s`. Repeated local runs are byte-identical. macOS arm64 passing
while Linux
aarch64 fails rules out the ISA — it is floating-point accumulation over
a few
thousand move durations under GCC vs Clang vs MSVC.
The mechanism makes it discrete rather than gradual: the backtrace parks
the
preheat at the first exported line at least `preheat_time` before the
tool
change, so `lead` is `preheat_time` plus the leftover of whichever move
that
landed on. A sub-tenth difference selects the neighbouring move and
`lead` steps
by that move's whole duration.
Entries 1–28 match exactly, including five earlier preheats whose leads
fall
inside the existing tolerance, so the toolpaths themselves are
identical. I also
reverted the two prime-tower commits that landed between the golden's
capture
point and now, rebuilt, and got a byte-identical trace — this is not
behavioural
drift.
That also rules out regenerating the golden: no single capture satisfies
all
three toolchains, and recapturing on Linux would turn the three
currently-green
runners red.
## Fix
Test-only.
- `lead` keeps a tolerance, widened to 1.5s (measured drift 0.6s; a
preheat
actually leaving its backtrace position would move by tens of seconds).
- `time:` is **not** compared across runs at all. Being a rounding of
`lead`, it
carries nothing the tolerance does not already cover, and comparing it
across
runs can only reproduce the flake. It is instead checked against its own
entry's `lead` — a correct rounding keeps `|time - lead| <= 0.5`.
That second point matters: simply tolerating `time:` numerically would
have made
the test blind to a real change, because drift and a wrong rounding both
move it
by 1. The self-consistency check keeps that coverage. I verified it by
changing
`(int) std::round(time_diffs[0])` to `(int) time_diffs[0]` in
`GCodeProcessor::export_lines` — the test fails with
`"time:" is not its entry's "lead" rounded to a whole second`, where a
plain
tolerance would have passed silently.
Everything else is still compared exactly: all M104/M109 values, tool
ids,
block markers, ordering, entry count, and the annotation text including
its
trailing `s`. The other 138 entries remain byte-exact.
No production code, no golden regeneration. The golden file and these
helpers
are used by this one test and nothing else, and the tolerance only
widens, so
Windows and macOS keep passing unchanged. A note is added to the
golden's header
so the next mismatch in those fields is not "fixed" by recapturing.
## How to verify
Before, on Linux:
```bash
git checkout main && ./build_linux.sh -t
ctest --test-dir build/tests -R "Toolchange temperature commands are unchanged" --output-on-failure
# fails at trace entry 29
```
After:
```bash
cmake --build build --config Release --target fff_print_tests
ctest --test-dir build/tests --output-on-failure # 463/463
```
Fix Windows crash in Replace all with 3D file
Keep the replacement result message as wxString and substitute the volume
name directly.
On Windows, wxString::ToStdString() cannot encode the Unicode status icon
through the active ANSI code page and returns an empty string. Passing that
empty string to boost::format with a volume-name argument throws
boost::too_many_args and exits OrcaSlicer.
* Fix redundant QIDI startup tool changes
Guard Q2, X-Max 4, and X-Plus 4 filament-change G-code so same-tool startup selections do not run the full cut, unload, and purge sequence.
* Guard Q2C against redundant startup tool changes
Skip the complete filament-change sequence when the requested tool is already selected during startup.
* Bump Qidi profile version
# 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?
-->
The prime tower reserved its footprint from the prime volume alone,
ignoring the flush volumes it actually has to hold, so on a multi-colour
print the tower shown in Prepare and the space kept clear for it during
arrange could be far smaller than the tower that gets sliced — leaving
it overlapping objects or running off the plate. This sizes the estimate
from the configured flush volumes instead, for rib walls as well as
rectangle and cone, applies the same height-based minimum depth the
prime-volume estimate already used, and reads the flush matrix correctly
on multi-nozzle printers, where it holds one block per nozzle.
Only the pre-slice estimate changes: the generated tower is untouched,
and prints that do not purge into the prime tower keep their existing
size.
# 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.
-->
<!--
> 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)
Prime towers reserved depth from the prime volume alone, ignoring the flush
matrix: rib-wall towers in both the engine and the preview, and rectangle and
cone towers in the preview, which never carried the flush-aware estimate the
engine already used. The preview also read the print preset, which does not
carry the printer- and filament-scope keys the estimate needs and so silently
fell back to defaults. On multi-nozzle printers the flush matrix, which holds
one block per nozzle, was additionally read as a single block. The tower could
come out too small for the purge it has to hold.
The flush-based estimate also skipped the height-based minimum depth that the
prime-volume one applies, so low-flush prints could estimate a tower shallower
than the one that actually gets built.
# 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?
-->
On delta, circular and custom bed shapes — and on multi-nozzle printers
where each carriage only reaches part of the plate — the prime tower was
positioned and clamped against the bed's bounding box, so it could be
parked in a corner the bed does not actually have. Neither the default
placement nor dragging the tower would pull it back onto the bed, and
slicing went ahead without complaint. The tower's default position, its
drag clamp and the slice-time validation now all follow the real
printable outline, and a tower that genuinely does not fit is reported
as "Prime Tower is partially outside the printable area" instead of
being sliced into a print that cannot be produced.
The travel that approaches the tower is planned against that same
outline. Previously the router gave up whenever its clearance box fell
outside the bed and drove the nozzle straight across the tower; a tower
parked near the bed edge now keeps its detour and enters through the
wall opening as intended.
This also corrects the footprint the prime tower validation uses for a
rotated tower, which was being rotated by the wrong amount and about the
wrong point, so proximity warnings and exclusion-area errors for rotated
towers were being computed against the wrong shape.
Prime tower placement on rectangular beds is unchanged. The new
printable-area validation and the tower-approach routing fix apply to
every bed shape.
# 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.
-->
Added unit coverage for the placement clamp against a non-rectangular
outline (a regular hexagon standing in for the shipped delta beds),
covering the rectangular-bed path, single-axis clamping while dragging,
a footprint already inside the outline, one sitting in the bounding-box
corner but off the bed, an unresolved auto brim width arriving as a
negative margin, and a footprint too large for the bed. The `fff_print`
suite passes.
<!--
> 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 placement clamps and the tower-approach router both stood in the bed's
bounding box for the bed itself, so on a delta or hexagonal bed the prime tower
could be parked in a corner that does not exist and the nozzle could be routed
across it. Both now test the real printable outline, slicing reports a tower
that does not fit instead of printing it off the bed, and a tower parked near an
edge is routed along the clamped side rather than falling back to a straight
line across the tower.
Also fixes the placement validation rotating the tower hull by degrees read as
radians about the plate origin, and never rotating the generated tower footprint
at all.
# 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?
-->
Adds **Wait for temperature on wipe tower**, a printer option for
multi-extruder
machines using a Type 2 wipe tower. With it on, the new tool is picked
up without a
blocking temperature wait; the printer travels to the wipe tower and
waits there
right before purging, parked beside the tower so the ooze from the
heat-up lands
next to it rather than on the model. The incoming filament's target is
raised ahead
of the tool change, so the heat-up overlaps both the change itself and
the travel to
the tower.
The benefit is less oozing and less dead time. The tool no longer sits
at full print
temperature while it waits to be picked up or right after it undocks —
it heats on
the move and only reaches temperature once it is over the tower, so
there is far less
hot-and-idle time, and what does ooze ends up beside the tower. This
matters most on
tool changer printers with long docking and attaching cycles, such as
Tapchanger and
StealthChanger machines, where that wait is otherwise pure stall time
spent dripping.
The firmware or tool change macro must not wait for the temperature
itself. The
option is off by default and only shown for multi-extruder printers on a
Type 2 wipe
tower, and it is enabled by default for the generic toolchanger profile.
# 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.
-->
New Catch2 cases in `tests/fff_print/test_multifilament.cpp`: the wait
moves to the
tower when enabled, priming pre-heats to the first layer temperature,
the park side
is regenerated when the tower is moved or rotated, and a regression test
pinning the
unchanged (option-off) toolchange temperature commands against a
recorded trace
(`tests/data/wipe_tower_temperature_trace_main.txt`).
<!--
> 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)
Adds a printer option that picks up the new tool without a blocking temperature
wait, travels to the wipe tower, and waits there right before purging, parked
beside the tower so the ooze from the heat-up lands next to it rather than on the
model. The incoming filament's target is raised ahead of the tool change, so the
heat-up overlaps both the change itself and the travel to the tower.
Off by default, and only offered for multi-extruder printers using a Type 2 wipe
tower; the generic toolchanger profile enables it.
* fixes: memcpy(...) writing to an object of type OrientParams with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
* review result: replaces anonymous namespace with static
* fixes: may be used uninitialized [-Wmaybe-uninitialized]
* fixes: may be used uninitialized [-Wmaybe-uninitialized]
* fixes: may be used uninitialized [-Wmaybe-uninitialized]
* fixes: may be used uninitialized [-Wmaybe-uninitialized]
* reverts {} initializer to = to keep code style consistent
* fixes: %g directive writing between 1 and 13 bytes into a region of size between 6 and 18 [-Wformat-overflow=]
* fixes: %5s directive writing between 5 and 63 bytes into a region of size 58 [-Wformat-overflow=]
* fixes: catching polymorphic type by value [-Wcatch-value=]
* fixes: [-Wcomment]; removes whitespaces
* increases buffer size from 71B to 90B to avoid potential ovfl.
Tommaso Bianchi