For prints with multiple islands, Slic3r will do the perimeter for one island, then move to the other and do its perimeter, then do its infill, and then move back to the first island. This much movement is unnecessary and can result in perimeter blemishes. For each island, it should do its perimeter first, and its infill, and only then should it move on to the next island. See http://techpaladin.com/wp-content/uploads/random/fbomb_plate_small.gcode

With Fill Density set to 0, Slic3r doesn't draw the first layer or any of the other number of solid layers you've specified. I think that it should. If not, then a setting whose effect would be "still draw top and bottom layers if Fill Density is 0" would be nice.

I don't know how useful (or achievable) this idea is.

The concept here is to allow the printhead to start moving before retraction is completed, so this retraction would occur after the printhead is moving.

Questions: Can the retraction occur at speed while the head is moving? What happens if the head gets where it's going before the retraction has finished?

I currently use start.gcode to insure that my printer is homed properly before starting a print. Because I use sjfw, which doesn't support home commands, this is somewhat complicated.

My start.gcode also makes sure that my hotend is up to temperature before allowing the print to begin.

My end.gcode retracts the filament, turns off the hotend, and homes X and Y.

This is hard to explain, but, this model, sliced on Windows w/ 11/4 build: http://www.thingiverse.com/thing:7047

This is the one that I believe drove him to add nearest point search outside of perims, and that's not reflected yet, so yes there is lots of travel from point to point. However, more concerning is that within each "pad" of the bracelet that gets laid down at the beginning, there is a ton of tiny movement and jitter, resulting in EXTREMELY long print time, and a Y axis motor that felt like it was going to burst into flames (never had an issue with it before).

So, I don't know how to explain what is going on, other than maybe to see it, or whether maybe it's related to nearest points bug (but again this happens inside an island). I had to cancel the print based on time and fear for my poor motor ;)

Add a speed setting for inside perimeters, as opposed to infill.

Generally, I've found that if I'm using multiple perimeters, I want them to be accurate, rather than fast, but I don't care where infill lands.

Whenever I print an object that has even the smallest of bridges, the plastic droops instantly. It almost seems like its dumping more plastic over bridges instead of less.

Here are a couple of pictures comparing a 1" long bridge in Slic3r and SFACT
Slic3r: https://picasaweb.google.com/115959673036406323701/Reprap?authkey=Gv1sRgCJGts42r3ZLbiQE#5674001681301574098

SFACT: https://picasaweb.google.com/115959673036406323701/Reprap?authkey=Gv1sRgCJGts42r3ZLbiQE#5674006469683640770

http://www.thingiverse.com/thing:12990

When slicing with 0.15, a solid surface is rendered in the hole on the top layer. This doesn't happen with the default layer height or even with 0.155.

reported by @Joaz

Model at: http://www.thingiverse.com/thing:12108

Errors out with invalid parameter, tried all four models. I don't have the knowledge to extract and test daily, so this is with the 11/4 build :)

When generating infill for a narrow gap (one that is wider than one filament, but narrower than two), center the filament within the gap, and adjust the filament width to compensate.

I've tried to slice http://www.thingiverse.com/thing:7013 several times now with several of my Slic3r profiles—including the default settings—using the version of Slic3r released on 11/04/11, with no luck. What happens is that as soon as I tell it to slice the file, it will immediately report success but produce an obviously bogus gcode file. Nothing is printed to the console. Here's the gcode file it creates with the app's default settings:

M104 S200 ; wait for temperature to be reached
G28 ; home all axes
G90 ; use absolute coordinates
G21 ; set units to millimeters
G92 E0 ; reset extrusion distance
M82 ; use absolute distances for extrusion
M104 S0 ; turn off temperature
G28 X0 ; home X axis
M84 ; disable motors

Model here: http://www.thingiverse.com/thing:13408

Model prints mostly fine (way better than SF :) ), but below each pillar for 1 or 2 layers there is space left in in the infill. It actually tries to print the outlines of the columns as if they are inset into the model versus starting at the surface layer. Similar thing happens with Hollow Pyramid Short on thingiverse.

