Gaps in sloping sides; extra perimeters insufficient

[ericu]

This model has slopes at a variety of angles. I set perimeters=2, generate extra perimeters when needed to true, and top solid layers to 3. When I print, there are gaps in the slopes, as shown in the attached photo.

It looks to me like Slic3r is depending on perimeters to seal the top surface, and that the code that generates extra perimeters is failing. So clearly there's a bug here, but I also think that it's going about it wrong. If I set top_solid_layers to 3, I expect that, if I drill vertically down through the model /anywhere/, whether it be on a perfectly flat surface or a slant, I should have to go through at least 3 layers to get to the interior. I shouldn't have to make the walls super-thick to make the top surface solid. Slic3r should figure out where a layer is smaller than the one below, recognize the need for a top surface, and propagate that knowledge down by top_solid_layers to get the right minimum thickness.

My config, stl, gcode, and a photo are at https://docs.google.com/folder/d/0B1PhG4uhITMmbm9XWmJwVEFMMjA/edit

Here's the photo again, just for convenience:

I'm using 0.9.8-dev, built out of the git repo a couple of days ago, at commit cf8390b5d32ac1ae1afecdf01b9976e0316ae5c3, on Linux [Debian Squeeze].

You'll note that I printed this at pretty high speed; it didn't seem to make a difference at all when I slowed things down.

[alranel]

Hello, I think this was fixed by the recent commits 5930267de9c2cb731d0e641a74e294b67900c537 and 15f07197d8bbdabdad3b1d57907983ffc7108252. Do you have any chance to test with the current git version?

[ericu]

I'll be away from my printer for the next week and a half, but will try it after that and let you know. Thanks!

[ericu]

It looks much better than it did, but it's not totally fixed. I updated to commit a633180518ebfe2ec1805aa9d63cc9c9f4c00ccb and tried a couple of prints. Here they are. The second print [the last two photos] all I changed was to turn off lift-on-retract and lower retract from 1.5mm to 0.7mm. I'm not sure why it's so much worse.

[ericu]

BTW here's the config from the first of those two prints.

generated by Slic3r 0.9.8-dev on Thu Jan 3 13:10:05 2013

acceleration = 0 bed_size = 200,250 bed_temperature = 0 bottom_solid_layers = 3 bridge_fan_speed = 100 bridge_flow_ratio = 1 bridge_speed = 130 brim_width = 0 complete_objects = 0 cooling = 1 disable_fan_first_layers = 12 duplicate = 1 duplicate_distance = 6 duplicate_grid = 1,1 end_gcode = ; Start custom footer\nM104 S0 ; turn off temperature\nM140 S0 ; turn of HBP\nG91 ; switch to relative coords\nG1 Z30 F1000; drop the platform by 30mm\nM84 ; disable motors\n; End custom footer external_perimeter_speed = 30 extra_perimeters = 1 extruder_clearance_height = 20 extruder_clearance_radius = 20 extruder_offset = 0x0 extrusion_axis = E extrusion_multiplier = 0.88636 extrusion_width = 0.5 fan_always_on = fan_below_layer_time = 60 filament_diameter = 1.75 fill_angle = 0 fill_density = 0.1 fill_pattern = rectilinear first_layer_bed_temperature = 0 first_layer_extrusion_width = 0 first_layer_height = 0.3 first_layer_speed = 30% first_layer_temperature = 0 g0 = 0 gap_fill_speed = 40 gcode_arcs = 0 gcode_comments = gcode_flavor = reprap infill_acceleration = 50 infill_every_layers = 1 infill_extruder = 1 infill_extrusion_width = 0 infill_speed = 120 layer_gcode = layer_height = 0.25 max_fan_speed = 100 min_fan_speed = 35 min_print_speed = 10 min_skirt_length = 0 notes = nozzle_diameter = 0.35 only_retract_when_crossing_perimeters = 1 output_filename_format = input_filename_base([version]).gcode perimeter_acceleration = 25 perimeter_extruder = 1 perimeter_extrusion_width = 0 perimeter_speed = 60 perimeters = 3 post_process = print_center = 100,125 randomize_start = retract_before_travel = 2 retract_length = 1.5 retract_length_toolchange = 3 retract_lift = 0.8 retract_restart_extra = 0 retract_restart_extra_toolchange = 0 retract_speed = 10 rotate = 0 scale = 1 skirt_distance = 5 skirt_height = 1 skirts = 0 slowdown_below_layer_time = 15 small_perimeter_speed = 30 solid_fill_pattern = rectilinear solid_infill_below_area = 10 solid_infill_every_layers = 0 solid_infill_speed = 120 start_gcode = ; Start custom header\nG90 ; use absolute coords for xyz\nG21 ; units -> mm\nM82 ; use absolute coords for extrusion\nG92 E0 ; reset extruder offset to zero\nG28 ; go home\nG92 X0 Y0 Z0 ; reset xyz offsets to zero\nG1 F5000 X30 Y60 ; step away from the corner\nG1 X220 ; step off the edge\nG1 F100 E10 ; prime the extruder\nG28 ; go home, wiping the extruder tip\nG92 X0 Y0 Z0.15 E0 ; call this home, but cheat down Z\n; End custom header support_material = 0 support_material_angle = 0 support_material_extruder = 1 support_material_extrusion_width = 0 support_material_pattern = rectilinear support_material_spacing = 2.5 support_material_speed = 60 support_material_threshold = 45 temperature = 0 threads = 2 toolchange_gcode = top_solid_infill_speed = 60 top_solid_layers = 3 travel_speed = 300 use_relative_e_distances = 0 vibration_limit = 0 z_offset = 0

