Drop In Print Quality Ver 0.9.3 -> Banding In Prints -> Visible in G-code Using Repetier Too

[IdolCrasher]

Good Day,

I have had the opportunity now to print a few objects with version 0.9.3, and have noticed a fairly significant drop in print quality.

Printed items now have a significant amount of banding. I have now proved this banding was a result of flaws in the G-Code produced by version 0.9.3

I sliced a 20mm calibration cube in both version 0.9.1 and version 0.9.3 and visualized that G-Code in Repetier.

This banding is visible in the 3D representations of the G-Code produced by 0.9.3.

The G-Code made by version 0.9.1 is silky smooth.

V. 0.9.3 Side View

V. 0.9.1 Side View

V. 0.9.3 Angle View

V. 0.9.1 Angle View

Left 9.1, Right 9.3

Version 0.9.3 also lefts gaps between infill and perimeters that 0.9.1 successfully filled in smoothly.

Top 9.3, Bottom 9.1

I am ready to provide G-Code and STLs for any of these scenarios on request.

[IdolCrasher]

Here is the config I used in 0.9.3

generated by Slic3r 0.9.3 on Sun Sep 30 09:04:25 2012

acceleration = 0 bed_size = 140,140 bed_temperature = 70 bridge_fan_speed = 100 bridge_flow_ratio = 1 bridge_speed = 60 brim_width = 3.15 complete_objects = 0 cooling = 1 disable_fan_first_layers = 1 duplicate = 1 duplicate_distance = 6 duplicate_grid = 1,1 end_gcode = M104 S0 ; turn off hot end\nM190 S0; turn off heated bed external_perimeter_speed = 10 extra_perimeters = 1 extruder_clearance_height = 20 extruder_clearance_radius = 20 extruder_offset = 0x0 extrusion_axis = E extrusion_multiplier = .913462 extrusion_width = .36 fan_always_on = 1 fan_below_layer_time = 720 filament_diameter = 1.7 fill_angle = 45 fill_density = 0.15 fill_pattern = honeycomb first_layer_bed_temperature = 80 first_layer_extrusion_width = .63 first_layer_height = 0.35 first_layer_speed = 30% first_layer_temperature = 210 g0 = 0 gcode_arcs = 0 gcode_comments = 1 gcode_flavor = reprap infill_acceleration = 50 infill_every_layers = 1 infill_extruder = 1 infill_extrusion_width = 0 infill_speed = 60 layer_gcode = layer_height = 0.20 max_fan_speed = 100 min_fan_speed = 100 min_print_speed = 10 notes = nozzle_diameter = 0.35 only_retract_when_crossing_perimeters = output_filename_format = [input_filename_base].gcode perimeter_acceleration = 25 perimeter_extruder = 1 perimeter_extrusion_width = 0 perimeter_speed = 30 perimeters = 1 post_process = print_center = 70,70 randomize_start = 1 retract_before_travel = 2 retract_length = 2 retract_length_toolchange = 3 retract_lift = .4 retract_restart_extra = 0 retract_restart_extra_toolchange = 0 retract_speed = 30 rotate = 0 scale = 1 skirt_distance = 10 skirt_height = 1 skirts = 1 slowdown_below_layer_time = 20 small_perimeter_speed = 20 solid_fill_pattern = rectilinear solid_infill_below_area = 70 solid_infill_every_layers = 0 solid_infill_speed = 40 solid_layers = 4 start_gcode = G28 ; home all axes support_material = 0 support_material_angle = 0 support_material_extruder = 1 support_material_extrusion_width = 0 support_material_pattern = honeycomb support_material_spacing = 2.5 support_material_threshold = 45 temperature = 185 threads = 2 top_solid_infill_speed = 30 travel_speed = 130 use_relative_e_distances = 0 z_offset = 0

[alranel]

Can you provide the two G-code files?

[IdolCrasher]

Certainly. Will put them up when I get home from work.

[IdolCrasher]

is there a better way to send you th g-code?

[IdolCrasher]

