I’ve been working to convert my Printrbot Metal Plus to more modern electronics with Klipper. I’ve got most things working now, but my X Endstop appears to be unreliable. It’s fine on first power-on, but seems less likely to trigger as time goes on. What’s odd is, if I manually toggle the endstop while watching the GTR board, the endstop LED promptly lights as it should, but querying endstops tells me it’s not triggered, or sometimes it will tell me it’s triggered. Again, the longer the printer is on, the more likley it is to tell me it’s not triggered. What’s more odd is, the Y endstop does not exhibit this behavior.
Here’s what I’ve done thus far:
- Removed diag pins from all TMC2209 drivers (not just X)
- Removed diag jumpers from the GTR
- Changed to a different X endstop connector/pin
- Replaced the endstop wiring
- Replaced the endstop switch
- Replaced the power supply to the printer
Other potentially important information: There’s no Z endstop, just a probe. It’s hooked up with a bat85 diode.
I’m at a loss, particularly since the endstop LED works as one would expect. I’m left with either some firmware oddity for the GTR, or there’s a manufacturing/design flaw in this board. Any insight would be much appreciated.
After more and more debugging, I thought I found my gremlin as the printer worked long enough to try to start a print, and at the final homing before printing, X endstop fails again.
Additional things I did:
- Rewired the power supply to the board. New connectors, wires, etc… (still broken)
- Tested just letting the printer sit after power on to see if it would break after sitting for 30 minutes (still broken)
- Swapped the X and Y endstop connections on the board (now Y is broken?)
What the? But I had moved the X endstop to PI11/J76 before… why does this seem to suggest that the problem is the X endstop connection?
- Moved Y back to the designated connector and moved the X endstop to the Z connector and now it’s a bit more reliable but still acting screwy.
- After more playing with macros and getting klipper setup, bed_mesh, etc… I have both X and Y acting screwy. I can only assume now that it’s probably always been the case, and that I only thought it was X because it always homes first.
So very much at a loss. Maybe my replacement endstop switch is flaky as well and I should source another. I’d believe that if it weren’t for the fact that the endstop LEDs on the GTR change state reliably.
Hopefully this is my last update…
After continuing to experience periods of “Everything is working just fine” and then suddenly going to “X or Y won’t properly home anymore,” and getting extremely frustrated, I pulled the X endstop and replaced it again, and for the time being it’s only Y that’s giving me periodic issues. So I’ll be tearing it down enough to pull and replace that endstop as well.
What’s still baffling to me is that these are wired as NC. Manually toggling the endstop always toggles the endstop LED on the board. The only explanation I can come up with is that there’s some leakage in these switches and that the LEDs aren’t going out, just going dim.