[mesheldrake]

The remaining gaps there are due to the zig-zag path in the slow-sloping region, right? We're mostly seeing through where the filament won't fit into the sharp corners.

The model is pretty low-res and that messy section is a fairly faithful reproduction of what the geometry is really doing. Here's a plane intersecting the model at the z level of the problem region:

A higher res model would result in straighter lines through that section, eliminating the sharp corners that produce little gaps.

Slic3r is detecting that the region in question needs extra solid layers, as you expect it to. This is done with a region of solid infill rather than extra perimeters. The problem with doing that as extra perimeters is that those perimeters would loop around the entire object over to regions that don't need them, like this:

Instead Slic3r just does solid infill where it detects an impending top surface above:

If you're getting those solid surfaces in that region, then I think Slic3r is doing about what you expect, even if it's not doing it with extra perimeters.

[ericu]

Mike:

Thanks for the really detailed response.

I certainly agree that top-surface is more appropriate than extra perimeters for filling those gaps. However, they're not quite getting filled. It's probably not all that clear in the photos, but it's still happening. I tried again today with really thin lines [0.25mm width] just to see if that helped, but it didn't. Take a look at this one:

Those gaps on the top surface aren't just local flaws--they go all the way through the surface. If you look through there, you can see inside the shape.

Contrast it with this print:

That was done on a Cube printer. See how smooth and solid it looks? The surfaces have far less in the way of line artifacts, and there isn't a single hole. I doubt the Cube's hardware is significantly better than that of the M2, and I doubt the firmware has a huge effect on this at these speeds. So that leaves the slicer, given that the shape's the same. If the paths are all kinked and there are going to be odd bits that are hard to fill with simple curves, then perhaps slic3r should learn to extrude a slightly thicker line in those areas?

[mesheldrake]

I'm looking at the G code I got with this object and your config, and I'm not seeing problems quite in the places where your holes appear to be. Maybe this is a config issue with speed or retraction or something else, or maybe you're getting different G code output. ... Why is your extruder temperature set to zero? How do you control temperature on these prints? It kind of looks like things just get messy and stringy in the problem areas. Is it a temperature issue maybe?

[ericu]

On Fri, Jan 25, 2013 at 7:22 PM, Mike Sheldrake notifications@github.com wrote:

I'm looking at the G code I got with this object and your config, and I'm not seeing problems quite in the places where your holes appear to be. Maybe this is a config issue with speed or retraction or something else, or maybe you're getting different G code output.

I can certainly post my latest config and gcode if that would be useful.

Why is your extruder temperature set to zero? How do you control temperature on these prints? It kind of looks like things just get messy and stringy in the problem areas. Is it a temperature issue maybe?

