I've been using Z lift (set at .3mm) for a while now and it has seemingly been working fine on my CR-10S, or so I thought. I'm now seeing that on the first layer, Z lift doesn't do anything at all, even though I can see it occurring in the gcode. On the second layer, the Z height remains the same as the first layer, and again Z lift doesn't work. On layer 3, everything seems to work properly. The gcode seems fine to me.

Few other Z settings:

• First and all other layers are set to .3mm
• My Z offset is set to -0.725
• Z works fine otherwise, both manually and during the rest of the print. I can "babystep Z" during the first and second layers, so I know it's not locking up or getting too hot.

Attached is a sample gcode file (note that I removed a lot of the middle of the gcode to get to under the uploading file size). You can see Z starts at -.425 (which makes sense, as I have a -.725 offset with first .3mm layer), and the Z lift occurs at -.125, and it goes back down to -.425 to continue more of the first layer. It does this a few times as the first layer is made, and then jumps up to
-.125 (second layer) and has a Z lift up to .175 (which again looks correct). However, the printer is not physically making these moves until layer 3.

I rebuilt my hotend recently, so I releveled the bed and adjusted the Z offset to the value it is now. That's the only recent change I can think of. Can anyone tell me what's going on to cause this?

Are you sure it does nothing or is your "squish-factor" set so high, you can't see it? Just try out insane z-lift of 1mm.

OTOH, there is a setting in slic3r to specify Z-lift. Maybe you have to set the "above" value to something negative ( your z-probe offset )

I tried setting the 'Above Z' value to something negative, a value lower than the negative Z offset, but this did not change anything.

I then used the "Set Home Endstops" in Marlin when I homed all axes. This fixed the issue. I'm guessing when I reset all my zero positions, my board was still remembering the 'old' endstop locations instead of the new, and was not allowing the Z to go any lower despite what the gcode said. After updating the endstops to the new values, this seems to have fixed the issue. This makes sense now that I'm thinking about it. The board was simply doing its job and preventing the Z from going too low.