[2.0.x] fix bltouch homing#11379
[2.0.x] fix bltouch homing#11379thinkyhead merged 4 commits intoMarlinFirmware:bugfix-2.0.xfrom GMagician:2.0.x-fix-bltouch-when-homing
Conversation
|
@thinkyhead ok, as state in previous PR I not tested G28 with bltouch and.....bug. I supposed that function DEPLOY_PROBE should do as stated but it forget bltouch. Is it not a probe? is it not used as other probes? |
|
Probably missing ")" before return in 1372 line. Also head after homing Z is around ~15mm above bed. |
|
@tig33r fixed missing bracket but change should not affect home position |
|
I did not change conf file (exactly same as before your commit), just flash my board (due + ramps-fdv2.1) with newest repo changes. Weird behavior, someone else has to evaluate it. |
|
@tig33r can you explain me what happens? bltouch deploy and stow correctly during home? only final position is wrong? What happens to be labeled as "weird"? |
|
Homing process is going ok (move out pin, first fast bed move until pin reach bed, again move out pin and slow bed move until reach bed, at the end bed is moving down like always) but finally head in position 0 is about ~15 mm above bed. Exactly same configuration.h file with bugfix before your change is giving correctly positioned head above bed. Tommorow I will record video for both conditions. |
|
hello, same problem here i think. |
The way the BLTouch's code works came out of a bunch of testing and development, and it was useful to keep BLTouch deploy/stow separate from the general probe deploy/stow. We could probably dig up the PRs where the BLTouch was being developed and fixed to read the rationale. I've added an extra commit suggesting changes to solve the Z position problem for testing (basically just reverting some of the changes from the earlier PR). I look forward to feedback from testers. |
| #endif | ||
| if (STOW_PROBE()) return; | ||
| } | ||
| #endif |
There was a problem hiding this comment.
Moved this down to make the revert more complete, but if the other reverts solve the Z position problem then this may turn out to be ok moved back up above.
There was a problem hiding this comment.
Yes this will solve Z. STOW_PROBE move Z
|
Looks like it works ok in my setup. Maybe someone else can confirm that fact. |
|
The G28 works. |
|
How did G29 fail? The pin didn't deploy at some point during the procedure? |
|
As this at least partly solves the issue, I will merge it for now, and we can continue to patch following more testing. |
|
Yes. It goes to the position. Then go down without deploying. |
|
I retry with the last merge and will give a feedback |
|
last merge make it work again !!! excellent |
|
@vincent-ogury, @tig33r, @Stephane-80 I made some minor change to my PR (from my branch) can you test it again, sorry for bothering continuosly @thinkyhead since stow/deploy_probe functions act with no care of bltouch and since bltouch needs always to deploy and stow. I moved latter calls just before axis move. This should not change any behaviour but will keep deploy just before move call and such calls will be near stow counterpart. It seems following a more correct logic |
|
Thanks! It's working again! |
|
PR is just public now.... |
6 participants
Fix #11378