PrusaSlicer 2.7.2-alpha2

PrusaSlicer

Summary

This is the first public alpha release of PrusaSlicer 2.7.2 (alpha1 was not public). This release introduces improvements of multi-material segmentation algorithm, improved M600 G-code handling, SLA overrides and many more improvements and bugfixes.

To let you enjoy the alpha without worries, the alpha builds save their profiles into PrusaSlicer-alpha directory, so you may use the alpha side by side with the current release without ruining your production configuration. The alpha will ask whether it should import a configuration from previously run PrusaSlicer versions on the first start.

Multi-material segmentation improvements

In PrusaSlicer, we use Voronoi diagrams as part of several features such as Arachne, multi-material segmentation, gap-fill, and thin-walls. We use the Voronoi diagram implementation from the Boost library ↗ because it is both fast and numerically stable. Unfortunately, it rarely produces a non-valid Voronoi diagram for some input polygons (the graph is not planar, missing vertices, etc.), which could cause a crash of PrusaSlicer, artifacts on external perimeters with Arachne or spilled layers with multi-material segmentation.

In 2.5.0 ↗, we implemented several mechanisms to detect a non-valid Voronoi diagram, and by manipulating the input, we could ensure that the Voronoi diagram would be valid. These mechanisms were originally implemented only for Arachne, and they were heavily tight with Arachne's data structures.

In this release, we have generalized these mechanisms to be used anywhere in PrusaSlicer. This itself solved many of the spilled layer issues with multi-material segmentation and also one crash during thin-wall generation (github.com/prusa3d/PrusaSlicer/issues/10632). ↗

We also reimplemented a significant part of multi-material segmentation from scratch, which, together with the changes above, should resolve all issues (github.com/prusa3d/PrusaSlicer/issues/11774) ↗ with spilled layers for multi-material segmentation.

voronoi

Color change (M600) improvements

Place the color change (M600) after moving to the next layer and position

Previously, PrusaSlicer placed the color change (M600) right after the previous layer was finished. The default implementation of M600 in all firmware will return to the position before M600. As a result of this behavior, the extruder with changed filament returns to the place that was printed with a previous filament and could create a blob with new material at that position (github.com/prusa3d/PrusaSlicer/issues/2672). ↗

Our community, especially @Nohus, came up with a solution (github.com/prusa3d/PrusaSlicer/pull/9036) ↗ of placing the color change after moving to the next layer and position, which proved to be much easier and more universal solution than changing the M600 implementation on the firmware side. Thank you, Nohus, for your implementation and all of you who participated in testing his PR.

Selecting the correct tool before performing a color change (M600) on multi-tool printers

Previous implementations of color change for multi-tool printers left picking the right tool on the firmware and user. Also, M601 (pause print) was placed instead of M600 (color change), which is how it was intentionally implemented for MMU. That case issue especial on our Prusa XL printers (github.com/prusa3d/PrusaSlicer/issues/11516, ↗ github.com/prusa3d/PrusaSlicer/issues/11517, ↗ github.com/prusa3d/PrusaSlicer/issues/11600, ↗ github.com/prusa3d/PrusaSlicer/issues/11792). ↗

This proved to be insufficient for multi-tool printers, mainly because there is a special sequence of extruder movements that need to be done before parking the tool, and PrusaSlicer depends on it.

Based on this, we implemented picking the tool on which the color change will be performed. After the color change, it picks the previous tool (if the tool for which the color change was performed no longer prints on that layer). Along with this, we are now emitting the M600 (color change) for multi-tool printers instead of the M601 (pause print).

Ramping travel improvements over PrusaSlicer 2.7.1

In PrusaSlicer 2.7.1 we introduced ramping travels together with helical layer changes that both should mitigate stringing and oozing especially on long travels between objects. In this release we continue improving the ramping travels.

Replace helical layer changes with proper ramping travels

Based on user feedback, it turned out that helical layer changes weren't good enough and sometimes even caused visible blobs or artifacts on external perimeters of prints (github.com/prusa3d/PrusaSlicer/issues/11940, ↗ github.com/prusa3d/PrusaSlicer/issues/11800). ↗

We thus decided to replace the helical layer changes with the ramping profile previously only used for travels. This change ensures that the stringing is still mitigated without the disadvantages of the helical movements.

Smoothing of ramping travel moves

During a ramping travel the print head moves in both XY plane and Z. If the travel is sufficiently long, the print head will reach the desired lift before the travel ends. This means that the Z-motor has to decelerate to stop, while the X and Y motors are still moving. Due to the limitations of motion planners in printer firmwares like Marlin and others, this Z-axis deceleration may lead to slight slow down of the movement in the XY plane which is not necessary.