When I try to home my machine, the X-axis moves towards the max position instead of the min position. I have set the direction to min in the firmware. Any ideas what’s going on?
// Direction of endstops when homing; 1=MAX, -1=MIN
// :[-1,1]
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1
Do the axes move in the expected direction when jogging manually?
Yes, they move in the correct direction manually, just not when homing. I’m using Marlin 2.0.
It’s possible the axis direction is reversed (inverted) in firmware. I know the common answer to moving the wrong way is to flip the motor connector, but for homing to work all the firmware sttings need to agree on direction.
A test would be to try switching homing to max. If things then work as expected, you’ll need to invert the axis direction and homing direction in firmware (or EEPROM), and then (with all power disconnected) flip the motor connector.
I did invert the axis in octoprint. I guess the firmware doesn’t know that and still thinks min is in the opposite direction. I’ll try inverting it in the firmware instead.
On a separate note, I tried reversing the homing direction in the firmware and it just keeps moving in the same direction. It’s like the firmware setting get ignored even though I used the M502 and M500 commands to update the EEPROM.
Yeah, don’t do that. Just flip the stepper plug, and get rid of the inversion in octoprint.
Thanks Jeff. That fixed it. Pretty obvious now that I think of it.
I have a similar issue, but different with Marlin 2.0 as I am not using octoprint, so this is strictly marlin from the TFT 3.5 menu, there is no where else I can have “inverted” it like with the octoprint example.
I have SKR 1.4, TFT 3.5, and an Ender 5 with Micro Swiss DD extruder and hotend.
From the movement menu, all axis respond as expected. It heats bed and nozzle with no issues, and it extrudes in the correct direction when told to do so. The BLTouch correctly homes the z axis. It works 100% no issues with the Creality board, so I am going with this being strictly a firmware issue. I confirmed this by plugging everything back into the Creality where it functioned with no issues.
Basically, it won’t home properly. When I tell it to home x, it only moves 1mm in the wrong direction, the same for y, and when you tell it to just home, it goes the opposite direction of the endstops. The same issue as OP reported, but as I am not using Octoprint or a similar intermediary, I can’t use the solution which worked for him.
I have tested switching the direction of endstops when homing to max, and it homes in the direction of XMin/YMin, but then the end stops do not work even when plugged into XMax and YMax.
Any suggestions?
Could the logic of the stops be reversed, or physically wired Normally Closed when firmware expects Normally Open (or vise versa)? What does M119 tell you?
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.
I have tried both inverting the logic and leaving it as the default which other Ender 5 User have done.
The default for Marlin and for the othert Ender 5 Users is:
define X_MIN_ENDSTOP_INVERTING false
When I have it set as that, M119 reports triggered on xmin and ymin.
When I set it as
define X_MIN_ENDSTOP_INVERTING true
M119 reports xmin and ymin are open.
With either true or false, M119 does not show a change when the switch is held down before running M119.
Also, whether it is in triggered or open state in M119, it still homes the opposite of what is set in the firmware
A fairly common homing cycle runs like this:
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:
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.
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’m glad to hear your homing issues are resolved.
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 replied in your other topic.