You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Idempotency of the G10 and G11 commands is an important/key property of firmware-retract. It's what makes it so your start gcode can end in a retracted state (so it doesn't ooze and lose priming) even if your slicer (cough Cura) insists on performing its own retraction before the initial travel move, without getting a double-retract.
Maintaining statefulness of retraction after one print ends and before another begins is also important to keep filament retracted at the right point not to ooze or waste excess material priming the next print.
The changes in https://github.com/DangerKlippers/danger-klipper/pull/83 make the former spam warnings, and completely break the latter by clearing retraction state after each print. They should be reverted and the system for introducing Z-hop re-thought not to break existing firmware-retraction semantics.
The text was updated successfully, but these errors were encountered:
Thanks for the feedback. We are working on making the features from #83 optional and returning the default behaviour for users that prefer so until we can work on a better solution
Idempotency of the G10 and G11 commands is an important/key property of firmware-retract. It's what makes it so your start gcode can end in a retracted state (so it doesn't ooze and lose priming) even if your slicer (cough Cura) insists on performing its own retraction before the initial travel move, without getting a double-retract.
Maintaining statefulness of retraction after one print ends and before another begins is also important to keep filament retracted at the right point not to ooze or waste excess material priming the next print.
The changes in https://github.com/DangerKlippers/danger-klipper/pull/83 make the former spam warnings, and completely break the latter by clearing retraction state after each print. They should be reverted and the system for introducing Z-hop re-thought not to break existing firmware-retraction semantics.
The text was updated successfully, but these errors were encountered: