New Mattercontrol Slicer

After spending 45 minutes for the "Saving Intermediate file" to finish using Slicr, I thought I'd give the other slicer option in Mattercontrol, Cura. I was surprised to see there was a new one in the list, Matterslicer. I tried it and the same object that took 35 minutes took 5 SECONDS!!! What's up with that?

 

And did you print it? What does it look like? Anyway to compare your results with previous prints using Matterslicer?

 

I printed an iPad stand using new neon yellow filament. It's not as smooth as one I printed in black. The base is very nice but the supports are kind of rough. I'm printing a lawn sprinkler in black so we'll see how that turns out.
Since I didn't make any adjustments to the new filament, I can't definitively judge the results, but 5 seconds compared to 45 minutes?!? I'll take a little poorer quality.

Sent from my iPad using Tapatalk HD

 

Here is the iPad stand and sprinkler sliced with the new Matterslicer. Rough, yes but not as bad as the photo shows. The yellow neon really distorts the look. I think with some tweaking prints could improve. Also using the new hotend from Robo and have only printed at 200. All in all I'm very pleased.


Sent from my iPad using Tapatalk HD

 

Slic3r's really slow, that's why I switched to cura forever ago.

 

Mike, What's the last version of Slic3r you used? The current version is fast as far as I can tell.

 

I suppose I haven't used it since one of the 1.0RC's


e trying a slice in MC right now, gets stuck on saving intermediate file

 

You're using Slic3r? It's not stuck-just really, really slow.

 

Yup just checked, looks like it sliced. Eventually

 

Could there be an issue with the way matter control is calling Slic3r? I really don't wait long even with stuff with lots of polygons. Maybe 30 seconds for something complex. I'm using a two year old i7 with only 4G of RAM. Slic3r version is 1.2.0.

 

Windows needs minimum 8Gb to run properly. Not sure of the Mac requirements.

I found that sometimes to get your object to slice properly and efficiently, you might have to orient it on the bed differently. Perhaps rotating the object or even angling it on the bed rather than straight on.

The angle trick will sometimes help in creating stronger parts.

Just a thought when trying to slice.

 

I am running a Dell XPS i7 with 16gb ram and every time I use Slic3e it gets stuck on saving intermediate file as well (don't know if it ever completes... never wait that long) Is there any known "fixes" for this when it did work it worked great and so far I'm not too happy with any of the others...

 

Not really. MC and Slic3r are both 32 bit apps, which is part of the reason they're so slow and choke hard on even moderate sized prints/files. I have a ton of STL's I can't even load without it crashing with memory errors.

 

I found that files that are not manifold also cause the slicer to crash or take too long to finish. Try putting the model thru Netfabb basic. Make sure it's manifold and no errors.


Sent from my iPhone using Tapatalk in Canada

 

Hey guys,

I'm one of the developers on MatterControl and MatterSlice. We have been working hard to ensure that MatterSlice gives great results, and has good numeric stability. Whenever you find problems, please let us know. We are an open source project and love all the help we can get.

 

How shall we let you know? I am experiencing various bugs... especially with CuraEngine. In one instance, I had a model that had been previously sliced/printed with MatterSlice no problem. However, after firmware upgrade and nozzle replacement there were various issues on curves (bumpy/textured/jerkiness of carriage)... so I went to try CuraEngine. It wouldn't work. It gave 1 slice, and said done (not even showing that one slice in the layers view); other models say "Preparing to slice..." forever. When trying the Whistle model, I had to completely remove the model from the Library and Import the STL file back in... then CuraEngine appeared to slice it, but upon print, there was no extrusion.

Once again, the print extrudes fine using MatterSlice. But with CuraEngine... it is tracing the motion properly, but not extruding at all. Is it too close to bed? Underextruding? Can't tell...

 

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!