Slic3r 0.5.7

Hello everybody,
this is to let you know that 0.5.7 is out and ready for download on [slic3r.org].

You can read the list of changes on the home page, however the key news are better solid surfaces (they were a bit sparse in 0.5.6) and a "Slice and save as..." command to choose the output filename. Many other things, though.

Enjoy!

Will be trying this new version over the next few days. Keep up the good work.

Edited 1 time(s). Last edit at 12/22/2011 06:47PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Thanks! I will give it a try tonight and compare.

Nice job

---

[richrap.blogspot.com]

Amazing job. I will check it out tonight.

Thanks,
Sean

I just printed a thing I designed, and it is really nice! This release is really good, and could be called 1.0.

Congratulation, this is great job. Thanks for making such powerfull tool!

---

Frédéric

I have printed quite a few different things with 0.5.7 now and it's working really well, but if I had to make an observation on the output I would say the objects are just a tiny little too stuffed now. Version 0.5.6 was leaving gaps and had low infill, for me 0.5.7 is ever so slightly over stuffing my prints. Other than that I can hardly tell the difference from a well tuned Skeinforge V46 Print.
And I would say Slic3r seems to take better (more sensible) paths than Skeinforge with many objects.

The only main thing stopping me switching over to Slic3r completely now is a minimum layer time setting as per the Skeinforge 'Cool' tab.
If Slic3r could have a box to enter a minimum layer time now that would really help out when printing.

I had one question - Does Slic3r decide on the WOT (Width over Thickness) by the user entering the nozzle size? I thought that was what was going on with the last release as I fudged the infill a little by lowering the nozzle size. Skeinforge needs the user to tune the solid fill (WOT) for any given nozzle size. I only ask as I'm about to start testing Slic3r with different nozzle sizes and also lower layer heights and was interested on how this was being done.

Other than that, Cracking release! I'm a big Slic3r fan! This is getting very close to 'Tool-Chain-Heaven'

Cheers,

Rich.

---

[richrap.blogspot.com]

Hi i am a German

I test whis [www.thingiverse.com]
I take the last Weeks Slic 0.5.5b an Slice the 0.5mm thin wall and the Programm give me an Gcode, its OK
Than i take the Slic3r 0.5.7 Version, and the same Slice the 0.5mm thin wall and the Programm give NOT an GCode, it is an Bug !
Only what the Programm make is, slicing 0,1 Sec and reddy,"


Manny stl Files from this [www.thingiverse.com] can i NOT make an G Code !
Other STL can Slice and i became an Gcode whis Version 0.5.7 and it works !
Can you help me ?


The Codeinfos
07:27:59.399 : ==> PROCESSING SLICES:
07:27:59.399 : Making surfaces for layer 0:
07:27:59.415 : Making surfaces for layer 1:
07:27:59.415 : Making surfaces for layer 2:
07:27:59.431 : Making surfaces for layer 3:
07:27:59.431 : Making surfaces for layer 4:
07:27:59.431 : Making surfaces for layer 5:
07:27:59.446 : Making surfaces for layer 6:
07:27:59.446 : Making surfaces for layer 7:
07:27:59.462 : Making surfaces for layer 8:
07:27:59.462 : Making surfaces for layer 9:
07:27:59.462 : Making surfaces for layer 10:
07:27:59.477 : Making surfaces for layer 11:
07:27:59.477 : Making surfaces for layer 12:
07:27:59.477 : Making surfaces for layer 13:
07:27:59.493 : Making surfaces for layer 14:
07:27:59.493 : Making surfaces for layer 15:
07:27:59.509 : Making surfaces for layer 16:
07:27:59.509 : Making surfaces for layer 17:
07:27:59.509 : Making surfaces for layer 18:
07:27:59.524 : Making surfaces for layer 19:
07:27:59.524 : Making surfaces for layer 20:
07:27:59.524 : Making surfaces for layer 21:
07:27:59.540 : Making surfaces for layer 22:
07:27:59.540 : Making surfaces for layer 23:
07:27:59.555 : Making surfaces for layer 24:
07:27:59.555 : Making surfaces for layer 25:
07:27:59.571 : Exporting GCODE file...
07:27:59.571 : Done. Process took 0 minutes and 0.577 seconds
07:27:59.571 : Filament required: 0.0mm (0.0cm3)

And the output GCode
; generated by Slic3r 0.5.7 on 2011-11-28 at 07:27:59

; layer_height = 0.40
; perimeters = 3
; solid_layers = 3
; fill_density = 0.3
; nozzle_diameter = 0.5
; filament_diameter = 2.92
; perimeter_speed = 30
; infill_speed = 30
; travel_speed = 100
; extrusion_width_ratio = 0
; scale = 1

