Slic3r 1.0.0RC1

It is quite a bit more work to get running. I spent quite a bit of time over the past two days getting all of the parameters set in KISS. It took 2-3 miserably failed prints and a few hours of messing with settings to get it to work. But it seems to me that the paths are better with KISS. I printed some cable chains with slic3r and some with KISS. The ones printed with slic3r left voids in the print that KISS managed to fill in. About a third of the cable chain pieces printed with slic3r broke while I was snapping them together. None of the ones printed with KISS broke.

One thing that helped was to open up the slic3r gcode file and copy/paste the prefix and postfix into KISS. KISS doesn't do things like homing and turning off the bed when its done. You have to add those manually. I basically wanted to keep all of the slic3r startup and ending setup, and I like that you can customize those procedures in KISSlicer.

I'll probably be using KISSlicer more often now. I have a little more stringing to get rid of, but I think with more tweaking it'll go away.

Edited 1 time(s). Last edit at 11/22/2013 02:10PM by iquizzle.

Is it worth it to pay for the "Pro" upgrade? I don't have dual extruders and the list of extra features doesn't mean that much to me accept multiple objects:

Multiple Objects

Load as many STL files as you wish.
All objects will be automatically packed onto the bed.
You can Export the composite STL of the packed objects.

Multi-Head Printing

You can pick a different extruder for: Raft / Support Base / Support-Model Interface / Model
The 'Wipe Pillar' allows multiple heads to be used without the stringing problem after the head warms up.
Smart Temperature control gives priority to already-warm extruders on any given layer.

Stacking

Support and Sparse-Infill can be printed every N layers.

Advanced Options

Oversample resolution
Crowning Length Threshold
"Slice & Exit" mode to use the last settings and simply slice a STL to G-code from the Command Line..

My machine is back in service and I have been playing with the new slic3r but only a little.

2 things I noticed right away:

1. infill in small spaces is much better (no more holes or gaps in thin walls at least on my tests).
2. Support is worse than ever. Using the default support on both prints, 0.9.10b gave descent support and was easy to remove with only a little cleanup needed. 1.0 the support was extremely hard to remove and after 10 minutes of cleanup still looked bad. Also it's weird that with support enabled, it would print support on one layer and the object on the next layer but not on the same layers (using repetier host to view layers individually). So even though both prints were set to .2mm layers, it looks like the 1.0 layers are thicker than the 0.9.10b version, like they printed thicker and only every other layer, very weird. So I just used my 50x ProScope microscope to confirm thicker layers. In one pick taken at the exact same size and distance the 1.0 had 21 layers while the 0.9.10b had 26 layers. So it's not double but they are thicker layers.

Anyway I feel that support in 1.0 is useless at least on small items. Have not tested it on larger items where the support will be taller.

I had to play around with the support settings to get them back to being removable. My big issue was that support that was running vertically next to a vertical surface was sticking to it (one of the issues in your pic).

I reset all the support material values to default and then set overhang threshold to 30 and interface layers to zero for this dragon print.

What appears to be missing is a gap between the support material and adjacent vertical surfaces. (I see bug number 1539 has been raised on this)

Rob

Edited 1 time(s). Last edit at 11/23/2013 07:36AM by pocketmoon.

Quote
tjb1
I really don't see how it can be a rendering issue when it is pulling all the data from the G-Code.

Your rendering looks different from crispy1's rendering in different software. And it is different from what I got viewing it 2D in pronterface. There are other examples in this forum of renderings not corresponding to the gcode. It happens.

Quote
jebba

Quote
tjb1
I really don't see how it can be a rendering issue when it is pulling all the data from the G-Code.

Your rendering looks different from crispy1's rendering in different software. And it is different from what I got viewing it 2D in pronterface. There are other examples in this forum of renderings not corresponding to the gcode. It happens.

Those are different files he generated for me.

[www.dropbox.com] - TT1

[www.dropbox.com] - TT2

Edited 1 time(s). Last edit at 11/24/2013 11:12PM by tjb1.

Anybody else run into this? [github.com]

Quote

Anybody else run into this? [github.com]

Apparently the "avoid crossing over perimeters" option can cause a 10-fold increase in slicing time... Whodathunk.

A couple more issues I've run into... [github.com] and [github.com]

Also not impressed with support in RC1. It's using far more material than is necessary, it will be very difficult to remove. The edge of support is right up against the object, so it will bond to the object.

Most importantly, enclosing the support in an outer perimeter makes it impossible to remove in some circumstances.

0.9.10b support:


RC1 support:


This example shows support that will be impossible to remove due to the outer "sheath" that is created in RC1:


Object without support, for reference: