Why don't you use Cura slicer?
-
I would like to use Cura, but it crashes under linux. The python gui seems to have had this issue on early versions too.
How up-to-date is your linux kernel? My installation of Cura used to crash regularly until a kernel update fixed a bug in Mono - which was something that the Cura author couldn't work around.
The Mono bug went away about a year ago, so if your kernel is older…
-
I would like to use Cura, but it crashes under linux. The python gui seems to have had this issue on early versions too.
I'm using the appimage; works Ok on Ubuntu 17.10, Fedora 25 and 26. A couple of very random segfaults during normal use, and consistent coring out if I try to do a API connection to octoprint via a proxy, which is not part of my workflow so unimportant to me. I'd be curious to know if you use the appimage, or an an apt install?
But really, I'd like Ultimaker to offer cloud slicing. I'd probably pay a small monthly fee to have that via a really good web interface. You should take a look at OnShape to see how 3D modelling works great under html 5. Totally the way forward.
One of my goals with 3d printing is to free myself from downstream suppliers who dictate to me what I have, what shape and color it is, when I can have it etc. Becoming reliant on a cloud slicer seems like a step in the reverse direction. I am fearful that the very ability to slice and generate prints will eventually become a service, with patents used to reserve decent slicing facilities only for those with the bandwidth and money to afford them.
That said; as a complementary service It's a great idea; I work for a company making cloud service software; the list of potential drawbacks is countered nicely by a list of real advantages in terms of functionality, feature rollout, central storage, transposable UI's etc. It has a real place in the ecosystem.
TL;DR
It's easy to have an apparently up to date machine who's python install is horrible; Python has it's own package management (pip et al) which sits on top of the OS's package management system; and can get out of step. Especially if you are not familiar with it but start following 'joe-random-stackexchange's' 'guide how to fix python for X' online; since that big list of 'sudo -y pip install XXXX' commands may be really storing up issues for programs expecting the vanilla OS versions. Python pro's know to use virtualenvs etc at these moments, but joe-random doesn't have time to explain that.I believe the appimage supplies it own python libs; which is why I'm curious about your mileage with it.
Regarding Appimages; I simply wouldn't bother with either compiling locally, or installing a port/package. I'm a DevOps engineer and uber-familiar with installing and building apps (I generate over 100 rpm packages when we do a release, for instance..) ; and when I looked at the Cura build instructions I rapidly decided I have better uses for my personal time. The appimage worked first time, and every time. For context: My current 50% project at work is repackaging our Cloud platform into a appimage/binary blob/some other container instead of the 107 rpm's, plus 353 dependencies from CentOS upstream we currently churn through for our daily builds. (as of last night..)
-
One other reason for me using Cura is that I find slic3r very flaky - it sometimes crashes when I add a STL file, for example. I also find the whole structure of slic3r inconvenient - I have to have 10 or 12 different setup files simply to accommodate the different diameters of filament I use. In Cura I just find the relevant line and change the number. The same goes for infill, etc.
-
This is not actually a limitation in Cura anymore as it has an option to optimize the order that walls are printed so that it will print all the walls around a single hole first before moving on to another hole.
Can you point me to the exact parameter? I can't find it…
-
I think it is still in the experimental category and it's called Optimize Wall Printing Order.
-
Got it. Thanks!
-
Just did my 1st print with cura in a long while. I found that the nozzle drags really badly on the infill. Tried going through all the settings but couldn't find anything that could be causing this….
-
Just turn combing off, and then it won't drag the nozzle through the infill.
-
I've made an effort to familiarize myself with Slic3r, Slic3r PE, and Cura 3. I've found things I like from all of them, but I typically find myself returning to Slic3r PE for a couple reasons. I have not used Simplify 3D. I have briefly used Kisslicer and will probably get deeper into it soon.
1. Cura has no speed control for small perimeters like bolt holes so the quality of the holes is incredibly poor. It leaves gaps and drags the filament around the curve. This makes the holes weak. Slic3r knows to slow down and the hole quality is perfect.
2. Cura seems to lack control over bridging and overhang parameters. It would be nice if you could specify slower print speeds and higher fan speeds during overhangs and bridging. The Cura help site just recommends reorienting the part to avoid bridging or to use support material. Slic3r gives a fan setting for bridging operations and gives good results. It also treats the first layer over infill as bridging, which means I can get away with fewer top layers.
3. Slic3r has an ensure vertical thickness setting, which will find areas of the top surface that might need additional layers underneath them and will add some material in a gap fill pattern. Typically under curves surfaces. This ensures the top surfaces will properly fill. I often have gaps when I use Cura, and the solution given to me by Ultimaker is to just use more top layers and denser infill.
4. Cura seems to lack support for firmware retraction. It does give fine control over retraction settings, but those settings are then backed into the gcode.
5. Cura lacks an easy way to manage linear advance K factor values. Slic3r now has that built in per filament config.
6. Cura lacks variable layer height. It would appear that this is coming in the next release, so I look forward to that.
7. Cura won't let you have a brim and a skirt. In Slic3r I use the skirt to prime the nozzle and a brim to help minimize warping. Cura lets me use one or the other. True I could use a larger brim and accomplish both, but a simple circle around the model is all I need to prime and a single wall brim is enough to adhere.
8. Cura was not giving me dimensionally accurate parts. I printed 2 end pieces to fit on the end of a 2020 extrusion. 1 with Cura and 1 with Slic3r, using the same settings as far as I could tell. The Slic3r part fit on the extrusion perfectly, the Cura piece needed ample filing to fit at all. The slic3r bolt holes were properly sized, the cura holes needed to be drilled. Perhaps I needed to modify the extrusion modifier for cura? Is flow % the same thing? I tried changing the flow % in other prints, but would get gaps between walls at anything less than 100%.
There are many things I like about Cura though.
1. I find the settings tree in the new GUI to be easy to use. As a new user coming to version 3 the defaults were fine, and when I needed a feature I couldn't find it was easy enough to add. I spent some time going through the settings and added nearly everything, and as I found what I used often and used never I simply hid the settings I no longer needed. I prefer that to the seperate tabs and views that Slic3r uses. It's interesting to note that the 1.3 dev branch of SLic3r allows you to build a similar sidebar menu which Slic3r PE has not yet brought across.
2. The layer preview is nicer than Slic3r I find, but a little slower. I like that it will simulate the tool head path. I like that it allows you to hide different path types so you can look at just the infill, or just the shell. I do wish they would separate the inner and outer walls and top and bottom surfaces out as well. The layer slider is a little sensitive. I like that it shows travel moves.
3. I like how Cura allows you to use modified meshes to define separate print settings for different areas of the model. Though it's usage is a little esoteric. Slic3r has similar modifier meshes but I find them even harder to use. It would be nice if this was exposed more easily in the GUI. For a while I was using these meshes to overcome the limitations I mentioned above, but it was taking forever to prepare a model. It was simpler to just use Slic3r.
4. I like that Cura gives very detailed control over print speed, acceleration, and jerk settings, minus bridging and overhangs. I find I'm able to get generally better print quality with lower print times from Cura, minus the complaints above.
5. Cura seems to properly support vase mode. Slic3r is very hit or miss.
All in all I would like to use Cura more, except for the issues I mentioned above. For now, if it's a mechanical part, I use Slic3r. If it's a art piece, I use Cura.
-
Hello Phaedrux, thanks for the extensive posting - all good stuff. BTW, I have just implemented adding settings to change the speed/flow/fan when printing bridges. Hopefully, that will mature and make it into a future release.
-
Excellent. I hope Cura continues to improve. I have been impressed with the pace of development for version 3. I hope it keeps up.
Will those settings affect bridging only, or overhangs as well? It would be nice if overhangs got some special treatment. There are times when I'd like to print outer walls first, but overhang performance suffers. Either speed and fan controls, or the ability to specify outer walls first, except on overhang layers, would be nice. The support generator already can tell the angle of overhangs to support, so hopefully special rules for overhangs could be made?
-
Just turn combing off, and then it won't drag the nozzle through the infill.
That did it thanks
-
OK, I'll look into what it will take to be able to specify settings for overhangs. A relatively easy solution would be to use the bridge settings for walls whose overhang angle is less than some threshold. Would that be acceptable?
-
1. Cura has no speed control for small perimeters like bolt holes so the quality of the holes is incredibly poor. It leaves gaps and drags the filament around the curve. This makes the holes weak. Slic3r knows to slow down and the hole quality is perfect.
3. Slic3r has an ensure vertical thickness setting, which will find areas of the top surface that might need additional layers underneath them and will add some material in a gap fill pattern. Typically under curves surfaces. This ensures the top surfaces will properly fill. I often have gaps when I use Cura, and the solution given to me by Ultimaker is to just use more top layers and denser infill.
6. Cura lacks variable layer height. It would appear that this is coming in the next release, so I look forward to that.
Variable layer height has now bee added, although it's automatic.
I too have noticed that I get gaps on curved surfaces. I think there is a setting to sure it but can't find where it is now.
I too would like to slow down automatically on small parameters
-
One issue i've just noticed it curves don't play nice with pressure advance. Anyone else noticed a stuttering with it turned on?
-
David can confirm but I think that the latest beta of RRF has some fix for pressure advance related to the smoothness of extrusion rates in curves.
-
OK, I'll look into what it will take to be able to specify settings for overhangs. A relatively easy solution would be to use the bridge settings for walls whose overhang angle is less than some threshold. Would that be acceptable?
Yes I think that would work well. Overhangs and bridging are pretty similar in their requirements for slow speeds and lots of cooling so they stay in place. This one change alone would make Cura more usable for me.
One thing that Slic3r also has is an extrusion multiplier specifically for bridges, with the logic being that since you're extruding into thin air, you want a thinner extrudate so that it gets pulled taught, and there is less plastic, and therefore, less thermal mass so that it cools faster. I've found this very useful when printing with larger nozzle diameters.
I would also say that being able to look ahead and detect a bridge is about to begin and slowing down before leaving the edge of the supporting layer so that it has a chance to anchor itself. I notice that Slic3r will slow down a little too late and the extrudate will break or disconnect.
Also, I've just been looking into the variable layer height plugin and it looks really good. The manual GUI from Slic3r PE is a bit weird and fiddly to use. The 1.3 dev branch of Slic3r has an automatic function which obeys a full steps/mm value you specify which is a much better way to do it. I hope the Cura version is similar.
https://community.ultimaker.com/topic/20451-cura-variable-layer-heigth/ -
One thing that Slic3r also has is an extrusion multiplier specifically for bridges, with the logic being that since you're extruding into thin air, you want a thinner extrudate so that it gets pulled taught, and there is less plastic, and therefore, less thermal mass so that it cools faster. I've found this very useful when printing with larger nozzle diameters.
I would also say that being able to look ahead and detect a bridge is about to begin and slowing down before leaving the edge of the supporting layer so that it has a chance to anchor itself. I notice that Slic3r will slow down a little too late and the extrudate will break or disconnect.
Also, I've just been looking into the variable layer height plugin and it looks really good. The manual GUI from Slic3r PE is a bit weird and fiddly to use. The 1.3 dev branch of Slic3r has an automatic function which obeys a full steps/mm value you specify which is a much better way to do it. I hope the Cura version is similar.
https://community.ultimaker.com/topic/20451-cura-variable-layer-heigth/Yes, I have a bridge flow setting which does the same as the slic3r extrusion multiplier.
What I have implemented is that the bridged region of walls extends a little onto the solid regions that support the bridge so that the bridge settings come into action just before the air below starts and finish just after the next solid region is encountered.
I am not involved in the variable layer height stuff other than I made some small contribution to speed up their implementation.
-
Your implementation sounds great. Can't wait to try it out.
-
As far as the seg faults under linux go, I had another great one on a clean install. I want to add my K8400 dual nozzle. Can't.
I can add the single nozzle variant no problem. Try and add the second nozzle. Boom! Just dies.
Raised on it github. Discover it's an old bug that's still there after many months. Means it's impossible to add a dual nozzle printer. Again it's one of those annoying python gui issues that's causing it. So frustrating, both for users and the developers I imagine.
This is under the latest LTS version of Ubuntu.
