PrusaSlicer with better RRF time estimates.
-
Hello,
I've been tinkering away on my fork of PrusaSlicer. Making small adjustments. I've released a new version of 2.4.0 beta 1 that allows the user the ability to use accurate time estimates by inputting machine parameters while also using RRF gcode flavor. Previously, one had to switch back and forth to marlin to get the accurate print time estimates.
There are also other improvements. A large number of them are simply settings switches provided to disable hard-coded prusaslicer behaviour.
NOTE: GRID SUPPORTS ARE DEPRECATED IN THIS VERSION! USE SNUG SUPPORTS INSTEAD!
New features introduced with settings:
- Additional XY separation for base/sparse support
- Expand or filter support structures
- Extra skirt base loops/layers
- With sheath around the support interface
PrusaSlicer previously hardcoded behaviour now with settings:
- Auto-adjust solid infill spacing
- Loop clipping
- Little move inwards (wipe kind of thing at end of loop)
- Optimize island extrusions
- Optimize tool order
- Retraction wipe speed
- Small perimeters length
- Skirt speed
- Prevent retraction within support islands
- Solid infill acceleration
- Support material acceleration
- Support material interface acceleration
Fixes and features:
- Lower polyline/polygon simplification threshold
- FDM snug support fixes (GRID SUPPORTS ARE DEPRECATED IN THIS VERSION!)
- Better handle solid infill expansion
- Remove slic3r non-rectangular-prism flow math
- Increased G-Code numerical precision
- Darker BG gradient
- Bottom solid infill is printed at top solid infill speed
- Added ability to use machine limits and time estimates for RepRapFirmware (as already mentioned)
- Dramatically improved perspective camera behaviour
Demonstration of new perspective camera:
In stock PrusaSlicer, the orthographic camera can sometimes be nearly identical to perspective camera.
Now, perspective is always relative to print volume/plated scene:
More info and downloads for Windows 64 bit and macOS here: https://github.com/n8bot/PrusaSlicer/releases
-
I don't suppose you could rename your executable for MacOS so that it can live alongside stock prusa slicer in the applications folder? MacOS won't let me rename it otherwise it won't launch! (Apple is getting out of control)
-
@phaedrux I do not know how to do that, but I will try that right now!
Do you know how I could reliably rename the app so it works? I actually tried, and it broke like you noticed. Maybe if I rename it before moving the bin into the ".app" folder.
You should be able to run it straight from the DMG, tho, for now. Right?
-
I have zero clue. Sorry.
But yes I can put the app elsewhere and run it from there. I actually just ended up turfing prusa slicer stock entirely as I haven't used it in a long time and it's out of data anyway. I've been using Super Slicer and Cura Master almost exclusively. Though Cura Master is no longer being build for Mac.
-
@phaedrux I will definitely figure out how to rename the app, though. It's definitely problematic.
This version should be really easy to use in place of stock PrusaSlicer 2.4.0 beta1. I put a lot of effort into retaining as much stock behaviour as possible, while giving the option to disable or use new features.
There are a couple differences that are hardcoded, but in most cases it will be not noticeable and is more in line with the behaviour of other slicers. (The extrusion width/spacing math in particular, and the g-code numerical precision.)
If the g-code produced is too detailed, the RESOLUTION setting should checked that it's at the new default of 0.0125 to replicate stock prusaslicer behaviour.
-
@phaedrux Well I just tried as many things as I could think of, and I can not get it to work with a renamed application.
However, I think if you drag it to your applications, and there is already one there, it gives you the option to keep both. Then, I think, one of them gets a different name at least. Not an ideal situation, but. I have no clue how to fix it. I'm not a mac person I just borrowed my wife's old macbook to compile it lol. Sorry!
-
Really interesting additions. PrusaSlicer is my slicer of choice for a long time, and I recently started to playing around with SuperSlicer for extra settings.
Have you considered contributing/push some of your cool additions to SS?
Dont get me wrong, I dont wanna sound rude, really appreciate everyone who does this kind of open source stuff, I was just wondering about managing different slicers just for some specific function… -
@pew I've gotten help from merill (author of superslicer)
He has a lot of good ideas and ability to execute them, and has a lot of work on his hands. When I get the chance I'll mention and show him some of the changes I made. He will be able to easily add them to superslicer if he choses. Many of them he has already taken care of in way more complicated ways haha. He loves adding lots of stuff. I'm trying to keep things closer to mainstream branch because I have a more limited capability of maintaining the changes.
@Phaedrux it might not matter much anymore but I figured out how to get the app binary name changed. It was easier than I thought I was just being kinda silly. The release is updated on Github, so profiles/settings on macOS are saved separately from stock prusaslicer.
-
@bot would you make a PR to PS aswell for the rrf limits?
-
@pcr and would you change the mm/s to mm/min for the jerk?
-
@pcr Yeah I was thinking of that. I have a lot of open PR right now, and some of them are silly, so they might not take yet another PR seriously at the moment. I will test it out some more, and let users test it out, before submitting it to them.
One thing that is bugging me about my current workaround implementation is how to handle "stealth mode." afaik, it does not affect anything negatively to include it as is with RRF, it simply provides a second time estimate based on a second set of values. I suspect the Prusa team will not like that integration, but it might not bother them.
-
@pcr the mm/s to mm/min for jerk is taken care of behind the scenes, if you emit to gcode.
The time estimator uses mm/s, and I don't want to mess with that (less is more in this case. if I can leave something alone, better).
So, simply input your jerk values as mm/s, and the app will take care of the rest. If you emit the values to gcode, it will use m566 with mm/min if you have RRF as the g-code flavor.
*not actually a robot
-
I'll take a look next time I print something. Good luck with the PRs
-
@bot AH PERFECT!
Really great work. Is it possible to get a Linux version too?
-
@pcr I don't have any PCs with linux distros, but there are build instructions for linux it should not be hard. I was just thinking about getting that set up today. I made a few commits that might be useful or not for isolating any linux builds from stock prusaslicer. macOS threw me a curve ball and now I'm worried about linux.
Could you try and build from source and see how it works out?
-
YEP
-
@pcr Very nice! Thank you!
Where is the .ini settings file saved? is it /users/user/Library/Application Support/PrusaSlicer-n8/ ? Or is it in a folder named just PrusaSlicer? This is important to keep the n8 version separate form the stock version.
Also, the PrusaSlicer.desktop file might not be configured correctly. I don't even know what it's for really. Does the correct name and icon appear for the app in your desktop environment?
Please don't hesitate to let me know of any issues you encounter I'd be happy to hear about them. I've never had it running on linux! Linux looks nice. What desktop environment you using?
-
@pcr I ended up making a PR anyway, so feel free to comment with any desired changes or problems:
-
@bot when will you merge upstream ;)))) hehe beta 2 is out
-
@pcr there is really not much added since I compiled this. Mine is basically beta2, except a few tiny bug fixes. If you need anything specific let me know. I have a beta2 branch that you can compile:
n8-240b2
