Closed Nocturnal42 closed 8 years ago
The issue appears to be with Z_DUAL_ENDSTOPS, with it disabled the printer moves and homes correctly.
@Nocturnal42 Please post your configurations so we can use them for testing. I don't have a machine to test with, but I might be able to see where the logic is failing.
Done. I suspect its the same issue as this #4916.
```
/**
* Marlin 3D Printer Firmware
* Copyright (C) 2016 MarlinFirmware [https://github.com/MarlinFirmware/Marlin]
*
* Based on Sprinter and grbl.
* Copyright (C) 2011 Camiel Gubbels / Erik van der Zalm
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see
```
/**
* Marlin 3D Printer Firmware
* Copyright (C) 2016 MarlinFirmware [https://github.com/MarlinFirmware/Marlin]
*
* Based on Sprinter and grbl.
* Copyright (C) 2011 Camiel Gubbels / Erik van der Zalm
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see
After bumbling my way through the code, tweaking random things, I found that cause. Looks like when you encapsulated the dual z endstop handling in #3631, and created `Endstops::test_dual_z_endstops', you accidentally turned
if (z_test && stepper.current_block->steps[Z_AXIS] > 0) {
into
if (stepper.current_block->steps[Z_AXIS] > 0) {
Fixing that fixes most of the problems, but reveals another.. assuming its supposed to work the way I think it is. It only homes to one of the end stops. I was under the impression that it should home to both, thereby leveling the attached axis.
And commenting out stepper.endstop_triggered(Z_AXIS);
fixes that, though now I suspect it's ignoring the endstops during normal moves.
No, I was wrong. This seems to work just fine, at least for me, with my setup and configuration.
// Pass the result of the endstop test
void Endstops::test_dual_z_endstops(EndstopEnum es1, EndstopEnum es2) {
byte z_test = TEST_ENDSTOP(es1) | (TEST_ENDSTOP(es2) << 1); // bit 0 for Z, bit 1 for Z2
if (z_test && stepper.current_block->steps[Z_AXIS] > 0) {
SBI(endstop_hit_bits, Z_MIN);
if (!stepper.performing_homing || (z_test == 0x3)) //if not performing home or if both endstops were trigged during homing...
stepper.kill_current_block();
}
}
I have noticed a small issue though, if I have endstops enabled by default, and if Y_min and Z2_max (uses Y_max) are triggered, I can't move the Y axis without it registering a triggered endstop.
This seems to work just fine, at least for me, with my setup and configuration.
I've applied the patch. This is one of the issues that has been blocking the release of RC8, so… much gratitude!
I have noticed a small issue though…
That's a good catch too! I'll see if I can patch that up.
if Y_min and Z2_max (uses Y_max) are triggered, I can't move the Y axis
Hopefully the patch in #5097 will do the trick. Please test the associated branch and see if it actually fixes the problem. Fingers are crossed. Breath is held.
Yup, that worked.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
I'm running the latest RCBugFix, I've just modified my printer to use dual stepper drivers for the Z axis (I had problems with one side of the axis drifting over time with the single driver for both). When first starting the printer, I am unable to move the Z axis. Attempting to do so will cause the display to report that the Z endstop has been tripped, but running M119 reports all endstops being "open". The reported Z position will change, but the axis won't move.
If I do a G28 Z, the position Z position on the display is immediately set to my max Z, but the axis does not move. However, I am now able to manually jog the axis down and up, without getting a Z endstop tripped message.