View Posts
MatterHackers Forum
This forum has been set to read-only for archival purposes. Please visit our Community Forum to ask and participate in active discussions.
Saving Intermediate file
by >cosber

Depending on the size of the object, it can take 10-15 minutes to begin printing before it finishes "Saving intermediate file". Is this normal?

cosber - August 8th, 2014 at 6:42p.m.

Which slicing engine are you using? This is not unusual for large parts if you are using the Slic3r slice engine.

kevin.pope [Moderator] - August 9th, 2014 at 10:43a.m.

I'm using slic3r. Right now I'm printing something that I've had to restart 3 times for various reasons and the first two times it took 35 minutes. This third time it's still saving, though it's "only" been 25.

Dave Cosford - August 11th, 2014 at 6:51p.m.

@Dave, We always recommend our users work with MatterSlice, it's the slicing engine we wrote :). It is much, much faster than Slic3r.

Is there a specific feature of Slic3r you are needing? I'm sure we can get you the same result in MatterSlice.

LarsBrubaker [Moderator] - August 12th, 2014 at 9:11a.m.

Long story short, here is a fix if you wish to continue using MatterControl with Slic3r as your G-code and slicer engine.

Uncheck "Avoid Crossing Perimeters" under Slice Settings > Print > Layer/Perimeters > Perimeters. Trust me, it works.

Note: If you are just wanting an answer, do what I said up above, but if you want to know how this fixes it and how I figured it out then continue reading.

I was using this setting when printing, but only when I was doing one object. When I copied/multiplied the object more than once, when generating the gcode and slicing it took FOREVER.... Actually I never even sat and waited for it to run.

I have used Slic3r before with another printer, but never within MatterControl, so I knew that Slic3r was not this slow... So I decided to just put all of my setting from MatterControl's Slic3r and copy it into the original program of Slic3r.

After about 15 minutes of making sure everything was good and getting kind of irritated at the inconvenience of this "bug" for MatterControl thats when I noticed it...

I noticed in the original program Slic3r under Printer Settings > Layers and Perimeters > Quality (slower slicing) I saw "Avoid crossing perimeters (slow)" : This feature both slows down both the print and the G-Code generation. (Default: no). After unchecking it in MatterControl using the Slic3r engine it generated super quick and prints like a champ.

So, in conclusion, I am not sure if this is a MatterControl bug. I assume it is because using the original application of Slic3r it still works and generates in a decent amount of time, but not hours and hours like in MatterControl. I hope this helps both the people having this problem and who still wish to use Slic3r and MatterControl together, as well as the developers of MatterControl be able to figure out why this happens and whether or not this is a bug.

Hope this helps!

DarkComet - January 25th, 2015 at 11:01p.m.

@DarkComet, thanks for the info on Slic3r and 'Avoid crossing perimeters'. We used to include the 'slow' description for this setting but it is fast in CuraEngine and MatterSlice so we took it out. This setting helps a lot with avoiding internal stringing so we enable it by default. We'll look at better ways to communicate the issue with Slic3r. Thanks again.

LarsBrubaker [Moderator] - January 29th, 2015 at 9:13a.m.