runout: Reset ran_out boolean on print resume

[tpruvot]

If the sensor was triggered during a print, the sensor status remains disabled,
even after the end of the current print.. which avoid a new trigger.

internally, filament_ran_out bool remains true.

[tpruvot]

i need to run a real test on this change... may be more complicated due to the multiple classes in Marlin/src/feature/runout.cpp

[thinkyhead]

Seems sensible, but I will await your test results.

[tpruvot]

its ok now... yes, that fixes it

i can see that with this commit : tpruvot@d86f6fc#diff-ec2f6f0048410f90bf566ce7f98b6ef1R606

[tpruvot]

to keep current "bad" behavior, you can also select disable sensor during the resume dialog... on the lcd

[tpruvot]

to note, our config ADVANCED_PAUSE_RESUME_PRIME is 0 and FWRETRACT disabled... (default values) that avoid the call to do_pause_e_move() which actually do the filament reset, maybe this reset() call is badly placed.

Or... maybe a && ADVANCED_PAUSE_RESUME_PRIME == 0 in the ifdef

[InsanityAutomation]

ADVANCED_PAUSE_RESUME_PRIME == 0 is what triggers this as prior it was reset on each prime move. If the sensor is out when they enter the continue menu this will leave them still stuck with no choice but to disable the sensor. Perhaps it should go on line 267 as well? That should hit youre other case and then IMO this should be merged.

[tpruvot]

nope, line 267 will not help... as its made at 269

[InsanityAutomation]

@tpruvot I mightve been a couple lines off, i meant adding as an else to the condition if (purge_length > 0) since a user who selected the heat and continue without loading filament and purge length of 0 may be stuck forced to disable the sensor.

[tpruvot]

i dont think this change can hurt any board... the reset is just a way to "re-enable" a triggered endstop.. If its really disabled, there will be no trigger... and if that was already done, that will not trigger it differently...

[thinkyhead]

I have heard rumors that possibly the resume after filament runout / filament change is still misbehaving - possibly going to the wrong Z position. Keep an eye out for those bug reports.

[tpruvot]

i didnt notice Z issues here, maybe a bit of underextrusion on resume (related to the purge length setting)

you sure its not related to PLR instead ?

using ./config/examples/Alfawise/U20

[thinkyhead]

I'm always a little concerned about all the resume procedures. PLR has some challenges too… If we can move the nozzle away before the power is completely lost it will help prevent messy melted spots that ruin the print. And another suggestion I got recently was for PLR to resume starting with…

• Pre-heat the nozzle to 180
• Do a small Z raise, then G28 XY
• …then do the rest of the resume…

The pre-heating is meant to prevent the print from being pulled off the bed, which can happen if G28 is done while the nozzle is still cold.

[tpruvot]

yep, i dunno... but this runout PR is unrelated...
./Marlin/src/feature/runout.h

    static inline void reset() {
      filament_ran_out = false;
      response.reset();
    }

was just a bool reset :p

[tpruvot]

k i understand for the PLR : #16413 (comment)

but unrelated with the filament sensor :p