cool_lift_head produces stringing due to wrong order of operations

[richfelker]

I've been wanting to use cool_min_head for prints with small layers for a long time, but kept abandoning it due to stringing issues. I finally got around to analyzing the output gcode to find the problem, and have a proposed fix.

When cool_lift_head activates, it first raised the nozzle, then moves 20 mm towards the center of the bed. Even though the filament is already retracted at this point, lifting in Z without breaking the thread pulls material out of the nozzle and starts it oozing. Performing the move first breaks the thread so that no oozing/stringing occurs.

I tested this as just a 2 mm move first, followed by the lift and remaining 18 mm move, in case 20 mm is too far to move blindly without the risk of marring the print. However I think that risk is actually very low if the layer is so small as for cool_lift_head to kick in - usually this means there's only a single path in the layer.

If you want this to be configurable, it should probably only do the lift first if Z-hop is enabled (meaning the user is okay with the consequences of lifting the head without first breaking the string), and otherwise move to break the string first.

I haven't tested, but it seems plausible that this same effect could contribute to seam bulge at layer change time, and that it might make sense to move significantly inside the path (more than half a line width, maybe up to 2 mm) before travel to the next layer. But that's a separate topic and would probably warrant its own knob (or maybe it's already doable with a long wipe distance?)

[richfelker]

I noticed the above description isn't quite accurate and probably not a complete solution because the Z move to the next layer has already happened at the time of the lift-head operation. That's from the logic at:

https://github.com/Ultimaker/CuraEngine/blob/6e3413a9d02cc6ca82aa92b4104fa3b10a4fc314/src/LayerPlan.cpp#L1796-L1806

whose purpose is not really clear to me; it seems to purely make print quality worse. Disabling it defers the Z move to the start of the next layer so that there is no risk of oozing from moving up in Z without tearing off the string. I just ran a test slice and print with that code disabled, and the output gcode is more logical and some very minor surface blobbing/stringing is gone.

[richfelker]

OK, the above code seems to have been introduced by PR #1076 (reverted but with the same change reintroduced in a fixed version later) in response to https://github.com/Ultimaker/Cura/issues/5853. The latter was not really well-documented or well-motivated in my opinion; the moves in question should not knock parts off because they're at the same layer in which travel is already happening, and if warping causes them to collide, collisions would already be possible and the user probably needs Z-hop. And the workaround/hack that was introduced (moving to the new Z early) produces travel that does not properly break strings after retracting. I think that should be reverted or made optional.

[rburema]

Alternatively, this open PR might solve it as well: https://github.com/Ultimaker/CuraEngine/pull/1746