Change runout computation algorithm v2 #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This should be considered as a draft idea, as there are some ideological contradictions in changing fundamental idea of runout. And needs approving that it does not harm other runout algorithms. This needs proper discussion with its pros and cons. I guess there is a reason(was not able to learn it though), why initial code excludes retraction/unretraction movement (or at least tries to do so). Initial idea of fixing issue MarlinFirmware#26061 Unlike patch MarlinFirmware#26082 this idea have alternative to conservative view. Instead of trying to figure out which E move is retract and which not, we take into account any E move, as those are connected to physical filament movement. All in all forward and backward movement will compensate itself. Modern slicers often introduce new approach to retraction movement. For example Super Slicer allows to enable retraction wipe, which makes retraction during horizontal movement. Also there is an old idea of filament unretract compensation, when unretract is slightly larger then retract movement. Not all printer needed this fix, but if we ignore retract/unretract we will loose those compensation move as well. This idea was inspired LCD_SHOW_E_TOTAL function. I do not actually checked the code of filament summary feed calculation, but from user experience LCD_SHOW_E_TOTAL shows actual filament movement with retraction and unretraction, as it may become smaller while printing. And as I understand it is considered to be precise.
This patch propose idea to take into account retract and unretract motion while computing runout left distance. Initial idea of fixing issue MarlinFirmware#26061 Unlike patch MarlinFirmware#26082 this code works not only for firmware retract, or classic retract, but also for software wipe retracts, when retract done with horizontal motion. Modern slicers often introduce new approach to retraction movement. For example Super Slicer allows to enable retraction wipe, which makes retraction during horizontal movement. Also there is an old idea of filament unretract compensation, when unretract is slightly larger then retract movement. Not all printer needed this fix, but if we ignore retract/unretract we will loose those compensation move as well.
thinkyhead
added a commit
to GMagician/Marlin
that referenced
this pull request
Jul 21, 2023
justvlade#2 Co-Authored-By: justvlade <[email protected]>
thinkyhead
added a commit
to GMagician/Marlin
that referenced
this pull request
Jul 21, 2023
justvlade#2 Co-Authored-By: justvlade <[email protected]>
thinkyhead
added a commit
to GMagician/Marlin
that referenced
this pull request
Jul 21, 2023
justvlade#2 Co-Authored-By: justvlade <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This patch is a variant of resolving issue MarlinFirmware#26061
The problem is not only with firmware retraction, but also with software retraction. While patch MarlinFirmware#26082 solve problem with classic retraction (when printhead is still while retracting) it cannot solve the problem with software wipe retraction, which is introduced in Super Slicer for example. Also there may accumalte computation error because of additional unretract compensation. All in all it is better to take into account all extruder movement to have accurate data.
This is a prototype of this approach. I have tested this on initial gcode retract_test_ps_464_fw.gcode and retract_test_ss_464_wipe_r06.gcode. And fixed some issues. And it is working alright.
I plan to create a working firmware with my preferred config to check how it works on real printing. For now this is a draft.
In this patch I added flags to reset
runoutvariables after unretract motion. Alsomotionvariables were changed the same way. But honestly I do not know whatmotionvariables are for. But from code I see they work alike torunoutvariables, so I made the same editing formotionvariables too.The idea is, when we take into account retract and unretract motion we cannot reset runout anytime. If retract distance is larger then runout distance if we reset between retract and unretract it will lead to runout trigger right after unretract.
So we unable to reset immediately. Also we cannot ignore event, as when unretract compensate retract movement we see that runout distance is smaller and smaller over time, which may lead to runout event again. So we raise a flag to trigger filament reset after unretract movement. It will try to reset at every movement until it succeeds.
Requirements
This requires filament motion sensor, or at least filament present sensor to test.
Benefits
Filament motion sensor will correctly detect runout event with small runout distances and large retract distances. And Slicers which experiment with retract wiping will not cause problem.
Related Issues
This should solve issue MarlinFirmware#26061