M119 shows them as open, and they do not show as triggered when I manually depress one before I run M119
On the more pressing issue (I would like to resolve the endstop issue after I resolve the homing direction) I now tried reversing the stepper plugs. To make them move in the correct direction, I had to set the X and Y_INVERT_DIR to true.
Even in this state, it still homes to max when told to home to min, and homes to min when told to home to max. Is there something else other than X/Y_INVERT_DIR or HOME_X/Y_DIR or reversing the stepper plugs that will change the direction of homing?
I think it is homing in the right direction but the switch is seen as already triggered. What you’re interpreting as moving in the wrong direction is the second part of homing where it moves off the switch.
The homing cycle depends on the state of the switches being properly reported and interpreted. I’d get the switches sorted out first, then the rest of homing will probably work as you expect it to.
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.
@sonoyuu, it doesn’t help to argue with us. We are trying to help.
I always make sure M119 and the direction are correct before I send a home command. It doesn’t help to try the home if M119 is incorrect, it just makes things more complicated.
You are pure awesome. Thank you for taking the time to write that out and explain it so thoroughly. It seems I had the ground connector on both x and y attached to 5v. Once I corrected the wiring, the endstops worked, and so did homing. I seriously wish I could at least buy you a coffee, because you just ended a week of struggling with this.
I apologize, I wasn’t intending on arguing. I have had a very frustrating week with this board. My new problem is it wont start a print because it is returning a filament runout error even though filament runout is disabled in Marlin.
I don’t even know where to troubleshoot this one. I have tried 3 firmware configurations from 3 different people, and tried doing a from scratch Marlin build and they all return this error when I go to print. I’d really love to just start printing again.
I’m sorry too. That came off much more defensive than I was meaning. It happens sometimes that people don’t accept advice when they ask for it. I think I am projecting other experiences onto you. I just want to help people learn and solve the puzzles. Sometimes people have spent so much time on their own that they can’t see it any other way.
Well, the software isn’t magic. It must be enabled. Are you sure you are changing the software on the board? How did you disable it? Maybe it is stored in eeprom and you need to reset eeprom with M502?
I agree with @jeffeb3 - if the sensor is stopping the print then it must be enabled in the firmware.
I just had problems with my filament sensor and got them sorted out, so lots of that research is fresh in my mind. What extruder and sensor are you using? Troubleshooting this is much more tailored to specific components than the endstop steps.
I’m new here so not sure if I’m doing this correctly but…
I’m running SKR 1.2 purchased from V1 store.
I have just built a low rider 2 with dual end stops, everything is moving in the correct direction but when I home the Y axis it moves in the wrong direction (-Y) I’d like it to home +Y, X and Z work correctly.
It is tricky to change the homing direction. Especially with the low rider. You can change the Y_HOME_DIR. But then you need to change the Y2 endstop pin to something else.
hello, I know. The x,y,z are going the wrong way by a few mm because the motherboard is detecting for pressing the limiters. you need to change in filmware “#define X_MIN_ENDSTOP_INVERTING FALSE” to “#define X_MIN_ENDSTOP_INVERTING TRUE” . In my case it solved the problem
Hi, I’ve been reading through this and many other threads about the same issue. However, it’s a little different for me. I have a cr10 that was working well, but I decided to upgrade to the wham bam plate. So I took the plate off and did the switch. Now, when homing, the Y goes away from the limit switch and grinds the stepper motor and belt. I have changed nothing expect the build plate. I don’t use any code software, still really new at this. I do have repetier now, and when I run M119, its shows all as open. When I manually jog, it travels as it should in the correct way. Any ideas?
Our X-axis is moving properly when printing from initial point till the nth point. However, as it goes to the next y line, the x doesn’t go back to its initial point.
We also try to use a limit switch, but when it is triggered, it only stopped the system instead of homing the the x axis.
I suggest you open your questions as a new topic, and you expand on what is going on. Is your behavior happening when you are trying to run a job? We can tell a lot from the g-code, so uploading it to a post is very helpful. Telling us the tool you are using to generate the g-code would also be helpful.
How do you manually move your axes (display, Repetier-Host, other)? Do they move property when moved manually? Is this only a problem when running a g-code file?