Why don't you use Cura slicer?
-
1. No slowdown when printing bridges.
2. Too much options. -
I drop Cura some moths ago because when printing perimeters, it prints one wall at a time, instead of printing all walls of the first perimeter, then move to the second perimeter and print all its walls, and so on…
It does not matter for any layers (except time lost), but on the first layer, it tends to tear off the wall when moving towards the second perimeter. If you have small perimeters, then you get a crappy first layer.
I asked on the forum to change that, and I was told it was not possible because of Bowden (don't remember exactly, but it was non sens to me).
At least, if it was able to slow down on small perimeters, it would no tear off the wall. But it does not... So, user has to slow down the entire first layer at a ridiculous speed, even non-printing speed.
Second think I don't like is the GUI: why spending so much time in re-writing a complete graphic lib? Why don't using Qt basic tools? It is ugly, not really handy (rotating the part!) and it takes hours to start. And it is a 100Mb executable!!!
That's why I switched back to Slic3r.
What Cura does well is support; Slic3r supports are crap.
-
I use CURA 15.4 for my older printer.
Everything is configured, it just works. It's nice and I don't have the courage to change slicer for it…I used Cura 3.1 for my newer printer and I prefer Slic3r PE.
The main problems with Cura are:
- Relative extrusion that is not really explicit
- Bridging parameters that can't be modified
- No manual support
-No easy way to change the Jerk and Accel parameters to have a more precise Time Estimation - No small perimeters parameters (that was the deal breaker of Slic3r for me).
But Slic3r is not really better, it's just different, with other quirks and good points.
I agree with FMA:
@fma:What Cura does well is support; Slic3r supports are crap.
One very positive point of Cura is the Ironing feature. It's a nice implementation…
Cura is free, as Slic3r and it's a very nice feature too. ^^
-
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.
-
Mostly stopped using it because it didn't support Z offsets for the bed. Although I have S3D I much prefer to use Slic3r PE.
-
@fma:
Slic3r supports are crap.
Which version are you using? I didn't use supports with Slic3r for a long time because they were junk, but have been using them again with Slic3r PE and they are working pretty well IMO.
-
@fma:
Slic3r supports are crap.
Which version are you using? I didn't use supports with Slic3r for a long time because they were junk, but have been using them again with Slic3r PE and they are working pretty well IMO.
+1
-
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.
