feat: forward plateindex for index-coded .gcode.3mf uploads
Gcode inside a .gcode.3mf is index-coded (Metadata/plate_<N>.gcode) and a
bundle may carry several, so the upload must name which plate to print —
even a single-plate bundle, since its entry is still indexed.
A 1-based plate index is stored in PrintHostUpload::extended_info when use_3mf
is set; the OctoPrint and Moonraker hosts forward it as a `plateindex` form
field. Servers that don't use it ignore the unknown field, so the plain G-code
path is unchanged.
Refactor skirt and brim ownership and emission flow
Refactor skirt and brim generation around a common object/group
ownership model.
Skirts and brims are now emitted as a coordinated preamble
(skirt -> brim -> object) instead of being generated and emitted
through multiple independent code paths.
Changes:
- Fix repeated skirt emission caused by the previous skirt state
tracking logic.
- Restore local skirt/brim ordering for per-object skirts in
By Layer mode.
- Emit brims together with their owning object or object group.
- Handle combined brims independently from skirt grouping.
- Handle draft shields through the same ownership model as skirts.
- Fix draft shield generation when skirt height is zero.
- Generate draft shields after brim geometry is known, preventing
draft shields from overlapping brims.
- Reject unsafe grouped per-object skirt configurations in
By Object mode.
- Remove legacy skirt emission paths and state-management
workarounds.
Support brim generation remains unchanged.
Co-authored-by: SoftFever <softfeverever@gmail.com>
The `@FF AD5M 0.25 nozzle` filament variants carried the base profile's
full printer list (AD5M/AD5M Pro/AD5X 0.4/0.6/0.8) instead of the 0.25
nozzle printers. Combined with base profiles that also listed the AD5X
0.4/0.6/0.8 printers already covered by dedicated `@FF AD5X` variants,
multiple presets with the same alias became compatible with the same
printer. The filament combobox keys presets by full name but displays
them by alias, so these surfaced as duplicate entries (e.g. "Flashforge
PLA Silk", "Flashforge ASA Basic" shown twice).
Fix the `compatible_printers` lists (data only, no settings changed):
- Repoint the 15 `@FF AD5M 0.25 nozzle` variants to the actual 0.25
nozzle printers (Adventurer 5M 0.25 + Adventurer 5M Pro 0.25).
- Remove the redundant AD5X 0.4/0.6/0.8 entries from the base profiles
where dedicated AD5X variants already exist.
- Bump Flashforge profile version to 02.04.00.02.
Each affected filament now resolves to exactly one preset per printer,
and the previously uncovered AD5M 0.25 nozzle printers gain coverage.
* Snapmaker U1: add 0.2mm and 0.8mm nozzle profiles
Add machine and process profiles for the Snapmaker U1's 0.2mm and
0.8mm nozzles, and complete the 0.6mm process lineup. Follows the
same data-only pattern used to add the 0.6 / 0.4+0.6 nozzles in
commit afc3756.
The U1 ships with 0.4, 0.4+0.6 and 0.6 nozzle options today; the 0.2
and 0.8 nozzles are supported hardware but have no profiles, so they
cannot be selected. This adds them the Orca-native way: per-nozzle
machine presets plus a model-file dropdown entry, with their process
profiles filtered in via compatible_printers.
Machine (2): lean presets inheriting fdm_U1, mirroring the existing
SM_U1_06 (0.6) preset and overriding only the per-nozzle values;
setting_ids SM_U1_02 / SM_U1_08.
Process (21): 2 per-nozzle commons (fdm_process_U1_0.2_common,
_0.8_common) holding the nozzle line widths, plus 19 profiles
(0.2: 8, 0.6: 6, 0.8: 5) that inherit their per-nozzle common and
carry their own layer height, matching upstream's factoring. The two
0.24 Standard profiles that shared id GP029 are split into
GP029_06_024 / GP029_08_024.
Model dropdown: machine/Snapmaker U1.json nozzle_diameter
"0.4;0.4+0.6;0.6" -> "0.2;0.4;0.4+0.6;0.6;0.8".
Vendor index: register the new presets in Snapmaker.json.
The existing 0.4 / 0.6 / 0.4+0.6 presets resolve identically before
and after. scripts/orca_extra_profile_check.py and the profile
validator both pass.
* chore(profiles): bump Snapmaker vendor version to 02.04.00.04
Bump the Snapmaker vendor config_version so existing installs pick up the new 0.2mm and 0.8mm U1 nozzle profiles. PresetUpdater only re-imports a vendor bundle when the shipped version is strictly greater than the cached one.
---------
Co-authored-by: ni4223 <ni4223@users.noreply.github.com>
K1C: corrige erro 'End of file' ao enviar impressao (start_print)
A K1-family fecha o WebSocket 9999 assim que aceita o comando de iniciar
impressao. O start_print fazia um ws.read() bloqueante logo apos o write, que
estourava 'End of file [asio.misc:2]' e era reportado como erro -- embora a
impressao ja tivesse iniciado (o comando e entregue no write). Torna o read e o
close best-effort (overloads com error_code), eliminando o falso erro. Mesmo
padrao ja usado em feed_filament; cobre os caminhos single-color e multicor.
wxWidgets chooses target files based on the compiler id, which makes clang-cl
look under the clang_x64_lib layout.
The dependencies are built with MSVC naming/layout, and clang-cl uses the MSVC
frontend variant on Windows. Patch the generated wxWidgets config so clang-cl
loads the vc_x64_lib targets instead.
ALL_BUILD is a Visual Studio generator target. Ninja uses `all`.
When building with -x (Ninja generator), the script fails with
"ninja: error: unknown target 'ALL_BUILD'". Use the correct target
name for each generator.
The runtime DLL copy was nested under CMAKE_CONFIGURATION_TYPES, so it only ran
for multi-config generators.
Ninja single-config leaves that variable empty, which skipped copying OCCT,
GMP, MPFR, WebView2, and freetype DLLs next to the executable. Run the copy
logic for both generator styles while keeping it Windows-only.
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.
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
