A fairly common homing cycle runs like this:
- Move fairly quickly toward the endstop until it is triggered
- Move away until the switch is no longer triggered
- Come back in at a slower rate until triggered again (which provides a more precise location)
- Set the now-known machine position
- Move off the switch one last time.
Homing won’t work, and you won’t be able to tell what part of the homing cycle is running, until the switches are consistently reported correctly by M119.
If M119 says “triggered” when the switches should be open, and it doesn’t change when you exercise the switch, there’s a short in your endstop circuit somewhere. What you’re interpreting as “homes the opposite of what is set in the firmware” is the second part of the homing cycle, trying to move away from the already triggered limit switch.
Are you using 3 pin connectors for the endstops? The board reads a connection between the Signal and Ground pins as the switch being triggered. Many boards also provide a 5V pin to run the optical sensor or indicator LED types of endstop modules. Make sure your switches are connected the right way around, matching S(ignal), G(round) and V(olts, if present) at both ends.
The following applies a general approach to limit switch troubleshooting which has proven effective for me in the past.
When M119 doesn’t report the state of the switches changing when you manually trigger them, I see 4 possibilities:
- The switches are mechanically faulty.
- The switches are wired incorrectly.
- The switches are plugged into the wrong ports on the control board.
- The wrong set of endstops is enabled in the firmware.
Since you’re experiencing the same issue with both X and Y switches, I’m leaning toward a wiring issue, but I suggest a process of elimination starting from one end of the system and working through all the elements in sequence. I’m a big believer in checking physical stuff first, so I’d start at the switch end of things.
- Assuming an actual mechanical switch (not an opto-enstop), check the switch’s operation directly with a multimeter/continuity tester. Based on your note that default is inverting set to false, connections at the switch should be to the NO (normally open) and C or COM (common) terminals of the switch, so check continuity between those terminals with as much other circutry disconnected as possible. You should get continuity when the switch is closed and none when the switch is open. If there’s no change right at the terminals when the switch is triggered, the switch itself is bad. You should still be able to test this even if the switch is attached to a circuit board.
- Next, assuming the switch tested okay, I’d test continuity of each of the wires between the switch and the connector for the control board with the endstop unplugged. There may be a bad wire, or a bad crimp, or a connector slipped up inside a connector end. This gets more tricky if there’s a circuit board involved, but you should still be able to check each conductor between the controller and the endstop. While doing this, be sure the ends of the cables match with regards to Signal, Ground, and Voltage (if present) conductors. The board reads a connection between the Signal and Ground pins as the switch being triggered. Many boards also provide a 5V pin to run the optical sensor or indicator LED. Make sure things are connected in the right direction.
- Next, being sure you’re working on the expected connection, connect the Signal and Ground pins of the board endstop connection (stay away from the V pin) with a known good jumper wire and try the M119 command again. If this still shows no change, then you’re looking at a firmware configuration problem.
One of these results should steer you toward the fix for your endstop switch trouble.