M104 S17 ; set temperature
M105 ; Dummy command

M109 S17 ; wait for temperature to be reached
G90 ; use absolute coordinates
G21 ; set units to millimeters
G92 E0 ; reset extrusion distance
M82 ; use absolute distances for extrusion
M105 ; Dummy command

; filament used = 0.0mm (0.0cm3

Michael

Edited 1 time(s). Last edit at 12/28/2011 01:33AM by Hardwarekiller.

richrap Wrote:
-------------------------------------------------------
> Version 0.5.6 was leaving gaps and had low
> infill, for me 0.5.7 is ever so slightly over
> stuffing my prints.

Hey Rich, the funny (or not so funny) thing is that for each version there's some people reporting too much extrusion, and other too few. For 0.5.7 I got almost all good reports, except for some infill/perimeter terminal overlap that needs to be a bit tuned. Did you try to adjust the Extrusion Multiplier option by lowering it? it's a factor applied to the flow amount; it's sort of a "packing density" setting, and most people set it to 0.95 or so to compensate for die swell. Also, make sure that your filament diameter is measured exactly with a caliper (I know you're not a newbie I'm telling it for sake of completeness and for other users interested in this).

> The only main thing stopping me switching over to
> Slic3r completely now is a minimum layer time
> setting as per the Skeinforge 'Cool' tab.

This will come, it's in my plans. I'm collecting ideas and community input in the apposite thread here in the Slic3r forum.

> I had one question - Does Slic3r decide on the WOT
> (Width over Thickness) by the user entering the
> nozzle size?

You can enter a WoT manually in the Extrusion Width Ratio option (Advanced options tab). Say you enter 1.5 and you have a 0.3 layer height, the extrusion width will be 0.45 of course. However, Slic3r features an automatic extrusion width calculation that is triggered by leaving the Extrusion Width Ratio to zero. This automatic extrusion width takes several factors into account, the most notably one being the nozzle diameter. The underlying reason is that [I believe] for each nozzle size there's an optimal range of extrusion widths. This triggers some discussion, however it's been reported to produce very sane values.

> Other than that, Cracking release! I'm a big
> Slic3r fan! This is getting very close to
> 'Tool-Chain-Heaven'

wow!

Hardwarekiller Wrote:
-------------------------------------------------------
> Than i take the Slic3r 0.5.7 Version, and the same
> Slice the 0.5mm thin wall and the Programm give
> NOT an GCode, it is an Bug !

No, it's not a bug. Support for thin walls is a feature that hasn't been implemented yet.

Sound Wrote:
-------------------------------------------------------
> richrap Wrote:
> --------------------------------------------------
> Hey Rich, the funny (or not so funny) thing is
> that for each version there's some people
> reporting too much extrusion, and other too few.
> For 0.5.7 I got almost all good reports,

I did have a play with the Advanced tab and also the extrusion multiplier, and with a tiny fudge I have perfect filling, I think this nozzle maybe slightly out of 0.5mm.

It seems perfect with solid, loose and hollow printing so I'm very happy and it's now identical to my Skeinforge prints.

I'm messing with tiny layers now and have one more question -

below all being Sliced using 3 solid layers and 25% infill.

If I slice an object (simple hollow triangular tube with a 0.9mm solid bottom) at 0.3mm layers I get a filament used of - ; filament used = 1555.2mm (9.5cm3)
If I slice the same object again at 0.1mm layers I get more filament used - ; filament used = 1593.0mm (9.7cm3)

I expecting the exact opposite, I would have thought that the3 x solid layers (0.9mm) using 0.3mm layers would use up more filament than the 3x 0.1mm solid layers (0.3mm solid, +25% infill for 0.3, +0.3 solid).

If I then slice the same object at 0.01 (Ten microns) it uses even more plastic - ; filament used = 1615.7mm (9.9cm3) I would have thought this would use slightly less than the 0.1?

Am I just being dim and missing something or is this wrong? The walls of the object are identical all the way up so it makes identical Gcode for every layer other than the base (being 0.9mm solid)

I have not printed it yet, just wondering about the way the total length is calculated in Slic3r,and if it's correct.

Cheers,

Rich.

---

[richrap.blogspot.com]

richrap Wrote:
> I have not printed it yet, just wondering about
> the way the total length is calculated in
> Slic3r,and if it's correct.

That's a challenging question :-)
The filament length is calculated by just summing all the E values from the G-code file before each reset of the E axis. This is what other software, like Pronterface, do and it gives exact values. Why this happens is a good question, but it doesn't concern me at all, since a lot of things can change as a consequence of changing layer height including toolpaths and extrusion math. Not a problem at all.

See this video from Spacexula: [www.youtube.com] printing at an unbelievable layer height. :-)

