Version 2.7.4
5. 4. 2024This is a small patch release:
- Objects from 3MFs generated by BambuStudio now retain multimaterial painting when loaded
- Fixed a bug where downloading files from Printables did not work when enabled in Preferences
This is a small patch release:
This is the stable release, bringing minor improvements and several bugfixes.
We implemented changes to the printing volume settings and new filament tip routines used by the MMU3 on the MK4.
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. 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, 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
PrusaSlicer is now able to open 3MF files generated by BambuStudio and load geometry from them. (#10718, PR #10808, thanks to @cmguo). Please note that BambuStudio allows to save a 3MF containing G-code only, which is not supported by PrusaSlicer and loading of such 3MFs will fail.
Metadata of binary G-code have a new item named 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. This is useful for controlling the Cancel object feature remotely via Prusa Connect.
This is the stable release, bringing minor improvements and several bugfixes.
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. We also reimplemented a significant part of multi-material painting from scratch, which, together with the changes above, should resolve all issues 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 color change in pretty much all firmwares returns the nozzle to the exact same position as before the color change started. As a result of this behavior, a small blob of filament with the newly loaded color would get stuck to the print.
Our community, especially @Nohus, came up with a solution 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 change.
We’ve replaced helical layer changes introduced in 2.7.1 with a more refined ramping profile. While the helical layer changes helped to reduce stringing, they sometimes caused color blobs and artifacts. With the new and refined ramping profile stringing is still mitigated without the disadvantages of the helical movements.
For SLA printing, we’ve introduced Material Overrides. This new feature, mirroring the flexibility of FDM slicing, 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.
PrusaSlicer’s origin is based on the Slic3r project, which was originally written in Pearl scripting language. Over the years, we’ve rewritten nearly all of the code. First the slicing core, then the user interface. We have now rewritten all remaining unit tests still depending on Pearl into C++. Goodbye, Pearl. You will not be missed.
This is the stable release, bringing minor improvements and several bugfixes.
The option 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 now much easier to turn the feature on or off without doing any changes in profiles.
Wipe tower weight was added into G-code metadata so it can be easily displayed in the print statistics on the printer’s display.
Fixed the issue where when ramping travels were enabled, sometimes a perimeter was missing at the layer where the spiral starts.
Fixed a crash when selecting embossed text while an SVG tool is opened.
Fixed a case where helical layer changes could result in out of bed moves.
Fixed a case where helical layer change was enabled even when there was no retraction on layer change.
In addition to the text embossing tool first presented in PrusaSlicer 2.6.0, it is now possible to emboss SVG images onto the models. The feature can be accessed through right button click and it allows similar options for projection and manipulation like the text tool. You can now just drag and drop an SVG logo, title, or even a QR code and merge it with an existing 3D model.
G-code files are easy to read and interpret, but their downside is that the data is not saved efficiently and the file size is often very large. Compression of the file is problematic because the printers usually run on limited hardware and they may not have enough memory and/or CPU power to decompress it. Several solutions to the problem were proposed by members of the community, such as MeatPack encoding (utilizing the fact that the character set of a typical G-code is very limited) or heatshrink compression algorithm (designed to have very small memory requirements).
We are proposing a new standard for a binary G-code format for encoding and compressing ASCII G-code files (see the specification). The format is flexible and the encoding and compression of individual blocks is variable. We also provide libbgcode library which contains the routines to convert ASCII G-codes to binary and vice versa. The library is written in C++ and the repository includes bindings for Python.
Regarding comparison of ASCII vs binary G-code sizes, the result depends on the contents of the G-code. Our testing shows that using binary G-code reduces the size by about 70 % on average. Using arc fitting (described above) at the same time can reduce the size even further. Following chart shows the comparison for 10 randomly selected 3MF projects:
The support for the new .bgcode
file format was implemented in PrusaSlicer, including its export, loading configs, previewing G-code or file associations. Exporting binary G-code can be enabled in Print Settings->Output options->Export as binary G-code
. An option to convert ASCII G-code to binary (or the opposite) has been added into File menu.
To print a binary G-code, it has to be supported by firmware of the printer. For Original Prusa MINI, MK4 and XL printers, this is supported since version 5.1.0-alpha2. It is necessary to update printer firmware before using the binary G-code format.
We would like to thank Scott Vokes (@atomicobject) for his work on heatshrink and
Scott Mudge (@scottmudge) for developing and maintaining MeatPack.