I discovered something really surprising today. When I have my model walls built to a multiplier of my nozzle witdth (attempting to get simple straight runs rather than inefficient fills), and set the shell thickness to that same multiplier of the nozzle width - CURA is not happy and creates a really inefficient print. BUT BUT BUT - When I reduce the shell thickness setting by 0.01 mm (one-hundredth), everything works as planned. In the model where i found this issue, this fix reduced my print time by 62%! (from 68 minutes to 26 minutes). I wrote a blog post about this if ppl are interested in details and pics: http://www.mkrclub.com/2015/06/speed-up-3dprinting-shell-thickness.html - but i included here most of the details you need to experiment yourself.
Isn’t that compensating by doing one less perimeter and using fatter line widths? So if you’re going from three perimeters to two, it makes sense that you’re seeing a 33% reduction in build time estimates. You need to compare the generated g codes, not just the time numbers.
i found another strange thing with cura : if you increase the print speed over a value the print time increase also. I can’t explain it to myself.
@Fabio_Ferretti Most likely the interaction between minimal layer time and print speed. There are some heuristics in there which sometimes cause this.
@Daid_Braam i’m not sure about that, it append even with large flat object with layer that take more than 2 mins. (20cm wide vespa logo)
I feel someone should get back to the notion of designing for multiples of nozzle width. Extrusion width should be about 1.5x nozzle width, depending on the slicer and settings. This has to do with ensuring good layer adhesion. So, when designing, you need to use multiples of extrusion width to anticipate efficient printing, not nozzle width.
@Jeff_DeMaagd no - i must not have described it well… In the 15 minute case, it was not using 3 perimeters - it refused to for some reason. I could see it in the layers view. And when I used fill density (20% for example) it was filling so innefficiently (teensy back-n-forth motions to fill that .3mm space).
There were some CURA quirks that made some of the results not reproduce perffectly each time - but some were easy to see.
In the efficient case, I’m getting 3 perimeter runs to fill that space.
@Dale_Dunn Oh - “extrusion width” is a completely new notion to me… will have to read up on that - thanks!
Can you post or link to the model? Maybe some of us can play with it to see what’s going on.
Interesting find. It may be in part because of weird quirks like this that I routinely switch between Slic3r, KISSlicer and Cura. I just find that some models slice better in one than the others and not always in ways that I can understand or anticipate.
I like the huge amount of adjustability that Slic3r provides so it’s become my “go to” despite arguably inferior results in a number of areas. I usually try to tweak Slic3r to play nice with my model for a bit before trying one of the others if I really can’t get the results I’m looking for (in the g-code preview).
I started with Slic3r - but experienced the same while I was inbetween CURA and Slic3r - that some models just worked better in one than the other… I should experiment with this same phenom in slic3r to see what happens…
@Fabio_Ferretti yes - I agree with @Daid_Braam on this for sure - that min print time per layer might be the factor making print time increase with an increase in raw print speed. I’ve had that happen and was able to prove it by changing min print time to a very low value.
@Jeff_DeMaagd Just make a box with a consisntent wall thickness - that’s what i did mostly after my original model (the more complex one) had these issues.
I can also upload when I’m back at my home