Quote

most people set it to 0.95 or so to compensate for die swell.

Die swell does not alter the volume of plastic extruded, it just makes it come out fatter and slower when extruded into mid air. It doesn't affect the maths but it allows you to extrude bigger filament or if you keep it the same size it gets stretched more, leading to more hole shrinkage.

---

[www.hydraraptor.blogspot.com]

No worries, I do a similar (but very messy) thing to work out plastic usage for layer selective colour printing, I'll double check it out with a really simple object at some point. I would still like a nice little program to split Gcode into filament used per layer, but I'm not a great PC programmer, only embedded stuff, so that'll need to wait.

It was that video and this blog post that prompted me to finally play with lower layers, it really is very easy with Slic3r, I'll let you know how they turn out, it's going to be a long print....

Cheers,

Rich.

---

[richrap.blogspot.com]

Sound Wrote:
-------------------------------------------------------
> Hardwarekiller Wrote:
> --------------------------------------------------
> -----
> > Than i take the Slic3r 0.5.7 Version, and the
> same
> > Slice the 0.5mm thin wall and the Programm
> give
> > NOT an GCode, it is an Bug !
>
> No, it's not a bug. Support for thin walls is a
> feature that hasn't been implemented yet.

Hi Thanks for the Info !

When make a Version i can Slice one Line Objekts ?


Hire an other Prob !

This ist an Belt Gear Pully, from
[www.thingiverse.com]
and i sliced whis sfact and print it
The Print iss ok

I can the Belt over the Pulley, ist all OK !

This the same Gear, i sliced whis all versions old and the last slic3r 0.5.7 and print it
The Print is NOT OK !


The Problem is hire !

1 all T5 bridge round
2 all T5 bridge iss not deep enough


I Belt can NOT over the Gear

Who iss the Problem ??

And a another question
At the moment i take as Firmware Sprinter
I wont change to Marlin
In the Marlin Firmware ask the Author the Diamander for the Firlament, is that an problem for the Slic3r ??
Why make that Marlin in the Firmware ?


Michael

Edited 1 time(s). Last edit at 12/29/2011 11:12PM by Hardwarekiller.

A couple of questions:

1. Is there a feed rate limit for z in slic3r? I noticed that the feed rate for z moves is quite fast in the g-code. The first layer move was done at the travel speed of 130 mm/s which is too fast for a Mendel. I know that the firmware (Marlin, Sprinter, etc) also has a limit, and with acceleration this speed will probably not be reached. But on combined x, y and z moves, could this pose a problem?

2. How can I see statistics on plastic used, printing time etc?

Hi, User Sound !

Can you give me an answer of my question ?

Thanks !



Michael

I finally got to play with this tonight and all of it's features seem to work really well so far.

That being said, I have a list of suggestions I would love to see implemented

Have a "Save as default profile" button in the GUI

Make every 'island' perimeter start from the same place. ie: lower left corner. Parts look better without the tiny layer change blobs arbitrarily scattered about.

Option to prefer starting/ending a perimeter where there is not any overhang.

I think the outermost perimeter should be printed before the inner ones (or at least give the option somewhere)

Cool (already mentioned)

And of course, support generation (also mentioned)

Also, I've found smallish internal circles around 8mm diameter sometimes do not have their perimeters meeting up and are leaving gaps (~.5-1mm)

THANKS for the hard work!

---

www.Fablicator.com

Hey there,
I also have a problem with slic3r, the outline perimerter comes out really well, but the infill is never solid. I set the infill to 1, but I get prints like in this picture:


I also tried setting the solid layers to 1000, means that all layers should be printet solid, and infill is ignored, but this also did not work.

Fill pattern and solid infill pattern are set to rectilinear with 45°.

Any idea what I can do? Because the tunig options in slic3r are really limited.

Tarjak, Solid layers is really only meant to specify the caps on the part. I would not go any higher than 6 with this value. You want to set fill density to 1 for a solid part.

Side note, printed Yoda at .1mm layers, 2 perimeters, 10% fill, 1.5x scale:

Sliced in 6min, 32s.

---

www.Fablicator.com

Very nice Andrew,

What print speed and temperature did you use?

I have been having some issues printing lower than 0.1mm, I can't work out if it's temperature or speed related.

Is that pearlescent White PLA?

---

[richrap.blogspot.com]

