1.When n<10, calc all case cost
2.When n>10, first k-medoids algorithm first
3.Enable setting group size
jira:NEW
Signed-off-by: xun.zhang <xun.zhang@bambulab.com>
Change-Id: I625f47e0235c70e440c6d489b052a156fbffca3f
(cherry picked from commit 9ec276d3d7114fff7a33213c3b47ce88df85f2ee)
1. backend support multi_extrude data structure
2. Compatible with third-party calibration
3. fix bug when get extruder in gocde export process
Change-Id: I5dac9abdd9907a521a1ba9b480f9e05640591bc1
(cherry picked from commit 21e6271e59ea8e4924866275566617d14a4b2b6e)
1. support recommended filament map when print by object
2. placeholder_parser support function filament_change
3. extruder_id of filament_map is start from 1
Change-Id: Ide8019cd4a165a25972f22706ff685c3005aa031
(cherry picked from commit b42d94e1d05236b8b7b2e65b4a24810eecf040cb)
* Add new Bambu RIB wall feature, including only the rib wall generation algorithm.
* Fix Linux compilation errors.
* Attempt to fix flatpak build
---------
Co-authored-by: Noisyfox <timemanager.rick@gmail.com>
* Ignore very tiny extrusions in flow rate scale (SoftFever/OrcaSlicer#9190)
* Don't show flow rate if it's not extrusion
* Merge branch 'main' into bugfox/gcode-viewer-flow-scale
* Revert "Fixed an bug that filament_minimal_purge_on_wipe_tower option doesn't work for soluable filament (#8397)"
This reverts commit fcc5489911.
* Fixed an bug that filament_minimal_purge_on_wipe_tower option doesn't work for soluable filament (#8397)
---------
Co-authored-by: SoftFever <softfeverever@gmail.com>
Fix#6839 with final tool preheating on multitool machines causing in appropriate temp settings
Seems like Orca is trying to preheat the next tool in a multitool print, and ends up calling a heater off command in the last 30 seconds of any print.
This happens because there's no handling to check if the next active tool is an actual valid tool index, or its a T-1 command to end the print since we're using the last tool.
Simply moved the preheat commands into the conditional IF that automatically fixes this issue since the tool index is now properly evaluated.
Co-authored-by: SoftFever <softfeverever@gmail.com>
* Junction Deviation Machine Limit
jd 3
JD menu 2
JD operativo
limpieza
final
* default JD print menu without warnings
* to fix multiple instances
* Only at first layer
* Calibs upgrade
* Shown on Marlin2
Shown on Marlin2
CodeCleaning
* Update Calibration.md
* set on writer
---------
Co-authored-by: Ian Bassi <ian.bassi@outlook.com>
According to https://eigen.tuxfamily.org/dox/TopicPitfalls.html one
should just avoid using `auto` as the type of an Eigen expression.
This PR fixes most of them I could found in the project. There might be
cases that I missed, and I might update those later if I noticed.
This should prevent issues like #7741 and hopefully fix some mysterious
crashes happened inside Eigen calls.
and modify the overlap of wall and infill for wipe tower jira:none
cherry picked from commit
bambulab/BambuStudio@4db196b11f
Thanks BambuLab!
- Optimize the starting position of the printing wiper tower after
material change, the initial print on the wipe tower sometimes had
under-extrusion issues, and all layers of wipe tower have the same
starting position, increasing the risk of collision. This optimization
distributes the initial extrusion over four corners, reducing the
accumulation of defects.
- Reducing the rivet length between the wipe tower's outer wall and
infill to 0mm minimizes the risk of collision when switching between
printing infill and outer walls.
and modify the overlap of wall and infill for wipe tower
jira:none
Change-Id: I0d1355c718e2bd1efea6d898f793f5869476ab12
(cherry picked from commit 4db196b11f052d6a7a7c7a8aafe0d2b34a7d2d80)
Add minimum flow ratios for spiral vase transitsions
Currently when starting the spiral vase the extrusion rate is ramped
from 0 to 100% on the first layer and from 100% to 0% on the last layer.
In some cases it can lead to underextrusion at the beginning and end of
the spiral.
This change adds minimum flow ratio options for the beginning and the end
of the vase. This means that instead of ramping from 0% to 100% it
instead ramps from for example 20% to 100%.
This issue has been reported in SuperSlicer
https://github.com/supermerill/SuperSlicer/issues/4195