This is 11/4 build!

Add a height parameter to Skirt, so that it can be used for its original purpose, which was to hold heat in around the print to reduce warping.

Alternatively, replace the skirt with a prefix print which is defined only by its length, and which circles the print ending up a short distance from where the print will start.

Layer(s) before/after open areas are not (or perhaps not always) filled 100%. Sample files emailed.

http://blog.reprap.org/2011/10/say-goodbye-to-unsightly-stl-triangle.html

The "Slicing…" window totally locks up the entire UI as soon as it appears. It should probably be threaded or something.

...to optimize travel moves

Slic3r inserts an M104 command as the first line of every gcode file it generates:

M104 S185 ; wait for temperature to be reached

[ beginning of my start.gcode]

G1 E30 F300 ;Prime extruder 30mm
G28 ; home all axes

[ end of my start.gcode ]

G90 ; use absolute coordinates
G21 ; set units to millimeters
G92 E0 ; reset extrusion distance
M82 ; use absolute distances for extrusion
G1 Z-0.825 F18000.000 ; move to next layer
G1 X58.938 Y56.873 ; move to first skirt point
G1 F1080.000 E1.00000 ; compensate retraction
G1 X59.118 Y56.723 F3000.000 E1.00279 ; skirt
G1 X60.108 Y55.923 E1.01795 ; skirt
G1 X60.238 Y55.813 E1.01998 ; skirt

However, M104 does not wait for the temperature to be reached. M109 does that. M104 sets the temperature and them immediately executes the next command. Thus, the hardcoded M104 command should be an M109.

