Detect blockage during endstop homing using stallguard

[thisiscam]

A working proof of concept to home the selector using stallguard instead of the selector endstop.
The goal is detecting selector blockage during homing.
Code for demonstration purpose only and needs cleanup.

[moggieuk]

I admit I haven't process these changes carefully yet, but you can set up stallguard on the selector for homing like this: (pulled from the Happy Hare doc):

True stallguard based selector homing

The extra endstop mmu_selector_touch described in the mmu_hardware.cfg file is designed for "touch" movement where the selector can feel for filament blocking a gate and autmatically take recovery action. However, you might be wondering if it is possible to perform true stallguard homing on the selector? It certainly is but you need to adjust part of the config for the selector stepper: instead of making mmu_sel_touch an extra endstop, make it the default like so (note it is very important to add the homing_retract_dist: 0):

[stepper_mmu_selector]
...
endstop_pin: tmc2209_stepper_mmu_selector:virtual_endstop
endstop_name: mmu_sel_touch
homing_retract_dist: 0

This will not only define mmu_sel_touch as a named endstop for "touch" movement but will also make it the default endstop for homing operation. With this configuration there is no need to have an microswitch or mmu_sel_home endstop defined. Personally I like the reliability of a mechanical homing endstop because it requires no tuning.

[moggieuk]

Setting up like this would allow for stallguard based homing as well and stallguard "touch" based movements.

I'm not entirely sure of what extra functionality you are providing in the this PR...?

[thisiscam]

Hi! Yes I know that the stallguard homing is already implemented.
I will revise the title.

The problem I am trying to solve is that the selector can be blocked when using an endstop to home. Ideally, we should be able to catch that blockage as well using stallguard. This code does just this:

• Try to make a first homing using stallguard
• Once homed, check if the endstop is triggered
  • If so, then do the second home using endstop
  • otherwise, report blockage

Does that make sense? The code is quite hacky and involves changing mmu_toolhead but mainly for demonstrating this idea.

[moggieuk]

Ah, that is more similar to the way it used to work for the original manual_stepper version. I think there may be a slighter better way tough...

I can have multiple endstops on a rail (the "extra endstop"). If the homing move used both endstops, one would cause it to stop. If not the physical one then error otherwise you are already homed. Would just need to figure out how to have both active in HomingMove()

[thisiscam]

I can have multiple endstops on a rail (the "extra endstop"). If the homing move used both endstops, one would cause it to stop. If not the physical one then error otherwise you are already homed. Would just need to figure out how to have both active in HomingMove()

This was what I looked into at first. However, it seems like multi-endstop homing only supports "conjection", that is, the endstops must be all triggered? I wasn't able to find how to do a disjunction...

[moggieuk]

Interesting. I admit I swap endstops all the time but have never had too active at the same time. Interesting that klipper defaults that way, are would have guessed the opposite.

[thisiscam]

Actually, upon secondary look, I think I figured out how to do a disjunction of homing.

Here's code from klipper homing.py:

def multi_complete(printer, completions):
    if len(completions) == 1:
        return completions[0]
    # Build completion that waits for all completions
    reactor = printer.get_reactor()
    cp = reactor.register_callback(lambda e: [c.wait() for c in completions])
    # If any completion indicates an error, then exit main completion early
    for c in completions:
        reactor.register_callback(
            lambda e, c=c: cp.complete(1) if c.wait() else 0)
    return cp

Perhaps something like (not tested):

import functools
def multi_complete_disjunct(printer, completions):
    if len(completions) == 1:
        return completions[0]
    # Build completion that waits for any completion
    reactor = printer.get_reactor()
    cp = reactor.register_callback(lambda e: [c.wait() for c in completions])
    # If any completion gives any result, terminate the main completion
    def check_completion(c, e):
        result = c.wait()
        if result is None:
            return 0
        else:
            return cp.complete(result)
    for c in completions:
        reactor.register_callback(functools.partial(check_completion, c))
    return cp

[moggieuk]

That proto logic looks right and yes, now I remember the "multi_complete" method. Of course this is yet more to keep up-to-date with klipper changes. Even the Toolhead class initializer has been keeping me busy lately!

[thisiscam]

Now that I think about it, I don't think the disjunctive homing makes much sense.
When the selector reaches the end, we don't know which of stallguard or endstop might trigger first. If endstop triggers first, then we are good to perform the second homing. But if stallguard triggers first, we'd need to check if endstop triggered too, and that's the same as the logic in this PR.

So the logic in the PR seems simpler...

[moggieuk]

Getting back to looking at this. Couple of things that seem incomplete:

1. This doesn't differentiate between selector homing or gear stepper homing. This isn't going to work for users that have "touch" homing setup to detect extruder entrance for example
2. As pointed out in the code, the TMC current change is not plumbed into mmu.py and config. Although I'm not sure why the current needs to be reduced. Doing so adds an extra complexity to the tuning of stallguard that is dependent of the stepper current,
3. How does this work for just selector "touch" stallguard homing. I.e. no physical endstop? Currently that has to be set up a little differently to just defining "touch" and requires a configuration that prevent multiple homing tries. I THINK this could be made to work to make setup easier and allow for just "touch" setup on the selector but of course that would not be able to include the intelligent home operation.

[moggieuk]

Getting back to looking at this. Couple of things that seem incomplete:

1. This doesn't differentiate between selector homing or gear stepper homing. This isn't going to work for users that have "touch" homing setup to detect extruder entrance for example
2. As pointed out in the code, the TMC current change is not plumbed into mmu.py and config. Although I'm not sure why the current needs to be reduced. Doing so adds an extra complexity to the tuning of stallguard that is dependent of the stepper current,
3. How does this work for just selector "touch" stallguard homing. I.e. no physical endstop? Currently that has to be set up a little differently to just defining "touch" and requires a configuration that prevent multiple homing tries. I THINK this could be made to work to make setup easier and allow for just "touch" setup on the selector but of course that would not be able to include the intelligent home operation.