I set the temperature manually, rather than do it in gcode. I'm printing at 185 on PLA 3034 from ProtoParadigm. It'll print at 180, but not at 175, and 185 seems to be just a bit nicer than 180, so that's what I use for everything.

[mesheldrake]

I see that your most recent test report was done with commit a633180518ebfe2ec1805aa9d63cc9c9f4c00ccb.

Since then @alexrj has posted commit 4bff4d0d508990845450144f54c71659d36c9402, which specifically bans the low acceleration values you are using. I don't know the background on that, but I'd guess that's the issue here.

Try with acceleration set to zero, or a high value like 9000 (as suggested in the GUI).

[ericu]

On Sat, Jan 26, 2013 at 8:40 AM, Mike Sheldrake notifications@github.comwrote:

I see that your most recent test report was done with commit a633180https://github.com/alexrj/Slic3r/commit/a633180518ebfe2ec1805aa9d63cc9c9f4c00ccb .

Since then @alexrj https://github.com/alexrj has posted commit 4bff4d0https://github.com/alexrj/Slic3r/commit/4bff4d0d508990845450144f54c71659d36c9402, which specifically bans the low acceleration values you are using. I don't know the background on that, but I'd guess that's the issue here.

Try with acceleration set to zero, or a high value like 9000 (as suggested in the GUI).

I can find no place in the gui that corresponds to those settings. I didn't set them intentionally; the sample file I was building on had them that way. Where in the GUI should they be? I just loaded a slic3r with and without those numbers changed to zero, walked through what I think was the entire interface, and compared field by field, and they all matched.

Anyway, I'll try a print with the new config and let you know what happens.

[ericu]

I tried it--there's no noticeable improvement. I've still got a bunch of holes all the way to the interior.

I've uploaded the config and the output gcode to the google directory linked above [https://docs.google.com/folder/d/0B1PhG4uhITMmbm9XWmJwVEFMMjA/edit]; the files are called M2PLAForMoebiusSliceThinFixed.ini and moebius_slice_accel_fix.gcode.

[mesheldrake]

In the "fixed " gcode you posted, the config report at the end shows that you still have the infill_acceleration and perimeter_acceleration settings set to the those too-low values of 50 and 25.

I'm guessing that you didn't find the acceleration settings because they require you to scroll down on the speed settings page. I missed this myself the first few times I looked at it.

So look again here:

Print Settings tab Speed scroll down probably There's the "Acceleration control (advanced)" section there at the bottom. Find it?

[ericu]

On Sat, Jan 26, 2013 at 5:21 PM, Mike Sheldrake notifications@github.comwrote:

In the "fixed " gcode you posted, the config report at the end shows that you still have the infill_acceleration and perimeter_acceleration settings set to the those too-low values of 50 and 25.

I see what you're talking about in the gcode, but I'm setting them to 0 in the config file, so that's something that slic3r must have decided. I just sliced it again, just to make sure I'd used the right config, and those magic values appeared out of nowhere again.

I'm guessing that you didn't find the acceleration settings because they require you to scroll down on the speed settings page. I missed this myself the first few times I looked at it.

So look again here:

Print Settings tab Speed scroll down probably There's the "Acceleration control (advanced)" section there at the bottom. Find it?

Nope. It doesn't exist in the version I'm running. There's a speed tab and an an advanced tab, but no "Acceleration control (advanced) under speed. Did it go in since the commit to which I synced, perhaps?

[mesheldrake]

Alright - I don't know what I'm talking about. Looks like the GUI option came in five commits later. It was previously just a command line option. And it looks like if the plain acceleration setting was 0 the other specific acceleration settings were disabled anyway, leaving your firmware totally in charge of acceleration. (The current release version 0.9.8 incorporates the latest acceleration-related updates, including the GUI access to the settings.)

Looks like we're no closer to figuring out cause of the remaining holes.

It could be the acceleration setting in your firmware. I'm seeing different values between MakerGear Sprinter config and Sprinter on GitHub default config.

It could be toolpath problems from Slic3r, but from the photos it doesn't look like the holes are all in places where the G code preview suggests problems might occur - or can you see a correspondence?

Anyone else have ideas on this?

[mesheldrake]

Here's a scaled and positioned version of the model, if anyone else wants to help look at this: http://sheldrake.net/bag/moebius_slice_scaled.stl

