Fix nozzle diameter guards for printers that don't report nozzle info (#13236)
PR #12814 changed DevNozzle::m_diameter default from 0.4f to 0.0f to
mean "unknown" when firmware doesn't push nozzle info, and guarded two
call sites in SelectMachine.cpp. PR #13330 introduced
DevExtderSystem::NozzleDiameterMatchesOrUnknown() and adopted it in
get_printer_preset / CalibUtils / CalibrationWizardPresetPage. A few
reachable sites were still left out and now report "mismatch" / fail
silently for every non-BBL printer (Klipper/Moonraker, RRF, Marlin,
etc.) that doesn't push BBL nozzle data.
The most visible symptom: the "Sync filament colors from AMS" button on
Moonraker printers with AMS/AFC silently does nothing, because
get_printer_preset() couldn't find a matching system preset (fixed in
#13330, but the lookup-string sites below kept the bug visible
elsewhere).
Apply NozzleDiameterMatchesOrUnknown at the two remaining comparison
sites:
src/slic3r/GUI/Plater.cpp
- file-load printer-mismatch dialog — don't prompt on every load
- on_select_preset sync_extruder_list gate — skip 0.0 extruders
For the three filament-lookup string-builder sites, fall back to the
currently-selected printer preset's nozzle diameter so the dropdown
isn't empty when firmware hasn't reported a diameter:
src/slic3r/GUI/AMSMaterialsSetting.cpp (Popup + on_select_filament)
src/slic3r/GUI/CaliHistoryDialog.cpp (get_all_filaments)
Also remove the dead SyncAmsInfoDialog::is_same_nozzle_diameters method
surfaced while auditing the affected sites — it was introduced
2024-12-30 in commit ad79ed6d93 ("ENH:add SyncAmsInfoDialog",
cherry-picked from Bambu's internal branch) but a caller was never
wired up on the OrcaSlicer side. Dead since introduction.
Fixes#13236
Refs #12814#13330
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: SoftFever <softfeverever@gmail.com>
* Fix data race in extra bridge layer generation causing spurious bridges on top surfaces
* Guard second bridge layer against top most surfaces
* CoPilot review comments & lighting infill threading fix.
* Fix overhang preview not using fallbacks when angle is 0
The overhang visualization in Preview ("show overhangs based on support settings")
used the raw `support_threshold_angle` value from the configuration.
When `support_threshold_angle` was set to 0, Orca internally falls back to:
- 30° for tree supports
- an angle derived from `support_threshold_overlap` for normal supports
However, the preview logic ignored these fallbacks and used the raw value (0°),
leading to incorrect overhang highlighting that did not match the actual
support generation behavior.
This patch computes the effective overhang threshold used for preview:
• If `support_threshold_angle > 0`, use it directly
• If `support_threshold_angle == 0` and tree supports are used, fall back to 30°
• If `support_threshold_angle == 0` and normal supports are used, derive the
equivalent angle from `support_threshold_overlap`, `layer_height`, and the
external perimeter width.
The function now returns `normal_z` directly so the preview uses the same
effective slope threshold as the support generator.
As a result, the overhang highlight in Preview now correctly matches the
supports that will actually be generated.
* Apply Copilot suggestions
Address SoftFever review item 1 on #13752: CFS sync now lives in
CrealityPrintAgent::fetch_filament_info, matching the MoonrakerPrinterAgent
/ QidiPrinterAgent / SnapmakerPrinterAgent shape. The standard
Sidebar::sync_ams_list
-> DeviceManager::get_selected_machine()
-> Sidebar::load_ams_list(obj)
-> Sidebar::build_filament_ams_list(obj)
-> agent->fetch_filament_info(dev_id)
-> build_ams_payload(box_count, max_lane_index, trays)
path now applies to CrealityPrint hosts identically to the other
Klipper-flavoured agents. CrealityPrintAgent inherits
MoonrakerPrinterAgent, so the inherited connect_printer() ->
announce_printhost_device() -> SSDP callback already triggers
MachineObject creation in DeviceManager's localMachineList for
K-series LAN hosts; the Plater-side special case was simply bypassing
get_selected_machine() before it could fire.
Removed:
* The if (host_type == htCrealityPrint) block in
Sidebar::sync_ams_list (and the CrealityPrintAgent.hpp include it
required).
* The static CrealityPrintAgent::sync_filaments_into_ams_list()
helper that wrote directly to PresetBundle::filament_ams_list,
plus the CFSAmsListResult status struct that surfaced dialog text
back to the Sidebar.
CrealityPrintAgent::fetch_filament_info itself is unchanged - it was
already calling the inherited build_ams_payload() correctly.
Net diff: 227 deletions / 4 insertions across 3 files. No behaviour
change. Discovery + WS protocol parsing unchanged.
Ignore SIGPIPE at startup to prevent crash on dropped printer connection
Writing to a closed printer network socket raised SIGPIPE, whose default
action terminated the whole process (exit 141, no crash report). Set
SIGPIPE to SIG_IGN once at main() entry (POSIX only) so such writes return
EPIPE to the existing networking error handling instead of killing the app.
Fixes#13787
After pulling the latest presets from the cloud, changed values such as Layer height kept showing the old value until the user switched tabs. Refresh the active settings tab on sync so updates appear immediately.
The Emboss text-cut workflow can crash with SIGBUS at a stack-guard page
on macOS (and equivalent on Linux) when CGAL's
Polygon_mesh_processing::corefine falls back from filtered interval
arithmetic (Epick) to exact rational arithmetic (Epeck / mpq_class).
On near-degenerate inputs -- coplanar triangles in the projection
footprint, very thin font stems, sharp edges or seams under the text --
CGAL's Filtered_predicate_with_state cascade ends up inside
Triangulation_2<Projection_traits_3<Epeck>>::march_locate_2D, whose
recursive walk plus mpq_class arithmetic frames overflows the worker's
4MB default stack. The fault address sits exactly inside the next
thread's guard page, which is the textbook macOS signature.
Crash trace (BambuStudio v02.07.00.55, macOS 26.4.1 arm64, embossing
text into a model):
__gmpn_mul_1
__gmpz_mul / __gmpq_mul
CGAL::determinant<mpq_class>
Projected_orientation_with_normal_3
Filtered_predicate_with_state::operator()
Triangulation_2<...>::orientation
Triangulation_2<...>::march_locate_2D
Surface_intersection_visitor::triangulate_intersected_faces
Polygon_mesh_processing::corefine
Slic3r::cut_surface
Emboss::cut_surface_to_its
Emboss::GenerateTextJob::get_text_mesh
PlaterWorker::PlaterJob::process
The thread's stack region in the report was exactly 4128K -- the
default 4MB plus a small TLS overhead -- and the faulting address hit
the adjacent guard page. We have one observed reproducer; the 16 MB
value is chosen as 4x defensive headroom over that, not as a measured
upper bound. Future heavier emboss inputs may need more.
Cumulative cost on a 64-bit target. Slic3r::create_thread has 22
callsites across the codebase. Realistic peak concurrent live count is
on the order of 10-15 workers (Plater UI worker, slicing process, FDM-
support gizmo, STEP loader, network sync helpers, per-task sender
threads in TaskManager up to MaxSendingAtSameTime, per-machine info
threads in device-list dialogs, long-lived sync helpers in GUI_App).
At 16 MB reserve x ~15 = ~240 MB of address-space commitment in the
worst case, which is bounded on any 64-bit target.
Resident memory remains proportional to actual stack depth on all three
platforms: macOS / Linux mmap the thread stack and defer-commit pages on
touch, and Boost.Thread on Win32 passes STACK_SIZE_PARAM_IS_A_RESERVATION
to _beginthreadex (verified at libs/thread/src/win32/thread.cpp), so on
Windows the bumped value is the reserve, not the initial commit.
The 32-bit branch of the previous (sizeof(void*) == 4) ternary is
removed: BambuStudio doesn't ship a 32-bit build today, and the literal
makes the value easier to read at the callsite.
(cherry picked from commit e150b502b3d2afc98b83dcc9e5720e998f9eb79a)
Co-authored-by: Abdel Gomez-Perez <nabdel07@icloud.com>
* feat(viewer): Display travel distance and move count in G-code summary
This commit introduces a new feature that enhances the G-code viewer by displaying the total travel distance and the total number of travel moves in the 'Line Type' summary.
This provides users with more detailed statistics about their prints, helping them to better understand the printer's behavior and identify opportunities to optimize travel moves for faster print times.
This commit also fixes a critical bug in the G-code processor where the travel distance was being calculated incorrectly. The distance variable was not being updated for non-extruding travel moves, leading to inaccurate statistics. The calculation has been corrected to ensure it is performed for all relevant move types, resulting in accurate travel distance reporting.
* Subfix segments
kilo mega giga tera peta exa
* Add missing values
* Grams to Kilos and tons
* add distance
* Fix tool view
* Record and display seam distances
Track seam-related distances in print statistics and show them in the GCode viewer. Added total_seam_gap_distance and total_seam_scarf_distance to PrintEstimatedStatistics (with initialization). In GCode::extrude_loop the code now computes seam gap and scarf distances and accumulates them for external perimeters. GCodeViewer uses the summed seam distance when the Seams option is selected in the legend.
* Fix travel / wipe distances
* Update GCode.cpp
* Filament changes estimated time
---------
Co-authored-by: Steve Scargall <37674041+sscargal@users.noreply.github.com>
Handle user_ticket_login
Legacy Bambu network plugins completed embedded login with
user_login, which the WebView dialog already handled.
Newer Bambu login flows can complete with user_ticket_login and
return only a short-lived ticket. The external browser path already
worked because the local HTTP callback server exchanges that ticket
for tokens, fetches the user profile, and passes the resulting session
payload to change_user.
Mirror that ticket exchange path for embedded WebView login so the
dialog can handle user_ticket_login instead of silently ignoring it
after verification-code submission.
2026-05-21 13:44:17 +08:00
Aleksandr Dobkinimg src=404 onerror=alert(document.domain)
fix: OK/Cancel buttons clipped in Flushing Volume dialog (#13511)
The WipingDialog renders its UI inside a wxWebView. When the dialog
was clamped to screen size (many filaments, small displays, high DPI),
the HTML content exceeded the WebView bounds and the OK/Cancel buttons
fell below the visible area.
HTML fix:
- Convert .container to flexbox column with overflow-y: auto
- Pin .button-container with flex-shrink: 0 so it stays visible
- Allow .scroll-container to flex-grow for the table area
C++ fix:
- Replace heuristic extra_size with accurate fixed_overhead estimate
- Use correct cell height (25 DIP) matching HTML table row height
- Add screen margin for window decorations
- Enforce minimum dialog size when clamped
Co-authored-by: SoftFever <softfeverever@gmail.com>
