Skip to content

Change runout computation algorithm v2#2

Draft
justvlade wants to merge 2 commits into
bugfix-2.1.xfrom
justvlade-patch-2
Draft

Change runout computation algorithm v2#2
justvlade wants to merge 2 commits into
bugfix-2.1.xfrom
justvlade-patch-2

Conversation

@justvlade
Copy link
Copy Markdown
Owner

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 runout variables after unretract motion. Also motion variables were changed the same way. But honestly I do not know what motion variables are for. But from code I see they work alike to runout variables, so I made the same editing for motion variables 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

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 <7622616+justvlade@users.noreply.github.com>
thinkyhead added a commit to GMagician/Marlin that referenced this pull request Jul 21, 2023
justvlade#2

Co-Authored-By: justvlade <7622616+justvlade@users.noreply.github.com>
thinkyhead added a commit to GMagician/Marlin that referenced this pull request Jul 21, 2023
justvlade#2

Co-Authored-By: justvlade <7622616+justvlade@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant