Marlin: Y homing issue

I've been trying to fix an issue with my Y homing function for quite some time. I would sincerely appreciate any help. Here is the situation:

I am currently using a Gen 6 Sanguino ATmega644P board, Arduino 0022, Marlin version "1.0.0 Beta 1". I use pronterface to do all my testing.

From a clean firmware install, several issues were present in the Y axis:

1. Y axis operated in an inverted manner
2. Y Homing went towards -Y, instead of +Y

Changing INVERT_Y_DIR from false to true did fix the inversion issue.

Changing Y_HOME_DIR from -1 to +1 did not fix the homing issue. When set on -1, it would, if allowed, move to the maximum -Y value without stopping. When set on +1, it would move only a small amount in some direction.

After trying many different possibilities (all involving options in the configuration.h section), I finally tried something else and this is where I am currently:

1. Kept Y_HOME_DIR on +1
2. Within pins.h under the Gen6 pin assignment, changed Y_MIN_PIN to -1 from 25
3. Within pins.h under the Gen6 pin assignment, changed Y_MAX_PIN to 25 from -1

This resulted in the Y axis moving towards the +Y direction as intended, hitting the endstop and ceasing motion.

It would not, however, return the correct response when prompted to continue +Y motion. Instead, after issuing another command to the Y axis; either +Y or -Y, it proceeds to move maximally towards -Y as it did before.

I have no idea what to do at this point. I've tried disabling the max_software_endstops to false from true, this has no effect.

The only thing I can think of is setting Y_MIN_PIN to some non-negative value. But I know absolutely nothing about pin configuration.

All suggestions are appreciated

Thanks for your time

Have you tried the latest Marlin on Github? I made some fixes to the homing and soft limits to support max endstops and they were merged in recently.

---

[www.hydraraptor.blogspot.com]

First, I'd like to apologize for never responding to your kind attempt to help nophead. I did try the latest version of Marlin, but it did not resolve the issue.

After being fed up with my machine not working (and myself), I finally decided to go into hypermode and get my machine working.

The problem arose after the homing. It somehow behaves as if it tries to home to Y_Min instead of performing the issued command. And this happens only after homing to max. I can use the control panel of pronterface to move the Y axis just fine, as long as I do not home to Y_MAX.

I reviewed the entire Marlin firmware, line for line, to understand how homing worked relative to everything else. I came to the following conclusion:

Homing is controlled by a function HOMEAXIS(LETTER) in the "Marlin" section of the firmware. The function behaves in two separate ways, depending on whether or not LETTER##_MIN_PIN or LETTER##_MAX_PIN (in this case LETTER## = Y) is greater than -1 AND on the value of LETTER##_HOME_DIR.

With the default firmware, Y_MIN_PIN is set to 25 and Y_MAX_PIN is set to -1.

As described previously, homing (after inverting the Y axis and changing Y_HOM_DIR to 1) would result in no motion.

I realized that this is because the HOMEAXIS function sets the current position to 0, and then moves to the current position. I verified this using the M114 function.

I couldn't think of a way to fix it with Y_MIN_PIN set to 25, so I switched (as described earlier) Y_MAX_PIN to 25 and Y_MIN_PIN to -1.

With the Y_MAX_PIN set greater than -1 and Y_HOME_DIR set to 1, The HOMEAXIS function would prefer the homing as intended, allowing the platform to hit the endstop and retract. After this, it issues the following command