i think it is safe to say, you will see this discrepancy between anything you slice with 9.1 and 9.3

No matter what settings I use, and no matter what item i slice, I get bumpy ugly perimeters with 0.9.3

What happened?

[theodeyle]

I use gist.github.com.

[IdolCrasher]

I posted the g-code on gist.github https://gist.github.com/3815185

Thanks Tdeyle!

Whoever fixes this gets a Coca-cola from me!

[IdolCrasher]

Anyone else seeing this behavior? Do most of you guys use pronterface and did not see the ragged edges version 0.9.3 seems to put on everything?

[avalero]

I have also noticed the same issue. I thought it was because of my threaded rods being bend, but after slicing with 0.9.1 walls were perfectly straight

[IdolCrasher]

Good to know I am not crazy! ;)

[theodeyle]

You're not. I still slice with 0.7.2b on certain things: Gears and Yoda, for example.

[IdolCrasher]

Crossing fingers for a version 0.9.x that is fairly bug free like 0.7.2b was.

Not there yet ;)

[IdolCrasher]

are more details still needed?

[IdolCrasher]

sorry boss, but I can't even get 0.9.3 to properly slice a calibration cube.

0.9.1 is still working strong.

Am I just a dummy or does something need fixed in 0.9.3?

[mesheldrake]

Let's play with your configuration a little, both to help point to where the problem is, and to see if we can avoid it with different settings, until the underlying problem is fixed.

First we turn off skirt and brim, and set solid layers (horizontal) to zero, so we can look down on all of the layers of the gcode visualization and see all perimeters and normal infill.

Here's your original config from above, with those changes, and the test cube used to make the following screen shots:

http://sheldrake.net/bag/idol_prob_iso.ini http://sheldrake.net/bag/20mmbox.stl

(It's so quick and easy to verify a Slic3r problem when those two files, providing a specific example, are readily available from the start.)

That gives this:

Ah - normal fill is set to honeycomb. And it's going all the way out to its boundary perimeter, and overlapping it. That explains the weird rough appearance of the outer wall in your first screenshot. (I use LinuxCNC AXIS here, but the Repetier gcode visualization reveals this too, if you click the "gcode editor" tab, and then "Show single layer" below the text edit area.)

Your config specifies one perimeter, but the "Generate extra perimeters when needed" option is checked. For whatever reason, a second, extra perimeter was added to some of the layers we're looking down on here, and on those layers the fill does the same thing - it runs right up to and on top of that perimeter.

The combination of the extra second perimeter on only some layers with this fill-perimeter overlap issue seems like it would give the kind of irregular results shown on that yellow printed part. But the overlap issue would be the primary problem there.

The two perimeters are confusing to look at, so let's uncheck "Generate extra perimeters when needed", and keep perimeters set to 1:

That seems to point to the problem fairly clearly. And all we've done is change a few settings to isolate what's wrong..

Now it seems we have something specific to report:

Hexagon Fill Overlaps Boundary Perimeter

or something like that.

(That seems a bit more fair than the globally damning "0.9.3 has reduced print quality".)

Let's simplify the test case a little more by using Slic3r's scale feature, set to 30%, so we get about one hexagon fill and fewer layers to look at. You'll also need to set "solid infill threshold area" to zero temporarily, to get the normal infill in this tiny cube.

The brighter part of the perimeter lines are where parts of the truncated hexagon overlap. (There's a similar visual cue when looking at this in Repetier.)

By now the author probably knows exactly where to look to fix the problem.

Does the rectilinear fill pattern do the same thing?

Looks like that's okay. The lines stop a bit short of the perimeter, like they should. So one config change - switching to rectilinear fill - might get you back to the quality you expect with 0.9.3, if you can forgo hexagon fill for now. I would guess rectilinear would work better for that smaller yellow part anyway.

[alranel]

Okay, I fixed this now.

I want to thank @mesheldrake publicly for the excellent investigation work about this issue. That helped me a lot to focus on the actual problem (overlap between honeycomb infill and perimeters).

[alranel]

I also pushed a fix for the useless extra perimeters.