Firmware retraction fix and extends zhop features.

[fbeauKmi]

As discuss on Discord, DK firmware and according to issue #204 and PR #206 . I made this for a while some change to fit my use case. I guess it can fix the issue.

Changes from actual firmware_retraction

• introduces reset_on_events parameter. (false : keep retracted state on events, true: reset retracted state and restore config values).
• Ability to use SET_RETRACTION while retracted
• Ability to do zhop even if retract_length=0.0
• Always do zhop as relative moves

Checklist

• pr title makes sense
• squashed to 1 commit
• added a test case if possible
• if new feature, added to the readme
• ci is happy and green

[richfelker]

I've been testing this and it works for me except that it still produces warning spam on G10 and G11 commands that should be idempotent. This messes up the start of every print, where the start gcode needs to have left the extruder in retracted state, but Cura also emits its own retraction for the first travel move. Supporting this kind of idempotency instead of double-retracting and messing up priming is, from my perspective, one of the compelling motivations for firmware retract in the first place, so it should not be treated as something abnormal that produces warnings.

As discussed on Discord, I would also like to see the issue resolved in a way that makes it possible to use Z-hop and get the right properties for how fw retract is supposed to work. This probably means something like having it so entering retracted state lifts Z by the configured amount, but explicitly moving in Z after that loses the offset and moves to the actual commanded Z height, and so that exiting retracted state only returns to the logical, non-offset Z height (doing nothing if Z was moved since the retract).

[fbeauKmi]

I've been testing this and it works for me except that it still produces warning spam on G10 and G11 commands that should be idempotent. This messes up the start of every print, where the start gcode needs to have left the extruder in retracted state, but Cura also emits its own retraction for the first travel move. Supporting this kind of idempotency instead of double-retracting and messing up priming is, from my perspective, one of the compelling motivations for firmware retract in the first place, so it should not be treated as something abnormal that produces warnings.

I removed the console outputs

As discussed on Discord, I would also like to see the issue resolved in a way that makes it possible to use Z-hop and get the right properties for how fw retract is supposed to work. This probably means something like having it so entering retracted state lifts Z by the configured amount, but explicitly moving in Z after that loses the offset and moves to the actual commanded Z height, and so that exiting retracted state only returns to the logical, non-offset Z height (doing nothing if Z was moved since the retract).

This point doesn't fit my workflow but I think we can do something configurable, for example a boolean clear_zhop_on_z_moves parameter to let the user choose. Unclear to me , does this apply to relative and absolute movements?

[rogerlz]

@fbeauKmi this looks good to me.. would you mind rebasing? ty

[fbeauKmi]

@fbeauKmi this looks good to me.. would you mind rebasing? ty

@rogerlz If you don't mind, I'd like to wait for feedback before merging. I'm not sure clear_zhop feature is useful for relative moves. TY