[ericu]

OK, another thing just occurred to me, based on the surface texture.

I've been thinking that my machine was perfectly calibrated because I went through https://github.com/alexrj/Slic3r/wiki/Calibration. However, depending upon how Slic3r makes its decisions, that guide may be wrong. Does Slic3r take into account the fact that it's laying down a flattened ellipsoid, rather than something with a rectangular cross section?

That guide has one print out a single-walled box, then measure the side width. So if you tell Slic3r to print 0.4mm traces, you're measuring to the very outer edge of a curve [see https://docs.google.com/drawings/d/1FddWDfmzswmX2zvXKDwYIKrPIoazgzlpzB8wvIFsRAE/edit for what I mean]. So if Slic3r doesn't take this into account, and I tell it to print a flat surface with 0.4mm line width, you'd expect the surface to be bumpy, as it would lay these curved objects /just/ touching. Whereas if it's smart about the curves, it'd realize that it should extrude a bit more when trying to do something that wasn't single-walled, so as to fill in the valleys between the tops of the traces.

Looking at my config, I see I have "extrusion_multiplier = 0.88636", which is suspiciously similar to the 0.87 that comes from the diagram linked about. Am I just under-extruding?

If Slic3r doesn't take the curvature of the trace into account, you'll need to adjust the extrusion_multiplier every time you change level thickness or line width, as the difference between the area of the curved trace and that of a rectangular trace will change based on its proportions.

[ericu]

On Sat, Jan 26, 2013 at 10:55 PM, Mike Sheldrake notifications@github.com wrote:

It could be the acceleration setting in your firmware. I'm seeing different values between MakerGear Sprinter config and Sprinter on GitHub default config.

BTW I'm using the M2 Marlin: https://groups.google.com/forum/?fromgroups=#!topic/makergear/rms7Q0z9giA

[mesheldrake]

Slic3r models the extrusion as a "rectangle with [possibly squished] semicircles at the ends" and interrelates that to layer height, speed and all that. So you can do something like change layer height and not worry about changing other settings. The extrusion flow rate will be calculated automatically to account for the new height. Or change speed. Same thing.

Consider that lots of people are getting excellent prints with machines calibrated with the given procedure. That's why I think it's more likely that your issue is related to the geometry of that model, which is either exposing an uncommon issue in Slic3r, or an issue with your firmware or hardware.

[mesheldrake]

I was able to reproduce your hole problem.

Your infill was set to 0.1. The top solid layers had almost nothing to rest on or stick to. The high speed infill was a secondary problem, making it harder for the first unsupported top solid layer to bond where it hit the perimeter. It made stretching worse too in these unsupported areas. Sometimes that first layer of top solid fill was just falling down into the almost empty interior.

I printed again at 20mm/s with 0.4 fill density and honeycomb fill, and that came out without the hole problem.

You might avoid the holes with higher infill density alone. Or it may take a combination of that and a slower speed for this object.

(I wonder what infill density your green print on the Cube printer used. I'm guessing it was set higher, and that was the main difference between that print and your M2 prints.)

[lordofhyphens]

@ericu Can you try it with current 1.2.9?

[ericu]

Sorry @lordofhyphens, I haven't actually had my printer set up since I 1) moved; and 2) had a second kid. Maybe in another year, but I'm kind of doubtful.

[lordofhyphens]

@ericu your model has since disappeared off the interwebs, could you zip it up and drop it here if you can find it?

[ericu]

I don't have that computer handy, but I see that the version that mesheldrake posted above is still a valid link: http://sheldrake.net/bag/moebius_slice_scaled.stl

[djdelorie]

I tried to reproduce this today, adding my observations (for better or worse ;) : since I couldn't get the original model via google docs, I re-implemented one: http://www.delorie.com/tmp/mobius.scad Printed with slic3r 1.3.0-dev, it looks like slic3r is trying to put in enough layers, but tries to bridge to open air: http://www.delorie.com/tmp/mobius-bridge.png Resulting in gaps due to non-adhesion: http://www.delorie.com/photos/3d_prints/img_3246.html

[DrLex0]

@djdelorie Yes, lack of proper anchoring of the first layer on top of infill is a known issue: #1815