50mm/s perimeter, 80 infill, 30 small perimeter. I think my acceleration/jerk are set to 4000mm/s^2 and 10mm/s respectively. Z is 30mm/s.

250C for the PLA. Makes bonding really strong, and at this size of an object part cooling is a non-issue. If you are printing a small part, the corners always seem to curl on me at this thickness.

It is just crappy natural PLA from esunpla. Actually got really lucky the part even finished, there was a big blob on the filament 20mm upstream when the part completed.

---

www.Fablicator.com

Thanks, I slowed down to 50mm/sec and I'm getting much better results at very low layers now. I'm thinking the bed needs to be very rigid to get good results below 0.1mm, I have a little flex and that's causing rubbing of the fine layers. I'll fix that now and it should be really good.

I never had much luck either with esunpla filament, the PLA is tricky to use and not very consistent and the ABS was a total disaster for me, I'm sure both the ABS and PLA have 'added' materials that make using it with printing much harder, but I could not get any info out of them about the real mix, maybe their new stuff is better?

---

[richrap.blogspot.com]

Andrew Diehl Wrote:
-------------------------------------------------------
> Option to prefer starting/ending a perimeter where
> there is not any overhang.
Agreed, perimeters are not treated as a bridge, and can cause some problems.

> I think the outermost perimeter should be printed
> before the inner ones
I disagree. Especially when printing serious overhangs it's best to print the inner perimeter first, as the outer perimeters sticks to the side of the previous loop, it's not much but I've gotten better prints when the order was changed.


I absolutely love slic3r! It's incredibly fast, it sliced this huge 5mb stl i less than 3 minutes! [www.thingiverse.com]

One question though, is it enough to make a shortcut to "slic3r.exe --gcode-arcs" to activate arc support?

---

--
-Nudel
Blog with RepRap Comic

I'm trying to print a couple of parts that look like a comb and it seems that slic3r refuses to retract during the infill phase when jumping from one "finger" to another. I tried reducing the Minimum travel after retraction parameter from 2 to 0.5 and it didn't make a difference. The gaps are 1.2 mm.





Edited 1 time(s). Last edit at 01/05/2012 08:19PM by brnrd.

@Hardwarekiller: I can't say anything about your dimension problem off the top of my head. It could be a flow issue, but I have no useful information to debug this. Perhaps someone can give that model a shot. Regarding your other question, Marlin works well with Slic3r. The filament diameter is requested in Marlin for the advance feature, which can be left off as I do; I can't give much help on that.

@brnrd: the Z feed rate should be limited by your firmware, not by your slicer. Check the max_feedrate option of your firmware and configure it so that no G-code could be harmful for your machine. Regarding your second question, when you load the G-code in Pronterface it will show the total length of required plastic as well as a pessimistic time estimate. I am aware of the missing retraction in that situation, and I will work on it soon.

@Andrew: I love that print! and thank you for the input, some of those features will be implemented some day.

@Tarjak: 1) make sure your firmware E steps are good, 2) make sure your filament diameter is exact and measured with a caliper, 3) make sure your Z = 0 (adjust endstop or the z-offset config option), 4) raise the extrusion multiplier.

@Nudel: invoking Slic3r with --gcode-arcs is sufficient to activate arcs. You can check that by searching for G2 and G3 commands in the resulting G-code. Beware that arc support is still experimental as I had no time to bring it from proof-of-concept to a stable state; other priorities kept me busy.

Is this the best place to put bug reports or should I leave comments in the git repo?

I've found a few situations where infill is outside the object's perimeter

---

www.Fablicator.com

How do you deal with circles, since in the stl format the tesselation decomposes them in triangles?

It's probably best to put them in the git repo also. I just put more information about the retraction bug there.

Put them in the GitHub issues only if you're familiar with it and provide complete information to reproduce issues (model, config.ini, G-code screenshot, print pictures...). Also, try to avoid duplicates. I actively use that tracker for my work. Posting things in this forum is fine too, as I keep watching it.

@Andrew: that issue is probably already entered in this ticket [github.com]

@Lanthan: Slic3r includes an algorithm to detect arcs from subsequent segments at the very last stage. Its purpose is, more or less, to save bytes in the resulting G-code by combining multiple segments into a single G2/G3 arc command where this won't visibly change the shape of the paths. The resulting better quality is a plus benefit, of course.

@Sound, about arcs: brilliant!

I tried running skeinveiw on slicer-generated gcode, it doesn't like it at all and dies. Probably it is because of the additional gcodes. Still, we'd benefit a lot for having a way to visually inspect the layers (apart of printing 'em) and might help by accelerating the debug cycle.