PrusaSlicer 2.3.1-rc is released!
Hello all. A release Candidate for Prusa Slicer 2.3.1 is out and is available here
Summary
This a release candidate of PrusaSlicer 2.3.1, introducing native builds for the new Apple Silicon MacBooks, Chrome OS support, performance improvements in G-code rendering, security fixes and new 3rd party printer profiles.
Universal OSX builds, Apple Silicon support #5179 #5124
Starting with this release, PrusaSlicer supports the new Apple Silicon MacBooks and MacMinis natively, running about 30% faster than emulated x86-64. The new Universal builds contain binaries of both x86-64 and ARM platforms, thus the distributed package is somehow larger than the previous PrusaSlicer.
Apple deprecated the multi-platform graphics API OpenGL about a year ago. Luckily MacBooks still support OpenGL, however G-code preview rendering of larger G-codes on new Apple M1 machines was extremely slow on PrusaSlicer 2.3.0 #5412 #5695 #5854, #6211. We were lucky to fix that issue through a trial and error process due to a lack of OpenGL API documentation and debugging tools from Apple.
We thank @xarbit and @obelisk for their initial work on PrusaSlicer M1 port #5179 #5313.
Chrome OS support #3392
Chromebooks are getting increasingly popular due to their low price, good usability and stability. This makes the Chromebooks the number 1 pick for the US educational institutions. Luckily Google now offers a containerized Linux on modern Chromebooks out of the box and PrusaSlicer runs in the virtualized Linux environment nicely.
Some users managed to run PrusaSlicer on Chrome OS before, see this post. We encountered the following issues when testing PrusaSlicer on Chrome OS, and we solved some of them:
- Red / Blue color channels were flipped by the OpenGL graphics virtualization. We solved that by disabling multi-sample anti-aliasing on Chrome OS and we reported the issue to Google.
- USB devices of Prusa3D printers are not being routed to Linux, thus the Firmware Updater does not work yet. We have reported that to Google and most likely the Prusa3D USB devices will be supported by some of the upcoming ChromeOS updates.
- Support of removable media detection and eject: PrusaSlicer newly detects removable media on Chrome OS. Eject of removable media is disabled in PrusaSlicer on ChromeOS, as such a function will likely never be available to Linux applications on Chrome OS due to security reasons. Please note that you have to explicitly share each removable media you plug in with Linux.
- Desktop integration: If the PrusaSlicer.desktop resp. PrusaSlicer icon is installed manually to
$HOME/.local/share/applicationsresp.$HOME/ .local/share/icons/hicolor/96x96/apps, then the PrusaSlicer application will be available at the Chrome OS application launcher. We will likely implement an automatic desktop integration into PrusaSlicer 2.4.0.
We have documented installation of PrusaSlicer on Chrome OS in our installation guide.
PrusaSlicer requires around 8 GB of RAM for processing full build plate prints, so you will be more lucky with Chromebooks that are equipped with at least 8 GB of RAM. On a 4 GB Chromebook you will be able to slice just about 4 3D Benchies and 4 Tree frogs at a 0.15 mm layer height. Please note that Chrome OS gives the Linux virtual machine 1 GB less than the physical RAM and there is no swapping enabled in the Linux virtual machine, thus a 4 GB Chromebook gives just 3 GB of RAM to Linux running PrusaSlicer, which is not much. Please note also, that on ARM Chromebooks the situation is worse: Only 3GB of RAM are given to Linux even on 8 GB chromebooks.
Also please note that the OpenGL support on ARM Chromebooks may be flaky. Current Chrome OS provides hardware OpenGL virtualization on modern devices, but the GPU performance of some ARM SOCs (for example Mediatek) is quite low, while on one ARM device we tested PrusaSlicer crashes when switching windows, which is likely a bug in ChromeOS OpenGL virtualization. Therefore we recommend Chrome OS devices with Intel CPUs for now to run PrusaSlicer.
New 3rd party printer profiles
- Multiple Creality printers profiles were added (Ender-3 Max, Ender-4, Ender-6, CR-5 Pro, CR-5 Pro H, CR-6 SE, CR-6 Max, CR-10 Max, CR-200B, CR-8), thanks @pmjdebruijn.
- Added Artillery printer profiles (Sidewinder X1, Genius), thanks @SzabolcsHornyak.
- Added INAT printer profiles, thanks @MarkINAT.
- Updated Anycubic Kossel bed texture (thanks @brunosso) and Anycubic Kossel bed STL.
Vulnerability issues fixed
The Talos Cisco Intelligence Group did a great job identifying potential security issues in loading invalid and potentially malicious AMF and 3MF files, see their vulnerability reports TALOS-2020-1222 and TALOS-2020-1218. We fixed these two potential security issues with this release of PrusaSlicer.
Bugs fixed with respect to PrusaSlicer 2.3.0
- Reduced number of hits shown by the "Find config option" dialog, fixed case insensitive search for non-Latin1 languages #5202.
- Fixed G-code preview with coloring by a tool and visualization of travels enabled #6095.
- Fixed opening of drop down menus at the bottom of the screen on multi-monitor setups #2999 #5911 #5957. This issue has been fixed by us in wxWidgets and accepted by the upstream.
Summary
This a release candidate of PrusaSlicer 2.3.1, introducing native builds for the new Apple Silicon MacBooks, Chrome OS support, performance improvements in G-code rendering, security fixes and new 3rd party printer profiles.
Universal OSX builds, Apple Silicon support #5179 #5124
Starting with this release, PrusaSlicer supports the new Apple Silicon MacBooks and MacMinis natively, running about 30% faster than emulated x86-64. The new Universal builds contain binaries of both x86-64 and ARM platforms, thus the distributed package is somehow larger than the previous PrusaSlicer.
Apple deprecated the multi-platform graphics API OpenGL about a year ago. Luckily MacBooks still support OpenGL, however G-code preview rendering of larger G-codes on new Apple M1 machines was extremely slow on PrusaSlicer 2.3.0 #5412 #5695 #5854, #6211. We were lucky to fix that issue through a trial and error process due to a lack of OpenGL API documentation and debugging tools from Apple.
We thank @xarbit and @obelisk for their initial work on PrusaSlicer M1 port #5179 #5313.
Chrome OS support #3392
Chromebooks are getting increasingly popular due to their low price, good usability and stability. This makes the Chromebooks the number 1 pick for the US educational institutions. Luckily Google now offers a containerized Linux on modern Chromebooks out of the box and PrusaSlicer runs in the virtualized Linux environment nicely.
Some users managed to run PrusaSlicer on Chrome OS before, see this post. We encountered the following issues when testing PrusaSlicer on Chrome OS, and we solved some of them:
- Red / Blue color channels were flipped by the OpenGL graphics virtualization. We solved that by disabling multi-sample anti-aliasing on Chrome OS and we reported the issue to Google.
- USB devices of Prusa3D printers are not being routed to Linux, thus the Firmware Updater does not work yet. We have reported that to Google and most likely the Prusa3D USB devices will be supported by some of the upcoming ChromeOS updates.
- Support of removable media detection and eject: PrusaSlicer newly detects removable media on Chrome OS. Eject of removable media is disabled in PrusaSlicer on ChromeOS, as such a function will likely never be available to Linux applications on Chrome OS due to security reasons. Please note that you have to explicitly share each removable media you plug in with Linux.
- Desktop integration: If the PrusaSlicer.desktop resp. PrusaSlicer icon is installed manually to
$HOME/.local/share/applicationsresp.$HOME/ .local/share/icons/hicolor/96x96/apps, then the PrusaSlicer application will be available at the Chrome OS application launcher. We will likely implement an automatic desktop integration into PrusaSlicer 2.4.0.
We have documented installation of PrusaSlicer on Chrome OS in our installation guide.
PrusaSlicer requires around 8 GB of RAM for processing full build plate prints, so you will be more lucky with Chromebooks that are equipped with at least 8 GB of RAM. On a 4 GB Chromebook you will be able to slice just about 4 3D Benchies and 4 Tree frogs at a 0.15 mm layer height. Please note that Chrome OS gives the Linux virtual machine 1 GB less than the physical RAM and there is no swapping enabled in the Linux virtual machine, thus a 4 GB Chromebook gives just 3 GB of RAM to Linux running PrusaSlicer, which is not much. Please note also, that on ARM Chromebooks the situation is worse: Only 3GB of RAM are given to Linux even on 8 GB chromebooks.
Also please note that the OpenGL support on ARM Chromebooks may be flaky. Current Chrome OS provides hardware OpenGL virtualization on modern devices, but the GPU performance of some ARM SOCs (for example Mediatek) is quite low, while on one ARM device we tested PrusaSlicer crashes when switching windows, which is likely a bug in ChromeOS OpenGL virtualization. Therefore we recommend Chrome OS devices with Intel CPUs for now to run PrusaSlicer.
New 3rd party printer profiles
- Multiple Creality printers profiles were added (Ender-3 Max, Ender-4, Ender-6, CR-5 Pro, CR-5 Pro H, CR-6 SE, CR-6 Max, CR-10 Max, CR-200B, CR-8), thanks @pmjdebruijn.
- Added Artillery printer profiles (Sidewinder X1, Genius), thanks @SzabolcsHornyak.
- Added INAT printer profiles, thanks @MarkINAT.
- Updated Anycubic Kossel bed texture (thanks @brunosso) and Anycubic Kossel bed STL.
Vulnerability issues fixed
The Talos Cisco Intelligence Group did a great job identifying potential security issues in loading invalid and potentially malicious AMF and 3MF files, see their vulnerability reports TALOS-2020-1222 and TALOS-2020-1218. We fixed these two potential security issues with this release of PrusaSlicer.
Bugs fixed with respect to PrusaSlicer 2.3.0
- Reduced number of hits shown by the "Find config option" dialog, fixed case insensitive search for non-Latin1 languages #5202.
- Fixed G-code preview with coloring by a tool and visualization of travels enabled #6095.
- Fixed opening of drop down menus at the bottom of the screen on multi-monitor setups #2999 #5911 #5957. This issue has been fixed by us in wxWidgets and accepted by the upstream.
DOWNLOAD FROM; https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.3.1-rc
Please report any bugs here; https://github.com/prusa3d/PrusaSlicer/issues
Shane (AKA FromPrusa)
RE: PrusaSlicer 2.3.1-rc is released!
Tested 2.3.1-rc today, note first time user of this slicer.
Reason I choose 2.3.1 over 2.3.0 is this version has Creality CR-6SE profile built in.
Printer CR-6SE, 32bit 4.5.2 board
Creality firmware 2.0.1.3
ERROR: After warmup then Automatic bed levelling, the Y axis lifts then then the X axis rams into Y axis post, stepper still drives.
Test file attached, which I was trying to run. (10mm hole size test, with holes +/- 0.2mm hole size steps)
Fabulous Jaban_0.16mm_PETG_CR6SE_35m
RE: PrusaSlicer 2.3.1-rc is released!
I suppose that you might be able to save the CR-6SE profile and reinstall 2.3.0 with that profile.
RC releases of code are very much a testbed for fixes and new code, not for the newbs like us.
RE: PrusaSlicer 2.3.1-rc is released!
For what it is worth, I used to program sheetmetal punch press machines line by line 20 years ago. So quite rusty, however I get the principle of the Gcode. The issue is I trusted the software programmers to test even RC versions, and not rely on the public to crash their brand new 3D printers with dodgy code(insert this public member).
I installed the 2.3.0 and it had no CR6SE and the web review I saw I saw CR-6SE. Found it in the 2.3.1RC , release candidate usually means nearly there. But there is a nasty fault in the Gcode for the CR6SE in the "Start Gcode".
Creality suggests this;
M201 X500.00 Y500.00 Z100.00 E5000.00 ;Setup machine max acceleration
M203 X500.00 Y500.00 Z10.00 E50.00 ;Setup machine max feedrate
M204 P500.00 R1000.00 T500.00 ;Setup Print/Retract/Travel acceleration
M205 X8.00 Y8.00 Z0.40 E5.00 ;Setup Jerk
M220 S100 ;Reset Feedrate
M221 S100 ;Reset Flowrate
G28 ;Home
G92 E0 ;Reset Extruder
G1 Z2.0 F3000 ;Move Z Axis up
G1 X10.1 Y20 Z0.28 F5000.0 ;Move to start position
G1 X10.1 Y200.0 Z0.28 F1500.0 E15 ;Draw the first line
G1 X10.4 Y200.0 Z0.28 F5000.0 ;Move to side a little
G1 X10.4 Y20 Z0.28 F1500.0 E30 ;Draw the second line
G92 E0 ;Reset Extruder
G1 Z2.0 F3000 ;Move Z Axis up
2.31RC has this ;
;TYPE:Custom
G90 ; use absolute coordinates
M83 ; extruder relative mode
M104 S120 ; set temporary nozzle temp to prevent oozing during homing and auto bed leveling
M140 S70 ; set final bed temp
G4 S10 ; allow partial nozzle warmup
G28 ; home all axis
G29 ; auto bed levelling
G1 Z50 F240
G1 X2 Y10 F3000
M104 S240 ; set final nozzle temp
M190 S70 ; wait for bed temp to stabilize
M109 S240 ; wait for nozzle temp to stabilize
G1 Z0.28 F240
G92 E0
G1 Y140 E10 F1500 ; prime the nozzle
G1 X2.3 F5000
G92 E0
G1 Y10 E10 F1200 ; prime the nozzle
G92 E0
The fault I suspect is the addition of the auto bed leveling then driving the coords to X2 Y10. This was the crash.
G28 ; home all axis
G29 ; auto bed levelling
G1 Z50 F240
G1 X2 Y10 F3000
I suspect that G29 loses the home position, maybe the command switches to relative positioning, who knows?
I'd possibly fix this with another G28 after the G29, which is what I do with a manual "home" after auto bed levelling.
However I do not like X2 dimension, why drive it so far over? Creality suggests X10.
Anywho, for Prucer developers, my suggestion here is to use the default "start code" creality suggests, I just checked and notice this is what CURA 4.8 uses.
If someone wants to add the auto bed leveling they can do so themselves, where I'd note doing so appears to have an issue for coords on completion and might require another homing command to get around the issue.
regards
RE: PrusaSlicer 2.3.1-rc is released!
Oops, posted fault here, didn't know you had github fault thing. Reposted under astrosmoke on the github.
Happy four these posts to be removed to save others following my lead here.
RE: PrusaSlicer 2.3.1-rc is released!
@nigel-3
Saw your post on github but thought I'd respond here (so as not to clutter up a proper issue over there). The problem is that ALL non prusa profiles are submitted by users. The prusa team have no involvement in them except to package them up. Going from memory there was a github issue raised about there being no auto bed levelling command in the profile when the machine comes with it as standard I think. Which is rather the opposite of your suggestion that the user add it themselves. So whoever submitted that profile obviously it works for them. The question is why doesnt it work on another cr6 ?
RE: PrusaSlicer 2.3.1-rc is released!
I can't find the link reference at the moment, so i could be wrong with this comment, but I think the person who submitted the setup Gcode for the PrusaSlicer did so with the aftermarket mother board or aftermarket firmware(not sure which). Alas there is currently 3 versions of the genuine motherboard for the CR-6SE printer where with the two 32bit variants you have different firmware for the same revision number. Without diving into the firmware and chip sets there could be an underline built in undocumented (bug, flaw, limitation, insert preference) between the 32bit boards and most likely the aftermarket firmware.
This maybe is why Creality played safe with the start Gcode and did not add the auto levelling as it causes a loss of location memory? (Speculation)
I had a quick glance at the marlin wiki and G28, G29 commands and there is an odd comment with G28 with reference to the G29 or levelling commands. So the problem may not with be Creality boards/firmware, but built into marlin. The quote taken from marlin G28 where the note references some interplay between autoleveling and homing.
Homing is required before
G29,M48, and some other procedures.If homing is needed the LCD will blink the X Y Z indicators.
G28disables bed leveling. Follow withM420 Sto turn leveling on, or useRESTORE_LEVELING_AFTER_G28to automatically keep leveling on afterG28.
The note is arguably lacking in whats going on between the two commands . But it reads that homing interferes with autolevelling somehow, maybe this is just an interrupt and does not damage the location data, however in my case this is what happens, zero or home appears to be lost when G29 follows G28.
In the end a coverall maybe just run "G28" "G29" "G28" to reset the home location, then for safety sake run the warmup strips at X10 and go there slower rather than try to drive the X axis through the wall.
However, an instant fix right now is to do the Creality suggested startup Gcode with a side note/warning in the startup code area, adding the G29 auto levelling requires careful testing for each user because of undocumented differences in boards and firmware.
I'm going to do a test, but it will be in a couple of weeks after I get work backlog cleared.
regards
RE: PrusaSlicer 2.3.1-rc is released!
Yes please add more printer profiles and skip the issue making slot of is unable to use Prusa slicer 2.3.x. Fix the issue with using hilbert curve as top layer.