Auto homing doesn't recognize max limits [SOLVED]


Does anyone have any ideas? Possible fixes? Steps to try? Are there any config settings to edit manually when flashing an arduino? Could it be a hardware problem?
I can’t print anything until I fix this

I recently replaced my arduino, which involved flashing the firmware onto a new arduino. Everything in the config looks great and the printer “works”, that is the motors move and move at the correct steps, the extruder and bed heat up fine. The problem I’m having is that when the printer tries to auto level, it never stops going towards the “max” end of the axis, away from the limit switches. It does the first bit of the function fine (finding 0 at X, Y, and Z) but then immediately afterwards begins to head towards the top right corner while the bed crashes into the front of the printer. The motors continue to try moving even after they have been hit their max indefinitely.

I checked the config file, and the dimensions for the “max” seem to be okay. Any ideas?

EDIT: It seems like the auto home function has the printer “reversed”. After it touches the X, Y, and Z end stops, it heads over to the left side again like it is trying to raise the z probe on the incorrect side. After doing that it seems to just get stuck in a loop of activating all motors at the same time, as it climbs into the top corner.

I also tried setting the max limits to 100 (rather than 200, 300, 200) but this did not change anything.

EDIT 2: I just flashed the Feb 23 version of mjrice’s Marlin, auto leveling didn’t end crashing into the corner. Will attempt a print with it.

The Feb 23 version did not work, I am unaware if this version had proper implementation of the new z probing system yet because it ran the extruder apparatus into the right wall during bed leveling, which raised the probe. It continued to “probe” the bed with the extruder head itself, apparently happy with the measurements it was getting by pushing the glass down 5 or 6 mm.

Video of Issue (warning: loud and vertical)


I am also having a similar problem. Mine hits the x and y end stops and trys the z but it doesn’t move to the center. It then does the same thing yours did.

I noticed that one of your linear bearings on the right side is stuck near the top.


About the linear bearing-- Its been doing that since day 1, the printed casing is slightly too large to hold it and the pole is slightly out of tolerance; not enough to inhibit printing but enough to make the bearing stick. The lower bearing stays in fine, however.


Could this be a mechanical problem? The ramps board interpreting both + and - movements as +?


Have you tried setting “Right Stop Pos” to 200? It’s under Control/Motion, all the way at the bottom. Store memory after set.


@Rockey I’d like to buy you a drink sometime!

The display was bugged and showed the Right Stop Pos to be 200, but when I went in to edit it it was actually 100. By setting it correctly to 200, the problem is fixed!


I have set mine to 198. On my Willson, it’s the perfect value to reset the z-probe after the auto home runs. I still have an odd issue. If I just “auto home” everything works great. If I run the auto bed leveling routine, the homing works fine, but after the 4 point probing the x-axis bottoms out again. this causes the x-axis to be short.
This seems like the right stop position value is not global. It’s used in the auto home, but not in the bed leveling.


Interesting-- I’m not sure I have the same problem. Are you saying your x axis is inhibiting the size of print you can do past its physical limits? or is this a problem that is causing you to be unable to print?


HI Guys,

I’m trying to work out what could be wrong here. The first thing is let’s make sure we’re all running the same code. If you are not using GIT to sync the project files locally, then you can download a zip of all the files from this link:

The right stop value is something I recently added to the EEPROM, so that i could be changed on the fly from the LCD. It should be persistent (assuming you go to Control->Store settings) and the value is used in the bed leveling retraction algorithm so that behavior @revnull reported doesn’t make sense to me.

Anybody who is still having trouble, please explain again if necessary what commands work and how things go wrong from there.


After the 4 point probe, the x-axis slides to the right to push the z-probe rack back in place. It over shoots and the belt skips a few times, then slides back to the left most home position. Because the motor doesn’t know there were belt skips the x-home is now a few MM off to the left. This not only reduces my x-axis print area, but will chew up my belt over time.

This was also happening with auto home when I had the max right position set to 200. Setting it to 198 fixed auto home. If the same max right position was honored after bed leveling, X should not bottom out.


There seem to be two problems people have with the April 2nd commit. I’ve had both.

The first problem with auto home crashing into the right side, described in the OP, is resolved by setting Right Stop Pos in Marlin.

The second problem with auto bed level is as @revnull describes well here. @douginarug describes similar behavior here. My description follows his post.

I’ve been poking around the code, trying to find the issue but I’m a novice and haven’t had any luck.


This is the problem that I’m seeing.


Exactly the same problem here.


@mjrice does this happen on your Wilson IIs? All things being equal, everyone running the same rack system and firmware should see the same issue.


Guys, the first time I flashed with the latest firmware and tried to auto home, my printer seemed to be lost after probing z and hit the right side. When I looked at the right stop value, it was zero. I manually set it to 200 and stored in memory and that fixed the problem for auto home. I have since flashed again and the stored value seems to stay put. It’s just that first time it didn’t write a value or something. I am still having problems with auto bed level hitting on the right. I posted details in the auto bed level thread.


I’m seeing the same thing. Auto home works fine, but auto bed level gets an offset on the x axis and hits the right side and when finished x is off by 12 mm.


Ok @revnull @rockey @rwatkins2112 I think I’ve found the problem. During the homing/bed leveling routine, the firmware was loosing track of the actual X position, so that at the end when it tried to go to 200mm (or whatever you have the x stop position set to in eeprom) it was actually trying to go 15mm farther. I’ve patched it and been testing it all morning, and it seems to be behaving now.

If you aren’t using git to pull the source code, here is the link to download the zip file containing it all at once:

Let me know if you have any other problems with it!


I’ve pulled the latest release from and loaded it. I’m getting a beep or alarm on the second Z probe of the auto home routine and a longer, oscillating beep/alarm on the last Z probe of the bed level routine which appears to abort the routine and does not retract the Z probe.

On the bed leveling routine I seem to be falling into the “if((int)current_position[X_AXIS]!=15)” case which seems odd because the LCD is showing that X is 15 while the alarm goes off but it then displays the coefficients and afterwards X is 14.

In case it’s relevant, my X axis seems a little short and I have X_MAX_POS and x_right_stop_pos set to 196.

Edit: I commented the return; in “if((int)current_position[X_AXIS]!=15)” and the bed level completed and retracted the Z probe. Afterwards I moved to X 0 and X Max and the axis still seems accurate. The resulting coefficients seem way off from what they used to be. The last coefficient used to be around 7.0 and now is 1.X.


I just tried it to and it looks like it’s working for me. It is beeping on auto home z probe and the last probe on auto bed level. I don’t think it affects anything.


@Rockey I added the tones while I was troubleshooting the problem, to tell me where it was hitting certain points. However, it shouldn’t get trapped by that test (on mine it does not make those rapid beeps) but I think it’s ok to just commend out that code (like you did). I am not sure why the coefficients would be different, but let’s see if it works and go from there.