Bot releases are hidden (Show)
This is first release candidate of PrusaSlicer 2.8.1, which mostly fixes bugs found in 2.8.0.
Filaments->Advanced->Abrasive material
and Printers->Extruder->High flow nozzle
. Both flags will be used to check whether a sliced G-code is compatible with the given printer (abrasive material requires hardened nozzle) and also to ensure that "Set as current" function in PrusaSlicer-embedded Prusa Connect will select the suitable profile for the given configuration.--query-printer-models
command line option was extended to contain bed shape and dimensions. Note that custom bed shapes are currently not supported.M106
G-codes when dynamic fan speed on overhangs is enabled. Too many commands were generated even when the fan speed barely changed or did not change at all. #11981, #11856PrusaSlicer now depends on WebKit library, which greatly complicates its distribution. Latest Linux distributions (such as Ubuntu 24.04, Fedora 40) ship with newer version of WebKit than older (but still supported) distros. Bundling WebKit into the AppImage is difficult and may not be possible.
Therefore, we now provide two separate AppImages, both depending on webkit library. You may need to install the respective package before you are able to run PrusaSlicer.
Build | min libwebkit2gtk version | distributions examples |
---|---|---|
older-distros | 4.0 | Ubuntu 22.04, Fedora 39, Debian 11 |
modern-distros | 4.1 | Ubuntu 24.04, Fedora 40, Debian 12 |
The AppImages can extract themselves when run with --appimage-extract
command line parameter.
It is quite likely that PrusaSlicer will switch only to Flatpak deployment from the next version on. The AppImage made sense when it could be used in the "bundle what you need, distribute a single file" way, but having to distribute several different AppImages and maintaining the required build infrastructure (and still worrying about what needs to be updated when some Linux distribution update is released) means burning time that we would much rather invest into actual work on PrusaSlicer.
Published by lukasmatena 4 months ago
This is final release of PrusaSlicer 2.8.0, introducing Prusa Connect integration, seam improvements, updated UI, new G-code Viewer, improved profile updating system and many more improvements and bugfixes. The final release fixes a single bug found in 2.8.0-rc2. See the release logs of 2.7.5-rc1, 2.8.0-alpha5, 2.8.0-beta1, 2.8.0-rc1 and 2.8.0-rc2 for the complete list of changes with respect to 2.7.4.
PrusaSlicer now depends on WebKit library, which greatly complicates its distribution. Latest Linux distributions (such as Ubuntu 24.04, Fedora 40) ship with newer version of WebKit than older (but still supported) distros. Bundling WebKit into the AppImage is difficult because it leads to various issues with its dependencies. So far we did not manage to create an AppImage that would reliably run on all relevant distros.
We now provide two separate AppImages. One depends on the old WebKit, the other one is built on Ubuntu 24.04 and links to the new WebKit. If you run Ubuntu 24.04, Fedora 40 or another very recent distribution, you should download the "Ubuntu-24-04" AppImage. The other one will not work for you.
To keep the confusion to a minumum, we do not provide the tarballs anymore, just the two AppImages. They are able to extract themselves when run with --appimage-extract
command line parameter.
Published by lukasmatena 4 months ago
This is the second release candidate of PrusaSlicer 2.8.0. This release candidate fixes several bugs found in previous 2.8.0-rc1.
The release candidate saves its profiles into regular PrusaSlicer configuration directory. When you first run it, it will search for all configurations produced by alpha or beta versions and offer to create a copy of the latest one.
An AppImage running on Ubuntu 24.04 is finally provided (unlike previous releases). The problem was that PrusaSlicer now depends on WebKit library, which is a big library with many dependencies. The new Ubuntu 24.04 uses new version of WebKit which is incompatible with our binaries. Bundling WebKit into the AppImage has proved to be difficult, because there it has many dependencies and it leads to many other issues.
Therefore, instead of bundling all the libraries into a single huge AppImage, we provide two separate AppImages. One depends on the old WebKit (which is currently shipped with almost all Linux distributions), the other one is built on Ubuntu 24.04 a links to the new WebKit.
To keep the confusion to a minumum, we do not provide the tarballs anymore, just the two AppImages. They are able to extract themselves when run with --appimage-extract
command line parameter.
Published by lukasmatena 4 months ago
This is the first release candidate of PrusaSlicer 2.8.0. This release candidate fixes bugs found in previous 2.8.0-beta1.
The release candidate saves its profiles into regular PrusaSlicer configuration directory. When you first run it, it will search for all configurations produced by alpha or beta versions and offer to create a copy of the latest one.
An important note for Linux users: The provided binaries will not run on newest Ubuntu 24.04 (and possibly other latest distributions). Solving problems with all dependencies is more work than originally expected. We hope to get it sorted for the 2.8.0 final release.
Published by lukasmatena 4 months ago
This is the first public beta release of PrusaSlicer 2.8.0. This release introduces Prusa Connect integration and many more improvements and bugfixes.
To let you enjoy the beta without worries, the beta builds save their profiles into PrusaSlicer-beta directory, so you may use the beta side by side with the current release without ruining your production configuration. The beta will ask whether it should import a configuration from previously run PrusaSlicer versions on the first start.
An important note for Linux users: As with the 2.8.0-alpha5, the provided binaries will not run on newest Ubuntu 24.04 (and possibly other latest distributions). Solving problems with all dependencies is more work than originally expected, and we do not want to postpone releasing the beta because of it.
After the feedback received from 2.8.0-alpha5 testing, further changes to the vertical slider were made:
We would like to thank for the feedback we got and we hope that these improvements address most of the issues that were reported.
Print speed limitation for infill was added into Filament Settings -> Advanced
. Two separate values can be entered - one for infill islands with intersection, one for islands without. The reason for this change is that intersections in the same layer cannot be printed properly at speed, because the molten filament tears at the intersections. This effect is especially noticeable with some materials, the most important example being PET. Until now, the only way to slow the print down in Filament Settings was to use Max volumetric speed
, which in effect slowed down the whole print. By distinguishing between crossing and non-crossing infill, it is now possible to increase the general volumetric speed limit and increase overall speed as a result.
The login into Prusa Account is no longer done in external browser window. Instead, the dialog shows directly in PrusaSlicer to streamline the workflow, and the user is thus not forced to switch between PrusaSlicer and the browser. Note that the login website will be improved in near future to blend in with the application more naturally. It should also help to solve issues such as #12853.
In addition to that, the login dialog now shows in Configuration Wizard as well, because logging is part of configuring the slicer to use. The login is of course still completely optional and can be skipped.
Login button in the top right corner can now be hidden, so people not interested in using Prusa Account are not bothered by it. There is an option in Preferences to do that, and before you log in for the first time, this option is also in the Log in menu to make it easily discoverable.
Speed and volumetric flow rate were added to the info dialog at the horizontal slider in the G-code Viewer (#12840).
Published by lukasmatena 4 months ago
This is the first public alpha release of PrusaSlicer 2.8.0 (previous alphas were internal). This release introduces Prusa Connect integration 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.
An important note for Linux users: The binaries will not run on newest Ubuntu 24.04 (and possibly other latest distributions). This problem will be solved shortly in the next alpha/beta.
Prusa Connect is our online system to control printers from the browser and distribute print jobs among them. Starting with this release, Prusa Connect is accessible directly from PrusaSlicer to streamline the workflow. A login box was added to the right of the top bar, which will open a browser window and let you log in with your Prusa Account credentials. When the login is successful, one more tab (Prusa Connect) will appear in the top bar. This tab will present your Prusa Connect dashboard and all features that you are used to.
When logged in, PrusaSlicer keeps track of the status of your printers and it also knows with which of your printer profiles they are compatible (printer model, MMU capabilities and nozzle diameter are checked). When a printer compatible with a given printer profile is in Prusa Connect, a little colored dots will appear in the printer profile dropdown in the right panel, displaying current status of that printer. The summary of the state of connected printers is shown just below the dropdown.
When ready to export G-code, a 'Send to Connect' button appears in the right panel. Clicking this button will open a dialog window presenting all your Connect printers compatible with the current project and allowing you to send the generated G-code to one of them:
To streamline the workflow in the other direction, there is an extra button in Connect labeled "Set as current", which is shown for every printer. Clicking it will switch back to Plater tab and select first compatible printer profile automatically. The language settings and light/dark mode in the Prusa Connect tab is automatically switched so they match what is currently selected in PrusaSlicer.
Previous way of sending G-codes to Prusa Connect using a physical printer profile is deprecated. Users should stop using physical printers for Prusa Connect, although the support will be maintained for some time. Nothing changes with regard to PrusaLink or the other print hosts.
Note that logging in or using Prusa Connect is completely optional. PrusaSlicer will work fine without the login, as it has worked before. We are considering to add a Preferences checkbox to hide the login box completely to not bother people who intend to never use it anyway. Your feedback is welcome.
We have decided to do several tweaks to the user interface. It is by no means a complete redesign, so the controls are mostly where you are used to find them. The most visible change is the top bar. The system menu was removed (on Windows and Linux only) and it is now accessible through a separate button at the very left of the top bar. The settings tabs are now larger and styled. The larger top bar allowed us to integrate the Search field into it, so it is readily accessible and it looks the same regardless of which tab is active (unlike in previous versions). The right part of the top bar features the Simple/Advanced/Expert switch (which is newly a dropdown) and the PrusaAccount login box.
Next, both sliders in the Preview have been completely reworked and are now part of the 3D scene, instead of being placed in a neighboring panels. Apart from looking nicer and more modern, removing the side panels means that the canvas size is larger. It also comes with a nice benefit that switching back and forth between the 3D view and Preview no longer shifts the view, so the transition is more comfortable.
Credits go to BambuStudio, whose sliders were used a starting point for the implementation (although we later ended up rewriting most of it to fit current PrusaSlicer architecture).
Topping the list of the UI improvements, the spacing and icon size in the toolbars in the scene was slightly changed. The toolbars are now nicer and look less cramped.
The integrated G-code Viewer has been significantly reworked to improve its performance. Less data are now transmitted between the CPU and GPU and more of the work is now performed on the GPU side.
Furthermore, G-code Viewer is now able to visualize actual speed. The printer accelerates and decelerates when direction changes, so even though the required speed is set to a given value, it takes some time to reach it (if it is reached at all). The acceleration limits are (as they always were) configurable in Printer Settings -> Machine limits
and PrusaSlicer always calculated with the acceleration and deceleration phases to get precise time estimate, but it did not allow to visualize them.
Note that the same disclaimers as for precise time estimates hold. If the machine limits are set incorrectly (in the sense that the printer uses different values), both the time estimate and the real speed visualization will not align with reality. Also, the actual speed visualization is not available for firmware flavors for which slicer does not allow setting the machine limits.
In addition, when moving the horizontal slider, there is a new popup dialog showing the data that G-code Viewer has about current segment, including the actual speed profile:
We have ported an option to use single perimeter for (top) solid infill layer. The feature can be configured in Print Settings -> Only one perimeter
and based on the configuration, it results in single perimeter on all solid infill layers, on top solid infill layers or on topmost solid infill layers. This generally leads to improved visual look of the printed object, without sacrificing structural rigidity.
This is a frequently requested feature, which was first implemented in SuperSlicer, ported over to OrcaSlicer and then reimplemented in BambuStudio. We have ported the code from BambuStudio with only small changes. Even though we ended up not using the original SuperSlicer implementation, we would like to thank to everyone who implemented the feature there and who worked on a PR with the port (#10648), namely @supermerill, @vovodroid, @mjonuschar. Thanks also go to @BambuLab for rewriting the feature later.
Related to #7986, #9854, #10346, #10868, #11654, #11965, #12263.
Since Slic3rPE 1.40 (released six years ago), PrusaSlicer has a built-in profile updater. Its task is to deliver read-only "system" profiles, which are fine tuned for the given printer and filament, sparing the user from having to tweak the individual parameters. The database of profiles has been growing ever since, and it contains many profiles, both for Prusa products and products from other vendors.
We have now split the profile database into several profile "repositories". Profiles are updated only from repositories that PrusaSlicer is subscribed to. The repositories are selected at the beginning of the Configuration Wizard. The transition of your previous configuration requires no action on the user's side, the repositories are automatically selected based on your currently installed profiles.
This change is motivated by several internal reasons, but it also brings the following benefits:
We have also covered the problem of updating system profiles on computers without internet connection. Not connecting a computer to the internet is an obvious security measure in environments where data leaks would pose a problem (which is in most contexts, maybe apart from casual hobby printing). However, the profile updater in PrusaSlicer relied on internet connection and there was no way of updating the profiles on such off-the-grid stations. They had to rely on undocumented and very user-unfriendly copying of configuration folders, transferring settings as config bundles, etc.
It is now possible to download a file containing the configuration update for a given repository from our website (note that the URL and the website are also in an alpha stage). This file can then be loaded as an "Offline repository", and the configuration process treats is the same way as it would use an online update. This gives the user a possibility to update profiles by transferring this file to the off-the-grid computer on a removable drive, distribute it using a local network storage, etc.
These files can be loaded (and removed) also in the Configuration Wizard. PrusaSlicer remembers path to the loaded files and it tries to use them anytime when configuration update is triggered.
Placement of seams is not a very well defined task, and it has many solutions. After the last big batch of changes in the seam placing algorithm (in 2.5.0-alpha2), the placing of seams was detrimental on various models.
In this release, the seam-placing algorithm was significantly changed to improve the results. We also did some other changes which allow the seam placing algorithm to do a better job. To name the most visible improvements:
The changes are related to issues #12759, #11433, #11190, #9649, #8867, #8512, #8443, #8107, #6346, #2761, #11914 and fix most of them.
M141/M191
G-codes). There are two new parameters in Filament Settings: minimal and nominal chamber temperature. The nominal temperature is the temperature of the heated chamber, minimal temperature is the temperature which has to be reached before the print starts. Setting minimal temperature to a lower value than nominal allows to start the print while the chamber is still heating up. In case of multi-extruder printer, the setting for the first filament is applied.Filament Settings -> Advanced -> Shrinkage compensation
, one for compensation in XY plane, the other for Z. The values define relative compensation values (percents). When using multiple filaments with different compensation values in one print, the compensation is not applied and the user is notified about it. The feature is independent on the already existing XY compensation in Print Settings, which is absolute and does a geometric offset instead of relative scaling of the geometry.Prefer clockwise movements
in Printer Settings. Enabling this option reverses direction of perimeters, tree supports structures etc.--query-printer-models # prints a JSON containing list of currently installed printer profiles
--query-printer-models --printer-technology SLA # The same, but filters SLA printers (FFF is also possible)
--query-print-filament-profiles --printer-profile "name" # prints JSON with a list of filament profiles compatible with a given printer profile
--print-profile --material-profile --printer-profile # Used when slicing. Loads configuration from the given profile.
With multi-material prints, you can provide multiple filament profiles to the --material-profile
parameter by separating them with a semicolon. All of the parameters are compatible with the --datadir
parameter which can be used to set custom configuration folder.
Starting with this release, only GTK3 Linux builds are provided. We no longer support GTK2. It is outdated and not shipped with Linux distros for a long time, so dropping the support should not prevent anyone from using the software. Supporting two different versions of the toolkit is tedious and it is time to move on.
Published by lukasmatena 4 months ago
This is the first release candidate of PrusaSlicer 2.7.5. This release adds support for new features introduced with firmware version 1.8.0 for Prusa SLA printers.
Note that this release candidate uses the same configuration folder as the regular releases.
In previous versions of SL1/SL1S firmware, the layer separation configuration mostly consisted of selecting a 'Material printing profile' from three predefined options (Slow / Fast / High viscosity). Based on the selection, the printer would use an internally defined set of parameters to perform the layer separation. To make it possible to fine-tune the layer separation procedure for each material, new 1.8.0-beta.0 firmware for the SL1/SL1S printers allows more detailed control over the parameters of the separation. You can read more about this change in Prusa SLA FW 1.8.0-beta.0 change log.
To keep up with these changes, PrusaSlicer 2.7.5 changes the way how the separation is configured: the 'Material printing profile' selector is no longer shown and many new parameters are now accessible in Material Settings -> Material printing profile
. Note that this change is only applied for Prusa SL1 and SL1S. With all the other printers, everything stays as it was in 2.7.4.
Old projects using the 'Material printing profile' selection are automatically converted when loaded, and the values for all the parameters are set to match the legacy profile selected in the project. On the other hand, opening a 3MF project from 2.7.5 or higher in an older version of PrusaSlicer will silently ignore the new parameters and the value of 'Material printing profile' (which is retained internally and kept in our system profiles) will be used instead.
Published by lukasmatena 7 months ago
This is stable release of PrusaSlicer 2.7.4. This release improves loading of 3MFs generated by BambuStudio and fixes a single bug found in 2.7.3.
Published by lukasmatena 7 months ago
This is stable release of PrusaSlicer 2.7.3. This release is functionally equivalent to 2.7.3-rc1. Please, read the change logs of 2.7.3-alpha1, 2.7.3-beta1 and 2.7.3-rc1 for the complete list of bugfixes and improvements over 2.7.2.
If any of the PrusaSlicer 2.7.3 alphas or betas was used before on the same machine, PrusaSlicer 2.7.3 will offer to import such alpha or beta configuration when it is first executed.
Published by lukasmatena 7 months ago
This is the first release candidate of PrusaSlicer 2.7.3, which fixes a single bug found in the previous beta. Please, read the change logs of 2.7.3-alpha1 and 2.7.3-beta1 for the complete list of bugfixes and improvements over 2.7.2.
The release candidate saves its profiles into regular PrusaSlicer configuration directory. When you first run it, it will search for all configurations produced by alpha or beta versions and offer to create a copy of the latest one.
Published by lukasmatena 7 months ago
This is the first beta release of PrusaSlicer 2.7.2, which fixes bugs found in the previous alpha. Please, read the change log of 2.7.3-alpha1 for the complete list of bugfixes and improvements over 2.7.2.
To let you enjoy the beta without worries, the beta builds save their profiles into PrusaSlicer-beta directory, so you may use the beta side by side with the current release without ruining your production configuration. The beta will ask whether it should import a configuration from previously run PrusaSlicer versions on the first start.
Published by lukasmatena 7 months ago
This is the first public alpha release of PrusaSlicer 2.7.3. This release introduces improvements of multi-material printing, improvements of spiral vase mode and several important 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.
For a long time, a community-developed feature exists which claims to improve filament tips during toolchange sequences, which would in turn increase reliability of devices depending on reasonable tip shape (such as Prusa MMU1 and MMU2). This feature is referred to as "skinnydip", and the basic principle is to push the filament back into the melt zone after it was unloaded to melt off the thin string that the filament often has. We at Prusa Research have tested the feature several times, but the results were not very convincing and we never integrated the feature into PrusaSlicer. After doing more experiments recently, we found out that the technique is more convincing when preceded by very rapid ramming.
Based on that knowledge, we decided to implement very similar approach for reshaping the filament tip. Because the goal is to reshape the filament tip using the mostly empty nozzle, instead of melting off the thin filament tip, we call our approach "stamping". There are two new parameters in Filament Settings (filament_stamping_distance
and filament_stamping_loading_speed
) which control how far and how fast should the filament be pushed after the initial unload. The stamping moves are coupled with cooling - the stamping moves are performed between the individual cooling moves.
We would like to highlight community projects that helped us develop our Stamping step and saved our developers and testers a significant amount of time – Skinny Dip post processing script by Erik Bjorgan and Dribbling by Antimix. While we ended up with a different approach, we would like to thank both authors for all the effort invested into the project and for making it open-source! (Related to #2385, #2452, #2729, mentioning @domesticatedviking and @antimix.)
PrusaSlicer allows to set purging volumes for single-extruder multi-material printers, so that each filament is purged exactly as it needs to. However, these settings were only saved in the 3MF project, not in configuration. This made setting them quite cumbersome and the user would always need to think about adjusting the default values. On the other hand, setting the values only in configuration without the option to override it in the project is also inadequate, because one may care about purging more in one project and less in another. In addition, the configuration option would make sense both in Filament and Printer Settings. #1273, #1282, #2990, #3756
In this release, two additional configuration options were added. The volume to purge is set using multimaterial_purging
in Printer Settings->Single extruder MM setup. This value can be further modified on filament level using filament_purge_multiplier
in Filament Settings->Advanced.
As for the project-specific override, the "Purging volumes" dialog now contains a switch. You can either use the values from Filament and Printer profiles (as described above) or define your own matrix of purging volumes (like in previous PrusaSlicer versions). When you decide to do that, the values from the configuration are not used.
When using spiral vase mode, the toolpaths are generated as usual and the resulting extrusions are then extruded while gradually increasing z. This approach led to seam-like artifacts on the print in places where the layer transitions would normally be (#4116, #2841). In addition, the last layer would end abruptly, creating a sharp "edge" where the extrusion ends.
Both these issues were addressed by @andrewboktor by interpolating between adjacent layers and by gradually reducing extrusion flow at the very end of the print. The improvement was recently merged into OrcaSlicer (https://github.com/SoftFever/OrcaSlicer/pull/3091), and we got a pull request with a port to PrusaSlicer. After we evaluated the feature, we decided to merge it because it is well written, well working and very useful.
Thanks to @andrewboktor for the time and effort invested into the issue, and to both @vovodroid and @tg73 for providing a pull request with a port from OrcaSlicer (#12079, #12142).
objects_info
, which lists all the objects in the print and their boundary polygons. The same info was added into the comments at the end of ASCII G-codes.G2
and G3
G-codes) were enabled, PrusaSlicer generated toolpaths outside the print area in certain cases (#12381).Published by lukasmatena 8 months ago
This is the stable release of PrusaSlicer 2.7.2, fixing one bug found in the previous release candidate. Please, read the change logs of 2.7.2-alpha2, 2.7.2-beta1, 2.7.2-rc1 and 2.7.2-rc2 for the complete list of bugfixes and improvements over 2.7.1.
If any of the PrusaSlicer 2.7.2 alphas or betas was used before on the same machine, PrusaSlicer 2.7.2 will offer to import such alpha or beta configuration when it is first executed.
Published by lukasmatena 8 months ago
This is the second release candidate of PrusaSlicer 2.7.2, which fixes bugs found in the previous release candidate. Please, read the change logs of 2.7.2-alpha2, 2.7.2-beta1 and 2.7.2-rc1 for the complete list of bugfixes and improvements over 2.7.1.
The release candidate saves its profiles into regular PrusaSlicer configuration directory. When you first run it, it will search for all configurations produced by alpha or beta versions and offer to create a copy of the latest one.
Published by lukasmatena 8 months ago
This is the first release candidate of PrusaSlicer 2.7.2, which fixes a single bug found in the previous beta. Please, read the change logs of 2.7.2-alpha2 and 2.7.2-beta1 for the complete list of bugfixes and improvements over 2.7.1.
The release candidate saves its profiles into regular PrusaSlicer configuration directory. When you first run it, it will search for all configurations produced by alpha or beta versions and offer to create a copy of the latest one.
Published by lukasmatena 8 months ago
This is the first beta release of PrusaSlicer 2.7.2, which fixes bugs found in the previous alpha. Please, read the change log of 2.7.2-alpha2 for the complete list of bugfixes and improvements over 2.7.1.
To let you enjoy the beta without worries, the beta builds save their profiles into PrusaSlicer-beta directory, so you may use the beta side by side with the current release without ruining your production configuration. The beta will ask whether it should import a configuration from previously run PrusaSlicer versions on the first start.
Published by lukasmatena 8 months ago
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.
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 (https://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 (https://github.com/prusa3d/PrusaSlicer/issues/11774) with spilled layers for multi-material segmentation.
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 (https://github.com/prusa3d/PrusaSlicer/issues/2672).
Our community, especially @Nohus, came up with a solution (https://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.
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 (https://github.com/prusa3d/PrusaSlicer/issues/11516, https://github.com/prusa3d/PrusaSlicer/issues/11517, https://github.com/prusa3d/PrusaSlicer/issues/11600, https://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).
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.
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 (https://github.com/prusa3d/PrusaSlicer/issues/11940, https://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.
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.
Under the right circumstances this issue can be mitigated on Marlin-based printers by smoothing the ramping travel moves. PrusaSlicer now automatically employs this slight optimization when applicable. This further helps to prevent stringing and may even slightly improve print times by a very small amount.
During long travels above already printed parts of models, ooze material may be so long that it can be wiped on the perimeters of other objects. Increasing the Z-hop distance could reduce this issue, but it also increases the print time when it isn't needed to do such a big Z-hope.
We implemented the lift before obstacles feature that ensures that during crossing already printed objects or parts the nozzle will be at chosen distance to not wipe oozed material on perimeters of that object.
PrusaSlicer classifies the SLA parameters into three groups: Print, Material and Printer parameters. This parameter classification is certainly artificial and not flexible enough. We are now introducing a concept of Material Overrides in SLA, which is mimicking the Filament Overrides feature known from FDM slicing (introduced in 2.1.0). It allows to override selected configuration options from Print or Printer Settings in Material Settings. There is a new parameter page in Material Settings, which allows to check the parameters which would be overridden and to redefine their value.
extruded_volume
, extruded_volume_total
, extruded_weight
and extruded_weight_total
(introduced in 2.6.0) did not include the volume / weight of the wipe tower. This is now fixed.PrusaSlicer is based on Slic3r project, which was originally written in Perl scripting language. Over the years, various parts were rewritten into C++, first the slicing core, then the user interface. We have now completed the transition by rewriting all remaining unit tests still depending on Perl into C++. Goodbye, Perl. You will not be missed.
Published by lukasmatena 10 months ago
This is the stable release of PrusaSlicer 2.7.1, bringing minor improvements and several bugfixes with respect to 2.7.0.
Export as binary G-code
was removed from Print Settings. Instead, there is a new option in Printer Settings named Supports binary G-code
so it can be set at printer level. There is also a new global switch in Preferences->Other, which controls whether binary G-code will be generated for printers which support it. It is therefore easy to turn the feature on or off without doing any changes in profiles (#11734, #11873).Published by lukasmatena 11 months ago
This is the stable release of PrusaSlicer 2.7.0, introducing SVG emboss, binary G-codes, ramping travels, support for G2/G3
G-codes, support for Cancel object function and much more. It also fixes many bugs. Please, read the change log of 2.7.0-alpha1, 2.7.0-beta1, 2.7.0-rc1 and 2.7.0-rc2 for complete list of changes with respect to 2.6.1.
If any of the PrusaSlicer 2.7.0 alphas or betas was used before on the same machine, PrusaSlicer 2.7.0 will offer to import such alpha or beta configuration when it is first executed.
Published by lukasmatena 11 months ago
This is the second release candidate of PrusaSlicer 2.7.0. It fixes several bugs found in the 2.7.0-rc1. Read the change log of 2.7.0-alpha1, 2.7.0-beta1 and 2.7.0-rc1 for complete list of changes with respect to 2.6.1.
The release candidate saves its profiles into regular PrusaSlicer configuration directory. When you first run it, it will search for all configurations produced by alpha or beta versions and offer to create a copy of the latest one.