Different gcode header ouput for 1.01 and 1.1.1

[justmyopinion]

This is the short gcode header version I get from ver 1.1.1: ; generated by Slic3r 1.1.1 on 2014-04-24 at 09:24:03 ; perimeters extrusion width = 0.35mm ; infill extrusion width = 0.52mm ; solid infill extrusion width = 0.52mm ; top infill extrusion width = 0.52mm

and this is the "normal looking" i get from 1.01: ; generated by Slic3r 1.0.1 on 2014-04-24 at 09:28:54 ; layer_height = 0.2 ; perimeters = 2 ; top_solid_layers = 3 ; bottom_solid_layers = 3 ; fill_density = 0.25 ; perimeter_speed = 60 ; infill_speed = 90 ; travel_speed = 90 ; nozzle_diameter = 0.35 ; filament_diameter = 1.75 ; extrusion_multiplier = 1 ; perimeters extrusion width = 0.52mm ; infill extrusion width = 0.52mm ; solid infill extrusion width = 0.52mm ; top infill extrusion width = 0.52mm

Both are sliced with the same config file with default extrusion width of 0.52, which is not respected in 1.1.1 but changed to 0.35 (nozzle width?)

Is this intented behaveour?

[whosawhatsis]

I found I had to explicitly set all of the extrusion widths, not just the default extrusion width, when switching to 1.1.x.

BTW, 1.1.x puts a lot more of the settings in the comments at the end of the file.

[justmyopinion]

@whosawhatsis it is correct that at least perimeter extrusion width needs to be set exclusively in 1.1.x, but then the meaning of "default" is obsolete, well maybe it was anyway?

[alranel]

Yes @justmyopinion, the values on top were just duplicates of the config appended at the end of the file. @whosawhatsis, are you saying that default extrusion width does not affect others anymore? That is not intended behavior. I'll check it and add unit tests.

[whosawhatsis]

That's been my experience, yes. Specifically, I've had trouble for some time now, when using infill every X layers, where the extrusion width is chosen very poorly, resulting in poorly-bonded strings and an infill pattern that is way too large. Explicitly setting the default extrusion width has always fixed this, but the recent update broke the fix so that I had to set the infill extrusion width (which was previously left at 0) for the fix to work.

[whosawhatsis]

Speaking of infill every X layers, whatever happened to the idea of changing that to perimeter layer height and infill layer height? That would be really nice (even if infill layer height was rounded to the nearest number that evenly divides into the perimeter layer height) because it would mean that I would only have to change one number instead of two when making new profiles for different layer heights.

[358Eki]

I have the same starting g-code than "justmyopinion".

• at first look it seems to me that it ignores my additional starting codes at least. I have there for example autocalibration routine and wait times that was totally missed (nothing broke though). Also extrusion rate is very whimpy with my 0.5mm nozzle so there is something else missing too.

I had to make a fresh install today (for other reasons) and got this experimental. Now I have some hard time to get back to previous versions from http://dl.slic3r.org/linux/ and http://dl.slic3r.org/linux/old/ Folder I get from versions looks like there is something different on ver 1.0.0 file folders - looks more like Windows to me... no building routine with it any more... slic3r-linux-x86-1-0-1-stable.tar.gz 22-Apr-2014; slic3r-linux-x86-1-0-0-RC3.tar.gz 15-Feb-2014; slic3r-linux-x86-1-0-0-stable.tar.gz For some reason these have changed for more difficult to install with less installation helpers than I remembered (- this is probably my bad - after 20years of Mac's just switched to Ubuntu and learning).

[alranel]

@whosawhatsis, I usually set Infill every 'n' layers to 9999 in order for Slic3r to choose the max allowed height (== nozzle diameter). Isn't that enough?

[alranel]

I fixed the original issue described by @justmyopinion and @whosawhatsis.

@358Eki, just download the package and run the slic3r executable in it. No installer provided IIRC.

[358Eki]

Thank you! I'll try it right away.

[whosawhatsis]

@alexrj I didn't know you could do that, I'll try it out. It would be nice to be able to set a maximum that is a little less than the nozzle size, though...

[whosawhatsis]

Oh, and does it do fractional layer heights, or round to the nearest multiple of the layer height that is below the nozzle diameter?

This opens up some nice possibilities. I'm excited.

[alranel]

As long as width is larger than nozzle, you can do layers as thick as the nozzle diameter. Extruded volume is calculated approximately as width*height, not as a circular extrusion, so don't be afraid. :)

No fractional layer heights, it's still designed as a combination of infill layers. With 0.2mm layer height and 0.5mm nozzle, it will decide to combine two infill layers by making a single 0.4mm infill layer.

Also, #992 is relevant to this topic.

[whosawhatsis]

Yes, that's the thread I tried to refer to earlier, but it's been a while, and I didn't remember all of the details. I'm sure I've received an error before when trying to set the infill every X layers to a value that would make them thicker than the nozzle diameter, but I haven't tried it for some time, and I'm glad to hear that the feature has gotten smarter. I'll experiment with it, thanks.

[whosawhatsis]

@alexrj Just a thought, what if the normal function of the "infill every X layers" was what it is now, but you could add "mm" to after the number (like the fields that normally work in mm but can be switched to percent) to set the infill layer height in mm instead of number of layers?

Actually, it would be nice to be able to do this with the perimeter loops and top/bottom surface thickness too.