current_position[LETTER##_AXIS] = (LETTER##_HOME_DIR == -1) ? 0 : LETTER##_MAX_LENGTH;\
plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);\
destination[LETTER##_AXIS] = current_position[LETTER##_AXIS];

Which sets the current position to the max length of the Y axis! This causes the continuing action described earlier. I verified this by changing the max length and observing how far it would travel before being issued an M84.

By changing the LETTER##_MAX_LENGTH reference to current_position[LETTER##_AXIS] (making it self referencing), the continued action problem was resolved!

The only problem with this solution is that the current_position it obtains is the current_position(LETTER##_AXIS) set at the beginning of the HOMEAXIS function, which is 0. I'm pretty sure that this will offset the printing operation, since the printer believes the Y axis is at the origin, instead of where it was once before.

I am not sure what you are saying. If you home to the max endstop then it should set the position to MAX_LENGTH. You should then only be able to move in the negative direction and 0 would correspond to the other end of the axis, where one would normally have a min endstop.

---

[www.hydraraptor.blogspot.com]

That sounds like the way the firmware was intended to work. However, in my case, it seems like once the HOMEAXIS function sets the position to MAX_LENGTH, somewhere along the line, the axis gets reversed, and the machine believes it is not at the MAX_LENGTH. The strange thing is, if I execute M114 (with MAX_LENGTH used in HOMEAXIS) after it reaches the endstop, it reports the MAX_LENGTH value. Nonetheless, it still tries to travel the MAX_LENGTH value, but in the opposite direction. Executing M114 after it does this reports the distance that it should have traveled (i.e if I issue a +/- 10 command, it reads that value). So even though it reaches the endstop and retracts, it doesn't believe it's at the endstop; it won't try to travel in the positive direction though, only negative for an amount equal to MAX_LENGTH.

Sorry but all you have said seem like the correct behaviour to me. We seem to be misunderstanding each other.

I have Z at the top, use a max switch and it all works as I expect it to. When it hits the top limit it knows it is the maximum positive value and will only travel in the negative direction.

---

[www.hydraraptor.blogspot.com]

I have my Z set at max also.
In Marlin there does appear to be a bug where the position is set to the MAX_LENGTH and not HOME_POSITION, but in practice they are both set to the same anyway.
The only issue I had doing this was having to disable the Z MIN endstop and the other MAX endstops in pins.h, not doing this caused the back off and approach the endstop a second time code to fail because the endstops were enabled for the homing process and they we're always triggered in the direction opposed to the homing direction.
I guess I could also have shorted the unused endstops.

What Polygonhell says is very interesting, I would have never thought to disable both MAX and MIN pins. I'll have to check this out when I return next week.

I'll try to describe it one more time, and if this is the correct behavior, then I'll be damned for all that unnecessary effort!

1. Platform starts at an arbitrary position between Y_MIN and Y_MAX
2. Homing command is sent
3. Platform travels to Y_MAX, retracts, and rests at Y_MAX
4. Upon issuing any command, Platform travels to Y_MIN.

This is contrast to, say, the X axis or Z axis. For example, my X axis endstop is on the negative side. It will home, retract and wait. Issuing an additional negative X command will trigger an endstop hit. Issuing a positive X command will move it the desired amount. It does not move all the way to the maximum X value, as the Y axis does.

Is this behavior correct?

No 4 is not correct. Any command or just G1 / G0?

I can't think why it would do that. My Z certainly doesn't and the same code is used for all axes.

---

[www.hydraraptor.blogspot.com]

Just G1/G0. It could be an issue with pronterface, but I don't have a clue. I'll do alittle more research when I return after the weekend. Hopefully my little fix doesn't interact with printing.

Hello ACityofOne, did you ever resolve this issue? I have a similar one in which the y-axis prints are flipped (mirrored) compared to the picture on the 3D preview. I'm using Repetier Host, but the same issue exists with Pronterface. I currently have my printer set up such that when the positive y-axis button is clicked, the bed moves away, and when negative is clicked, the bed moves towards the front (where I have the y-axis motor mounted). This forms a right-hand Cartesian coordinate system with positive z pointing upwards. I've tried the following, and have had the same results as ACityofOne:

"Changing INVERT_Y_DIR from false to true did fix the inversion issue.

Changing Y_HOME_DIR from -1 to +1 did not fix the homing issue. When set on -1, it would, if allowed, move to the maximum -Y value without stopping. When set on +1, it would move only a small amount in some direction. "


Thanks!

Zangetsu57 Wrote:
-------------------------------------------------------
> same issue exists with Pronterface. I currently
> have my printer set up such that when the positive
> y-axis button is clicked, the bed moves away, and
> when negative is clicked, the bed moves towards
> the front (where I have the y-axis motor mounted).

This is a common misconception, the bed should move towards the front when Y+ is clicked, assuming that (0,0,0) is at the front left (standard setup).

Remember that the coordinate system is with respect to the toolhead only, regardless of whether the head moves or the table moves.

Thanks for the reply, I'll try to make the appropriate changes in firmware.

My Z-axis is having trouble of a different sort. I'm retrofitting RAMPS to my Makerbot Cupcake, and this is the last bit I need before it works.

If you're looking at the front of the machine, the Y-MIN endstop is at the back, the X-MIN endstop is on the right, and the Z-MAX one is near the top.

The X and Y ones work just fine, the problem lies with the Z-homing. I issue the command, and Z homes first to get out of the way. Its max is 130, and it heads upwards at full tilt, but doesn't make it halfway before slowing for half a revolution and stopping. It seems to move the same distance each time, but I don't know for sure.

I've tried disabling the software endstops, and messing with the steps and homing speed, all in Configuration.h, but to no avail. Any advice?

wrong thread

Edited 2 time(s). Last edit at 06/18/2013 02:30PM by bigfilsing.