oneTBB enables MSVC IPO/LTCG by default, which emits MSVC proprietary bitcode
objects when built with cl.exe.
lld-link cannot consume those /GL objects. Patch the TBB MSVC compiler settings
so IPO can be disabled and the dependency produces native COFF objects that both
link.exe and lld-link can consume.
clang-cl defines MSVC in CMake, but some guarded blocks apply flags or behavior
that are specific to cl.exe and should not be passed to clang-cl.
Exclude Clang from those MSVC-only branches so clang-cl follows the compatible
compiler path instead of inheriting cl.exe-only settings.
The Windows path builds url_prefix as a wide string.
MSVC accepts concatenating the narrow literals here, but clang-cl rejects the
mixed narrow/wide expression. Use wide literals so the concatenation type matches.
clang-cl is stricter about converting the T2A_ helper result in this expression.
Cast the conversion helper result explicitly to const char* so the intended
string conversion is unambiguous across MSVC and clang-cl.
LabelItemType values are used with Marker, which is std::size_t.
MSVC accepts the implicit narrowing in this path, but clang-cl diagnoses it more
strictly. Give the enum the same underlying type as Marker.
Eigen's .cast<T>() returns a lazy CwiseUnaryOp expression, not a materialized
Matrix. The distance_to_squared overload taking a nearest_point output parameter
expects a concrete Eigen::Matrix, so template deduction fails on clang-cl.
Materialize the cast into a local Vec variable before passing it.
MSVC accepted the expression directly; clang-cl correctly rejects it.
clang-cl does not instantiate BoundingBoxBase<Point, Points>::construct for
Points::const_iterator through the same transitive path accepted by MSVC.
Add the explicit instantiation so the template definition is emitted where the
clang-cl build needs it.
The Cartesian designed-view preview over-extended the toolpaths past the model
shell by a height-proportional amount (up to ~20mm tall parts), most visibly on
long multi-part prints; compact parts like a calibration cube looked fine.
Two coupled causes:
- Belt start G-code that primes with a Z advance and a 'G92 Z0' reset leaves a
constant machine-Z origin in the GCodeProcessor, so move positions are stored as
gcode_Z + origin. The linear back-transform mixes that constant with the
gantry-Y term, leaving a per-move designed-Y error that min-corner anchoring
cannot cancel when an elevated move (e.g. a bridge) happens to cancel it at the
bbox minimum. Expose GCodeProcessorResult::belt_z_origin (the m_origin[Z] left by
the start G-code) and subtract it before the back-transform.
- Elevated features (bridges/overhangs) are mis-mapped by the linear inverse to
outside the model body; build the anchor bbox only from moves within model_bb +/-
10mm, with a fallback to the full bbox when the clip would drop the bulk (object
placed away from the belt entry) so the gross-offset case still anchors.
Preview-only; G-code output is unchanged.
The belt designed (upright) preview back-transforms the machine-frame G-code
into model space with the linear belt inverse. That inverse recovers the
print's shape and orientation, but not the per-object placement/lift
translation: the object's position on the belt, the BeltSliceStrategy min-Z
lift, and the centering pre-translate are applied OUTSIDE
build_forward_transform() (see PrintObjectSlice.cpp), so its linear inverse
cannot undo them. The result was a constant offset (~20 mm on the belt-advance
axis) of the toolpaths from the model shell, on every model.
Recover the missing translation generally — independent of the offset's exact
source or the axis remap — by anchoring the back-transformed object body
(extrusions on layer_id >= 1, i.e. excluding the layer-0 prime/skirt) onto the
upright model bounding box, the same space the shells render in, and folding
that translation into the belt inverse before converting to libvgcode.
Replaces the previous Y=0 anchoring in LibVGCodeWrapper, which pinned the
toolpaths to the belt entry rather than to the model and so left the offset in
place for any object not sitting at the origin.
On a belt printer the emitted G-code is in the machine frame (45-deg sheared,
axis-remapped, scaled), so the toolpath preview shows the print as a sheared
slab floating off the bed. Map each toolpath vertex back to model/Cartesian
space for the "designed" view.
The back-transform is the inverse of the full G-code forward pipeline
(BeltGCodeWriter::to_machine_coords):
model = [BeltForward^-1 if !gcode_back_transform] . AxisRemap^-1 . MachineFrame^-1
built from config, so it handles any rotation / shear / scale / axis-remap
combination, not just plain 45-deg belt slicing. Computed in load_as_gcode()
from print.config() and applied per-vertex inside libvgcode::convert (display
position only; layer_id, times and the volumetric/flow math keep the raw
machine values, so the layer slider and stats are unaffected).
- Toggle with the existing "Show designed view" checkbox / hotkey B; off shows
the raw machine-frame G-code (useful for debugging the transform itself).
Defaults to on.
- Belt printers skip the same-result-id load cache so the upright view applies
and the toggle takes effect even when the G-code is unchanged.
- The object extrusions (layer_id >= 1) are anchored to the belt entry to drop
the constant machine-origin offset (start-G-code belt advance) that the linear
back-transform alone does not capture; start-G-code prime lines are excluded
so they don't steal the anchor.
Several Artillery and Flashforge machine profiles set the first-layer nozzle temperature with M104 (set, no wait) immediately before the purge/prime line. The purge then runs before the nozzle reaches temperature, so filament is extruded through a nozzle that is not yet hot enough to melt it. Changed M104 to M109 so the printer waits for the target temperature before purging.
Affected profiles:
- Artillery Sidewinder X3 Plus / X3 Pro / X4 Plus / X4 Pro (0.4 nozzle)
- Flashforge AD5X (0.25/0.4/0.6/0.8)
- Flashforge Adventurer 5M / 5M Pro (0.25/0.8 overrides + shared fdm_adventurer5m_common, which also covers the 0.4/0.6 variants via inheritance)
Refs #4337
Build the Linux AppImage for ARM64 (aarch64) alongside x86_64: the Linux CI
job now matrixes over both architectures, with arch-aware deps caching and
artifact/asset names (amd64 keeps its existing names). The aarch64 AppImage is
published to the nightly and release pages like the x86_64 one.
Run the unit-test suite on the aarch64 runner (faster GitHub arm runner); the
tests are built on that leg. Self-hosted keeps tests on the amd64 server.
Gabriel