Why don't you use Cura slicer?
-
I used the old cura, did not like the new interface and moved on to Slic3r PE.
Yes supports are not the best feature in Slic3r, whenever I need to add manual supports, I modify the STL in
meshmixer which works quite well: -
Thanks for all of the responses, keep them coming. Some valid points have been raised (and also some misunderstandings).
Cura comprises the GUI front end which is written in Python and the actual slicer itself which is a C++ program. The slicer
(CuraEngine) is quite fast, what causes most of the slowness in Cura is the Python GUI. Personally, I only work on the code for CuraEngine and having nothing to do with the GUI but I know they are putting great effort into improving it. However, it's probably never going to be able to handle huge models as well as other slicers that are written completely in C, C++, etc. BTW it is quite possible to use CuraEngine without the GUI front end and I know people drive it from scripts.I am hoping to meet some of the GUI developers next month and so will pass on the points that are being raised in this thread. I know that some of these are being worked on already.
Good point. I have not tried the very large models through the cura engine without the python GUI.
I do actually like the slicing engine of cura, though it's not perfect (like none of them are).
Thanks for the interest here, and your contributions to open source software.
-
I used older versions (and still do) I do not like the new interface i find it confusing i guess. There are some settings i feel could use a better (more specific maybe) description of what they do. It will also do stupid things when slicing sometimes. For example small circles (3mm dia) it will revisit the perimeter of these circles 3 times (3 shell) when it really should do the whole 3 at once because these small circles sometimes have a problem adhering when you do multiple passes on the first layer.
-
Developers should always include a 'Classic' interface for legacy users. Nothing like completely throwing your user base under the bus by forcing them into a new interface. Microsoft did this first with their development tools, then the OS with this metro nonsense. It takes VERY LITTLE effort to offer a classic style interface, or one that is dynamic enough to toggle views on and off. The latest version does do this to a limited point - but the interface is still not as elegant as earlier versions. It's just hard on the eyes.
There's just too much going on in the versions after 15.06 - it's too busy and that breaks concentration and makes your eye wander. Maybe some testing should have been done before the entire interface was revamped, using a product similar to Morae: https://www.techsmith.com/morae.html
Granted Cura is free…so I have no recourse or say in the interface (but I did buy a UM2 retail so maybe that counts for some pull).
The major appeal of Cura over others was how simple and to the point the interface was in the earlier versions...which is why I installed v2...and v3...and have yet to print anything out with either. I go right back to v15.06.
-
It will also do stupid things when slicing sometimes. For example small circles (3mm dia) it will revisit the perimeter of these circles 3 times (3 shell) when it really should do the whole 3 at once because these small circles sometimes have a problem adhering when you do multiple passes on the first layer.
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.
-
It will also do stupid things when slicing sometimes. For example small circles (3mm dia) it will revisit the perimeter of these circles 3 times (3 shell) when it really should do the whole 3 at once because these small circles sometimes have a problem adhering when you do multiple passes on the first layer.
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.
-
One point to add is that you can really improve the usability of cura with big/lots of models if you turn off the auto slicing of models. that way you can sort out the build plate move things, rotate etc and then slice the model.
-
I started using slic3r and for a while I was very happy with it. Then they did an update that made the Windows build crash frequently. At that point I tried Cura (I think it was version 15.04) and found it generated buggy GCode, AFAIR it inserted tiny G0 moves between adjacent extruding moves, which play havoc with pressure advance. [S3D does the same when printing curved skirts, but nowhere else that I have seen.] That's when bought S3D.
My main criticism of S3D is that it is terrible at handling multiple printers of different types. It also lacks the speed control for printing "small perimeters" that slic3r has had for at least the last 4 years, which is invaluable especially on the first layer.
I tried Cura version 2.something a while ago, but it seemed very basic compared to version 15.x and didn't seem to understand delta printers.
So if you can tell me that the latest Cura handles switching between different printer profiles better than S3D and allows me to reduce the speed for small perimeters, I'll gladly try using it.
btw I would be interested in a slicer that produced GCode that is less machine dependent, as I outlined at http://forums.reprap.org/read.php?1,803621. I have 3 different printers (Cartesian, Delta and SCARA) all with 0.4mm nozzles, and I see no reason why I should need to slice models differently for them.
-
It will also do stupid things when slicing sometimes. For example small circles (3mm dia) it will revisit the perimeter of these circles 3 times (3 shell) when it really should do the whole 3 at once because these small circles sometimes have a problem adhering when you do multiple passes on the first layer.
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.
That's very good news! Just add the speed control for small perimeters, as David said, and I will certainly go back to Cura!
-
I used to use slic3r but have forgotten about it now(!) so please provide a description of the speed reduction on small perimeters so I can understand the request.
I know that printing curves on the first layer reliably requires a slow down because my personal version of Cura has separate speeds for the first layer walls and everything else. What I do is print the walls on the first layer real slow and then print the skin quite a bit faster. I find this works really well, I get perfect walls and don't have to wait forever for the skin to be printed. I did offer the Cura people the code to do this but they rejected it saying that they wanted to achieve the same thing a different way (this was some time ago). They haven't done anything about it so I will try again.
-
BTW, have you noticed the duplicate posts on the forum? When I posted that last reply I got an error page so I posted it again.
-
Yeah I think I know the cause…. Roll on new forum software when I can!
-
I used to use slic3r but have forgotten about it now(!) so please provide a description of the speed reduction on small perimeters so I can understand the request.
Well, Slic3r has a specific speed param for small perimeters, that's all. You usually set it with a slower speed than normal perimeters. This speed is also scaled down by the first layer reducing speed factor.
But I don't know what is considered as a small perimeter (the length is hard coded). All I know is it works fine.
I know that printing curves on the first layer reliably requires a slow down because my personal version of Cura has separate speeds for the first layer walls and everything else. What I do is print the walls on the first layer real slow and then print the skin quite a bit faster. I find this works really well, I get perfect walls and don't have to wait forever for the skin to be printed. I did offer the Cura people the code to do this but they rejected it saying that they wanted to achieve the same thing a different way (this was some time ago). They haven't done anything about it so I will try again.
The problem is if you reduce the speed of all perimeters to handle small ones, it can takes hours when you have large external perimeters, mostly straight lines, where you can print much faster than small inner holes perimeters.
-
Where the "small perimeters" speed reduction factor in slic3r is especially useful is when I am printing parts with M3 clearance holes aligned with the Z axis. The perimeters for such holes need to be printed very slowly to ensure good bed adhesion and to stop the filament cutting corners.
-
@fma:
I used to use slic3r but have forgotten about it now(!) so please provide a description of the speed reduction on small perimeters so I can understand the request.
Well, Slic3r has a specific speed param for small perimeters, that's all. You usually set it with a slower speed than normal perimeters. This speed is also scaled down by the first layer reducing speed factor.
But I don't know what is considered as a small perimeter (the length is hard coded). All I know is it works fine.
If you hover over the small perimeters box, you get a pop up, and in that it says that it applies to perimeters having a radius <= 6.5mm. At least that's what happens with Slic3R PE 1.37.1. I have no idea why that number was chosen or why it's hard coded.
-
I didn't notice that. Thanks!
-
OK, thanks for the description of the slic3r small perimeters setting. If you use that, you'll be looking forward to exploring M592 so that your first layer walls will have uniform width (just kidding, of course!)
-
One point to add is that you can really improve the usability of cura with big/lots of models if you turn off the auto slicing of models. that way you can sort out the build plate move things, rotate etc and then slice the model.
Thanks for the info. I will have to revisit a newer version again and try this.
-
Opinions only:
I use Cura. I did at one point license S3D and kept going back to Cura, so when C3 came out, I sold my S3D license
Cura V3.x has MUCH better defaults around supports. Still not enough manual control… but... so far, I've not needed manual control if I just take the defaults.
In fact, there is a theme here: I am a person who immediately puts software in "expert mode" and tweaks every setting. I've discovered that with Cura 3, I'm getting fantastic results just using the "recommended" mode of the GUI, which really only takes about four or five settings and leaving the rest of the hundreds of settings alone. This is hard for me… I want to be a control freak... but it seems to work very well. This is the main reason I've come to chose Cura: I want results, not eternal tweaking.
Yes, IMHO, the very first thing you do to Cura is turn off auto slicing.
Cura V2 and/or V3 GUI is VERY SLOW on my machine. The slice engine is fine. I have been working with Cura support on this issue and I believe they've found the root cause, literally in just the last few days. It seems that custom defined printers always have 8 extruders (and maybe 8 of other things) internally. The error checking around the fact that 7 of those 8 don't really exist is what is slowing down the GUI. I'm hoping for a patch soon, and/or I may manually edit the (somewhat byzantine) raw configuration files.
I really, really, really, like the Cura > Octopi plugin. So much that I'm attempting to code a Cura > Duet3D plugin.
So, why Cura? Despite the GUI slowness?
I like open source. I'm getting excellent print results. As a disclaimer, I do not typically print extremely high poly count STLs… and that may change, soon. So we'll see if I still like Cura when I start printing higher and higher count models.
Why NOT ideamaker? Doesn't support round beds, and I'm a delta/kossel fanatic. Otherwise, I'd be giving it a really solid try. Why not Slic3r? Harder to answer. There is something about it that just seems awkward. Personal taste. Also, I can't remember if it supports round beds or not. Why not S3D? While I like generally like OSS, I will happily pay for commercial software if it has value. To me, S3D is absolutely NOT $150 'better' than Ideamaker/Slic3r/Cura. Not even close. YMMV.
Anyway, that's it for now, from someone who's the opposite of the very original question... "Why don't"... well, I DO! For the above reasons.
-
I really, really, really, like the Cura > Octopi plugin. So much that I'm attempting to code a Cura > Duet3D plugin.
.
Have a look here:
https://github.com/Kriechi/Cura-DuetRRFPluginA Cura plugin for controlling a Duet with RepRapFirmware.
Thanks to resam for this, thread is here:
https://www.duet3d.com/forum/thread.php?pid=27676#p27676
