Enable bowden correction for unload moves

[igiannakas]

To address issue where drag in the rewinder system could result in the gate homing max distance not being enough to fully pull out the filament from the encoder.

Also addresses issue where erec would cut the filament at the wrong spot, as the unload operation didn't bring the filament to the expected position, if drag in the buffer system caused slippage.

The logic uses the amended approach from this PR #582 to ensure that the right amount is retracted (vs the old one that overshot the requested correction).

Tested with load and unload Bowden console commands and the slippage is fully compensated (actually better than I thought!!)

[igiannakas]

Updated, also updated the load part that was doing something similar ;)

[moggieuk]

Here is my concern... HH used to do this on unload (as it does on load). The problem is that poor calibration or encoder issues can easily lead to "over unloading". This is something that cannot be undone .. the filament is ejected. However, the safe way to handle is to let "unload_gate()" handle perhaps with a longer length... that will not over unload.

That is the reason I removed the logic and simply replaced with warning message. I think a better way to handle is to indicate to unload_gate() to increase the homing distance. This can actually easily be done by setting the filament position to "IN_BOWDEN" rather than "START_BOWDEN"

[igiannakas]

Hm… I get the point. Maybe a different way would be to cap the max correction adjustment up to the gate parking distance? That way you’ll never unload past the gate?

[igiannakas]

Also just thinking out loud - if the encoder is not reliably measuring the filament won’t it crash on the extruder when loading and strip? Yes that’s probably reversible but with a long Bowden tube that’s an issue too as the flat spot may cause a potential subsequent unload to fail if the flat spot is not extruded?

Interesting idea setting the in Bowden position. The issue I had that spurred me to look at this was during main Bowden unload phase it slipped slightly and it happened to be the right amount of filament left that the gate unload routine pushed it out of the gate completely. And then it couldn’t be grabbed again for the next tool change 😁

Would setting the position to in Bowden do smaller moves to retract the filament?

Alternative:
Cap the adjustment up to gate unload buffer (as this is what should be left in the Bowden if no slippage is present) minus say gate parking distance (as this is the distance from the encoder to the gate), minus some tolerance (so we don’t fully clear the encoder), basically bringing the filament worst case right before the encoder measurement spot.

Also limit the correction to a single move, not 2 attempts to correct.

That way even if the encoder is misreading, the filament would be brought, at worst, to the entry of the encoder and no further, while also correcting a large portion of the deviation.

Could also set this as an option in the config to enable or disable the correction move on unload as I’m guessing for the vast majority of non filamentalist users this doesn’t matter as there isn’t enough friction to affect the unload process, so this is redundant.

I’ve got a print lined up for it tomorrow using that slippy lane with the code above and see how it does. I’ll amend the PR to try the idea above as I can see where you’re coming from, makes sense.

Maybe I have too much misplaced trust in the encoder 😂

[igiannakas]

Quick check before I go off and try your suggestion to set it in the In_Bowden state if excess slippage is observed.

Would this affect EREC in any way? Is that one expecting the state machine to be in the start_bowden state?

[igiannakas]

So did some more tests with a ceiling set to avoid going past the gate. I’ll push the code shortly for you all to check out. (main...igiannakas:Happy-Hare:Gated-bowden-correction)

Kind off see moggie’s point. The moment you add protections to avoid overrunning the gate, the compensation becomes exponentially less useful, as you are capped to how much you can correct.

Which is counter to the point of correcting in the first place as you are still left with an “unpredictably” long amount left to cut / rewind. And that still exposes you to the same issue of running out of gate homing headroom or cutting too long of a filament tip with the EREC.

Hm that’s a tough one.

The thing that I have noticed though is that the homing moves are around 15mm long - I think this is because of the encoder step size which may be a bit too large causing the homing moves backwards to push the filament out of the gate on (rare) occasion, if it happens to have the filament just clear the encoder (12mm move), with up to 20% overrun (3mm overrun), then another push back move is done (15mm) -> 15+3 = 18mm behind the encoder. The gate stop is about 10mm on the ERCF so you've cleared the filament trap and are now on the extruder gears.

And if the spool just so happens to also tug on the filament slightly due to momentum in the filamentalist you've exited the gate. Admittedly a rare scenario but somewhat possible (its happened twice yesterday for me for example)

So maybe that is the solution? Reduce the encoder step size for the encoder homing process?

[moggieuk]

You have been busy! Great to see the deep dive into the code...

Firstly, the "homing to encoder" works on a step step. This step size must be less than the final parking position. Therefore, when there is a big enough mismatch between what the encoder sees, that both indicates that the filament is out of the encoder AND the amount of overshoot. So long as the overshoot is < parking_distance, the parking distance is simply reduced by that amount. It works really well and certainly achieves 1-2mm accuracy (a gate sensor would achieve about 0.5mm accuracy by comparison).

At one point I use to have a separate flag to "apply on unload" which I'm open to bringing back because with it defaulting to "0" (off) there is no upgrade complexity.

But as to my set "state machine position" to IN_BOWDEN idea... see this comment in _unload_gate()

        if full: # Means recovery operation
            # Safety step because this method is used as a defensive way to unload the entire bowden from unknown position
            # It handles the cases of filament still in extruder with not toolhead sensor or the small window where filament
            # is between extruder entrance and toolhead sensor (if toolhead sensor is available)
            homing_max += self.gate_homing_max # Full bowden may not be quite enough

This means that if the "calibrated_bowden_length" is passed in as the homing max, then HH will home using the full bowden length move + a bit more. This is the slow homing move and works whether "encoder" or "gate" homing is used - just takes a bit more time to unload.

Given the explanation above for the encoder based approach, it should never overshoot...

Also see this around line 8097, which is how the unload_sequence() knows what method to apply:

                elif start_filament_pos >= self.FILAMENT_POS_HOMED_GATE:
                   # We have to do slow unload because we don't know exactly where we are
                   self._unload_gate(homing_max=bowden_move) # Full slow unload

[igiannakas]

Thank you 🙏🏻 my python skills are pretty much non existent and starting with a 5k line python file is quite the undertaking :)

after my little printing accident yesterday need to get the printer back up and running again as it’s a PITA to try and test these with a half working cutter, blobifier servo etc.

Got some parts coming today so hope to delve into this tomorrow / Friday.

thank you again!!