1

Topic: Slic3r crashing on high resolution slicing

When trying to do a .1 mm resolution slice in slic3r, it is crashing at infill every time. Oddly enough, the one time I forgot to change the layer width to 0 to allow it to do the auto calculate, the slice was successful. From what I've read in some other forums, there are issues with the 32 bit slic3r trying to use too much memory. I think it is more than 2 GB. Is anyone familiar with this and or know how to reduce the complexity of the slice so it doesn't take so much memory?  I am not at home, but will post the profile when I get there. I did try .3 first layer and .1 after that with .1 infill every layer and every 3 layers but it crashed either way.

2

Re: Slic3r crashing on high resolution slicing

For whatever reason, when I got home and tried one more time, I could not recreate the crash... The only thing that I did differently was save the profile, close slic3r, and reload the profile and .stl... I'll post results in the morning since it is a 5 hour print...

3

Re: Slic3r crashing on high resolution slicing

This seems like it continues to be a problem with high resolution prints and even the same print with a scaled up model...  Seeing if I can find any solutions now....  I am curious if anyone else is able to slice this with .1 mm resolution scaled up to 150-200%?  It is still consistently crashing as soon as the memory usage spikes at the infill layers stage...  I don't think it is taxing my computer as much as it is Slic3r.

Post's attachments

dragon100k12cutkleinMLNL65mm_fixed.stl 4.97 mb, 29 downloads since 2012-09-05 

You don't have the permssions to download the attachments of this post.

4

Re: Slic3r crashing on high resolution slicing

I haven't changed the setting on mine yet but you can alter the amount of threads allocated in the Slic3r settings. Upping it from the default of two might provide the requires resources to finish the process.

5

Re: Slic3r crashing on high resolution slicing

Ya, I did try that as well with no luck...

6

Re: Slic3r crashing on high resolution slicing

I was able to slice it.

.1mm layers
.1 Fill
Fill Every 3 Layers
.35mm thread width

It peaked at 2.1GB of RAM.  If it is getting overwhelmed with fill, you can reduced the fill, or reduce the # of fill layers so there aren't as many moves.  This model looks like you could get away with no fill at all, and maybe 4 perimeters to make sure there is enough overlap.

7

Re: Slic3r crashing on high resolution slicing

Ian, were you able to get this sliced when scaling up to 150 or 200%?  I can slice it at this size, but not scaled up.

I think that changing the way your object is printed to accommodate the slicing program is kind of skirting the issue anyways since there may be times when you really want a very dense infill... I am also well aware it is a great and free open source software so not complaining, just looking to find out how to make the most of it.  I am peaking at around 2 GB of RAM as well which is not pushing my computer, which leads me to think it is slic3r...  That's why I was wondering if there is a way to slice it differently without compromising on the way you want the print done.

8

Re: Slic3r crashing on high resolution slicing

It was scale 150%.  I've run into the limit trying to print multiple objects.  I wanted to get around the cooling issue by printing several figures at once, but at 3 or 4 it got too complex.

9 (edited by jooshs 2012-09-05 15:46:37)

Re: Slic3r crashing on high resolution slicing

So, I believe I found the problem... Slic3r does not like to calculate the thread width for you in the infill layers.  If I fill this in manually, it seems like it will slice every time.

Ian, I noticed on your Solidoodletips you said you used .42 for default extrusion width, but said .35 for this slice.  I have had better luck on higher res prints with a smaller width closer to the .35 width.  If you change the extrusion width, will Slic3r automatically adjust the flow rate to try to match the extrusion width at different points on the layers?  It would be nice to keep the perimeters at a very narrow width while keeping the infill closer to the .42 width...  Unfortunately, I won't be home till Friday to try this.

I did also go up to the 64 bit version.

10

Re: Slic3r crashing on high resolution slicing

What have you found the difference to be between the widths?  I would think that from the outside, it wouldn't look any different.  You could print 3 perimeters at .42 and get the same wall thickness as .30 at 4 perimeters, so there would be a time savings.  Also overhangs might work better, since there is more support at the inside edge of the thread.

On the other hand, the thinner thread would give finer surface detail since it can turn tighter corners.  I guess it would be a judgement all based on the model.  If there is a lot of surface detail you would want finer threads, but go thicker if there are a lot of challenging overhangs or you are trying to print hollow.  And turn down the horizontal resolution of fill with wider threads, just as you turn down the vertical resolution of fill with Fill Every X Layers.

Slic3r will adjust the flow to hit the specified thread width.  I'm not too confident about Skeinforge 39, though Skeinforge 50 should be able to do it like Slic3r.  I haven't had very good luke with Skeinforge and .1mm prints.  Even though I have the flow rate dialed in, it always seems to pile in too much plastic with one solid layer after another.  I was printing a Rainbow Dash (by request) and SF would do a slow set of perimeters of one leg, then do all four legs at speed, repeating the first leg.   I could turn the flow down and keep tweaking and testing until it seems right, but I hate dialing in the settings subjectively.  I like to do something I can measure to determine whether it is the proper result.

11

Re: Slic3r crashing on high resolution slicing

The difference has definitely been in the surface finish...(I also noticed that a happy accident is that prints take longer, but it helps small layers cool better when you use more perimeters and finer width threading) When I am doing prints with a good bit of surface detail and want something close to a smooth looking finish, the smaller thread width is very nice.  It actually eliminates the appearance of layers on some of the gradual curves in models.  The other thing was that it seemed to allow me to create holes that were smoother.... I don't know why this is and or if it has to do with the fact that I slowed the small perimeters way down, but the very small holes are much better.  Theoretically, the thread width shouldn't have any affect on this, but it helped. 

As you said, it is a judgement call based on the needs of the model and your patience.  Same size prints will fluctuate wildly depending on settings.  Even this dragon can go from 11 hours to 22 hours depending on different setting at same resolution... I haven't experimented with increasing the thread width much on infill, but but this may be another thing to look into to save time.  I really like how much easier and less there is to deal with i Slic3r than SF at this point.  I'm not sure that it gives you the complete fine control that SF does, but it seems easy to understand everything that you are controlling and producing.

12

Re: Slic3r crashing on high resolution slicing

I've been getting better surfaces with Skeinforge.  I'm more likely to see bumps on curved surfaces in Slic3r where the nozzle moves in, or changes layers.  However Slic3r handles solid surfaces better.  If SF thinks that some infill will get exposed due to the layer above being set back too far, it will make that infill solid for the whole layer.  Slic3r adds solid infill only in the area needed.  Because of this, the SF Yoda took 3.5 hours, compared to about 3 hours for the Slic3r Yoda.  SF kept making solid layers all the way across the inside of Yoda's head because of some horizontal surfaces inside the ears.