second layer printed at first layer's height in certain conditions

[jefvdb]

Hi!

What i'm seeing; when having a non-zero lift-z-on-retract and a height difference between the first and the later layers, generated gcode will put the second layer at the first layer's height (creating a nice mess), and the further layers at their correct height. I have tested on 1.0.1, 1.1.7 and 1.2.0, all of which seem to have the issue. Setting the lift-z to 0 removes the issue, and so does setting the first/successive layers at the same height.

This could also be a problem with the gcode's interpretation, my method of testing is checking the gcode visually with octoprint (GCodeVisualizer) and printrun's (5Nov2013) visualisation, as well as actually printing them via octoprint on an i3. Both visualizations show a somewhat different but in both cases wrong result, and the prints themselves seem to agree with printrun's.

Some data I've gathered;

1) first-layer-height == other-layers-height == lift-z 0.3 All tests (octoprint, printrun, 1.2.0's visualizer) have good values. First layer @0.3mm, second @0.6mm, third @0.9mm, etcetera.

2) first-layer-height = 0.24mm, other-layers-height = 0.3mm, lift-z = 0.3mm

• 1.2.0's preview show correct values; first @0.24 , second @0.54, third @0.84, ...
• however, others say:
  • printrun; first @0.24 , second @0.24 !!! , third @0.84 !!! , fourth @1.14, ...
  • octoprint; first @0.24 , second @0.84 !!! , third @1.14 !!! , ... (viz skips a layer there? only shows the two first layers as being full-infill, there are three configured/printed tho)
• very visible in prints, much like what printrun says; this is a block of 1cm width, first layer already printed as well as the walls and a portion of the infill of the second, the second is squashed over the first (and not pictured, a gap occurs here and there between the outside perimeters of layers 2 and 3)
  • bottom:
  • top:

3) first-layer-height = 0.24mm, other-layers-height = 0.3mm, lift-z = 0mm

• same as before but with no lift-z
• all visualization and a real print confirm, everything looks ok; first @0.24, second @0.54, third @0.84, ...
  • 

4) first-layer-height = 0.4mm, other-layers-height = 0.3mm, lift-z = 0.3mm

• (same as 2) but with first-layer-height larger than other-layers-height)
• 1.2.0's preview shows correct; first @0.4, second @0.7, third @1.0mm, ...
• others however;
  • printrun; first @0.4, second @0.4 !!! , third @1.0mm !!!, ...
  • octoprint; first@0.4, second @1.0 !!! , third @1.3mm !!!, ... (GCodeVisualizer again confused and skips a layer, only shows the two first layers as being full-infill, there are three configured/printed tho)
• in printing this (again like printrun seems to indicate) the second layer is still squashed upon the first, but this is not as dramatically visible as in the previous case, only at the corners does the second layer's filament droop all the way to the bed, guessing due to more wall-room to droop over.. But I can still feel the second layer being thicker than the rest, and a now more noticeable gap appears on the perimeter between layers 2 and 3 (and 3 and 4);
  • 

5) first-layer-height = 0.4mm, other-layers-height = 0.3mm, lift-z = 0mm

• same as before but with no lift-z
• all visualization and a real print confirm, all is well; first @0.4mm, second @0.7mm, third @1.0mm, ...

My setup;

• Slic3r 1.0.1, 1.1.7, 1.2.0 on OSX 10.6.8.
• Printrun-Mac-05Nov2013 on the same host.
• octoprint on a raspi, source code mentions 1.0.0

[jefvdb]

The files;

• config saved with 1.2.0 (scenario 4 above): https://dl.dropboxusercontent.com/u/383266/github-Slic3r-2295/config_i3_squash_20141006.ini
• the input stl shown above: https://dl.dropboxusercontent.com/u/383266/github-Slic3r-2295/bar.stl
• output of that stl with that config on 1.2.0: https://dl.dropboxusercontent.com/u/383266/github-Slic3r-2295/bad.gcode

[alranel]

Thank you for the very detailed report. I confirm this is fixed as of current HEAD thanks to the large refactoring I did on the lift/retraction code.

[hynyna]

This problem may still exist, though I don't really know, why this weird thing happens.

Using Slic3r 1.3.0 installed through homebrew on macOS 10.14.6

Currently I'm trying to print keyboard keycaps using this OpenSCAD library https://github.com/rsheldiii/KeyV2/ Keycaps are generated by doing what's mentioned here to have multi material print without using a multi material printer: generate legends and generate caps separately and upside down. When I put the generated STL file into Slic3r, the second layer has a really weird pattern and it's merged into the first layer.

Has somebody got a clue for me as to why this could be happening?

I uploaded sliced gcode+STL file, in case somebody wants to test this out.

Finally some screenshots of what's happening: 1st layer looking perfectly fine

2nd layer pattern looking abnormal and squishes into first layer

2nd layer madness viewing from below the bed

3rd layer looking fine and normal again

[jefvdb]

Hi @HobbinHood ,

I recommend opening a new ticket, I don't think the devs are reading this :)

But FWIW, I loaded that .stl with 1.3.0 on Linux and I'm not seeing those shenanigans in your screenshots. I am using a different config with different layer heights tho. Post yours if you'd like me to try it out.

[lordofhyphens]

Yes, please open a new issue