I was printing the Vanderbilt Mansion (http://www.thingiverse.com/thing:10485) and in two places, many layers of infill were printed in the interior where they really didn't seem to be needed and can't even be seen once the print is done.

In this recording of the individual layers, you can see it at about the 15 and 29-second marks:
http://youtu.be/DLO3Mr_X_8w?t=15s

Here's the profile I used: http://pastebin.com/1PPKarx4

… And here's a zip of the profile, .stl, and generated .gcode file: http://techpaladin.com//wp-content/uploads/random/vanderbilt_issues.zip

Definition: a thin wall is a part of your model whose thickness in the XY plane is <= extrusion width.

Slic3r currently ignores them and produces no extrusion. This is because it tries to draw an outline for the part (that is, 2*extrusion width). We need an algorithm to detect these parts and one to generate a single-path extrusion for them

Detection of thin-walls: inset polygons, then outset them again, and do the difference between the original ones and the result; what's missing are thin walls.

Now the question is: given a thin polygon (with variable thickness and direction), how can we detect its backbone?

I like to print infill every other layer to save time, but I've noticed that in this circumstance, the infill is printed very sparsely; often an infill line will barely touch the lines under it. In cases where I use a very small layer height like 0.08 and print infill only every three or four layers, the infill can break down entirely. Here's a picture that illustrates the layers of infill barely touching the ones beneath them with 0.15 mm layers and infill every other layer: http://www.flickr.com/photos/18245812@N00/6339039117/

Here's the profile I used: http://pastebin.com/1PPKarx4

… And here's a zip of the profile, .stl, and generated .gcode file: http://techpaladin.com//wp-content/uploads/random/vanderbilt_issues.zip

It seems like the flow rate of the infill needs to be increased a bit to ensure that enough of it is laid down in a way that it can properly support the next infill layer.

Settable either as a ratio based on layer height, or as a fixed value in mm.

Advanced option - not normally visible.

This picture shows the top of the F-Bomb model:
http://www.flickr.com/photos/rgoodwin/6330312473/in/photostream

from thingiverse: http://www.thingiverse.com/thing:12812

The top of the "top" should have filled complete, but didn't. Rest of print seems quite good, with little surface error, but maybe some thickness variance in the "top" outer walls.

Right now the only way to cancel slicing if you realize you've made a mistake is to force-quit the program. The "Slicing…" window needs a cancel button.

Replace the "High-res Perimeters" option with a value which specifies the ratio between perimeter layers and fill layers - a value of 4 would quadruple the vertical resolution of the perimeter.

It would be great if the "Slicing…" window's progress bar was of the determinate type so you could estimate about how far it's gotten.

Separate "Multiply along X", "Multiply along Y" and "Distance:" into a separate grouping named "Duplicate:"

Rename "Multiply" to "Copies".

Eliminate the backward logic of "Packing Density", and make it logical.

Change "Packing Density" to "Extrusion Multiplier", which is computed in exactly the opposite way, to eliminate the confusion of larger number = less extrusion.

Also has the advantage of being a nod to what people actually use "Packing Density" for - to correct their bad calibration.

@triffid suggested 15%.

Or at least tell the user he/she should repair the model when Slic3r is not able to process it, instead of only throwing out internal errors

please see http://triffid-hunter.no-ip.info/slic3r-bug-report-001.tar.lzma

contents:
git_head.txt
x-ends-both-lm8uu-M8-x1.stl
config.ini
x-ends-both-lm8uu-M8-x1.gcode

problem areas:
the skin in the nut traps (layer [email protected]). slic3r detects these as a separate part, and produces unprintable gcode that would leave the nut trap full of dribbles, instead of bridging.

the bridge layer at the top of the smooth rod holes (layer [email protected]). One layer below this, slic3r seems to turn the perimeters inside out, and fills the empty spaces in the nut trap and the central hole in x-end-idler, and leaves the body unfilled and untouched.

about 2/3 of the way up, two layers before the bottom of the top motor mount nut trap (layer [email protected]), the lm8uu holder on the x-end-motor has one complete layer missing.

I have fed this exact same STL to both skeinforge and webskein, neither of them slice those layers in this way so I suspect that this is a bug in slic3r's slicing code rather than a bad STL.

Having said that, webskein does complain about the paths on layers 66 and 213, and automatically applies a slight offset and slices again to get good paths so presumably there are triangles coplanar to the slicing plane at these layers that cause some of the issues.

I was printing the Vanderbilt Mansion (http://www.thingiverse.com/thing:10485) and in three places, infill was printed instead of solid top layers: http://www.flickr.com/photos/18245812@N00/6339822988/

You can also see it a little after second 18 in this recording of the individual layers: http://youtu.be/DLO3Mr_X_8w?t=18s

Here's the profile I used: http://pastebin.com/1PPKarx4

… And here's a zip of the profile, .stl, and generated .gcode file: http://techpaladin.com//wp-content/uploads/random/vanderbilt_issues.zip

A setting which would describe the usable print area (X, Y and Z) of the printer, so that a warning could be generated when the user attempts to print something too large.

Just like Extrusion Width and Extrusion Spacing, except only for the outer layers.

After I click slice and select a file, I get a dialog saying Can't locate object method "Pulse" via package "Wx::ProgressDialog" at /home/triffid/Projects/Slic3r/lib/Slic3r/GUI/SkeinPanel.pm line 115.

Clicking OK on this dialog takes me back to the gui, no slicing occurs.

Slic3r $ git log | head
commit 6d65338
Author: Alessandro Ranellucci [email protected]
Date: Thu Oct 20 18:11:59 2011 +0200

New experimental --gcode-arcs options to generate G2/G3 commands. #23

I've found that at moderate speeds (50 mm/sec and above), drawing the exterior perimeter first can cause surface blemishes because the filament within the nozzle may not be entirely in position to be extruded following retraction. Here are some examples:

http://techpaladin.com/wp-content/uploads/2011/11/exterior.jpg

http://techpaladin.com/wp-content/uploads/2011/11/wall.png

http://techpaladin.com/wp-content/uploads/2011/11/interior-loop.jpg

The smaller the island and the more retractions before the next layer starts, the bigger the problem. I hesitate to recommend simply drawing exterior perimeters last, since drawing them first definitely results in a nicer finish in places where this problem doesn't manifest. Perhaps a little extra extrusion over an infill part to prime the extruder for putting down enough filament?

Here's the profile I used: http://pastebin.com/fyZci3sM

Add "Extrusion width:" and "Extrusion spacing:" to the accuracy panel, as advanced options.

The two would be tied to each other, with changes to one being reflected in the other.

If I had to choose between one or the other, I'd rather see extrusion spacing.

In skeinforge, Extrusion spacing = Extrusion width / 1.272.

Note: When printing a 2mm wide rectangle with an extrusion spacing of 1/3mm (or extrusion width of .424), and 2 extra shells, Skeinforge lays down exactly 6 filaments, with equal spacing between them. This implies that the finished part will be about 1/10mm wider than expected, which could explain a small part of the issues we have with hole diameter in skeinforge.

We need hexagonal fill.

Also we could implement some of these: http://user42.tuxfamily.org/math-planepath/gallery.html

which will be filled anyway.

That's what @Joaz suggested.

I'm ambivalent on this one - the idea is to provide a popup which would change the behavior of Slic3r based on which firmware was in use (i.e. Relative E) rather than having the user tick checkboxes for each alteration that a given firmware needed.

The problem is that Slic3r would have to be updated for any new firmware, or the Relative E checkbox would have to be available regardless.

Perhaps a popup which just sets Relative E, and leave the checkbox there?

...instead of Z = 0 like it is currently.

@blddk's idea

The arc g-codes G2 and G3 I and J values need the offset to the center point. Not the absolute position.

On multiple Mac OS X machines (a 1 year old Mac Mini and a new MacBook Air) I've tried it on, the version of Slic3r released on 11/04/11 is frequently hanging for long periods of time, especially when slicing objects at small layer heights. Examining the console log reveals that it will ususlly hang while slicing a certain layer. For example, while trying to slice the Vica Illusion Sculpture into 0.15 mm layers, Slic3r hung for 15 minutes on layer 645:

11/10/11 6:43:49.767 PM [0x0-0x99099].Slic3r Making perimeter for layer 643:
11/10/11 6:43:49.767 PM [0x0-0x99099].Slic3r Making perimeter for layer 644:
11/10/11 6:43:49.767 PM [0x0-0x99099].Slic3r Making perimeter for laye
11/10/11 6:44:22.000 PM kernel macx_swapoff SUCCESS
11/10/11 6:59:59.000 PM kernel (default pager): [KERNEL]: ps_select_segment - send HI_WAT_ALERT
11/10/11 7:00:00.000 PM kernel (default pager): [KERNEL]: Switching ON Emergency paging segment
11/10/11 7:00:06.000 PM kernel (default pager): [KERNEL]: ps_vstruct_transfer_from_segment - ABORTED
11/10/11 7:00:06.000 PM kernel (default pager): [KERNEL]: Failed to recover emergency paging segment
11/10/11 7:00:06.000 PM kernel macx_swapon SUCCESS
11/10/11 7:00:22.190 PM [0x0-0x99099].Slic3r r 645:
11/10/11 7:00:22.190 PM [0x0-0x99099].Slic3r Making perimeter for layer 646:
11/10/11 7:00:22.190 PM [0x0-0x99099].Slic3r Making perimeter for layer 647:

That's a 15 minute hang! You can see that my system ran out of physical memory from the kernel logs! It eventually ate up 1.5 gigs of RAM. There was another 4-minute hang later, too.

Here's a link to a zip file containing the console log, my profile, two samples of the process while it was hung, the source .stl file, and the resulting .gcode file:

http://techpaladin.com//wp-content/uploads/random/vica_problems.zip

Rationale: my bed has surface imperfections up to 0.1mm high, but I want to print models at 0.05mm.

With skeinforge I print my first layer at 0.2mm by massaging bottom:altitude and raft:first layer flow.

Please add a first layer height to the first layer tunables like speed, perhaps a ratio so nothing bad happens if it's left untouched.

Every time you open the app, it displays the default settings. It should instead load the last active config file at launch so you don't have to do this manually.