-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect blockage during endstop homing using stallguard #134
base: development
Are you sure you want to change the base?
Detect blockage during endstop homing using stallguard #134
Conversation
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 homingThe extra endstop [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 |
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...? |
Hi! Yes I know that the stallguard homing is already implemented. 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:
Does that make sense? The code is quite hacky and involves changing mmu_toolhead but mainly for demonstrating this idea. |
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() |
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... |
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. |
Actually, upon secondary look, I think I figured out how to do a disjunction of homing. Here's code from klipper
Perhaps something like (not tested):
|
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! |
Now that I think about it, I don't think the disjunctive homing makes much sense. So the logic in the PR seems simpler... |
Getting back to looking at this. Couple of things that seem incomplete:
|
1 similar comment
Getting back to looking at this. Couple of things that seem incomplete:
|
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.