Welcome! Log In Create A New Profile

Advanced

Homing in Marlin

Posted by revwarguy 
Homing in Marlin
March 07, 2014 03:45PM
Hello, I am hoping for a response with someone familiar with the Marlin code... (by this, I mean the Delta modifed Marlin code from Johann - its for a mini Kossel)

My questions have to do with homing.

When using the full Graphics LCD interface, what exactly happens when you press "autohome" as a menu selection under the "prepare" menu item? Does this just execute a G28, or something else?

In either case, what exactly is supposed to happen when homing is executed? I gather that each axis is increased (direction as defined in configuration.h) until it the max homing switches are triggered for each axis. Then what? On mine, the carriages stop just as soon as contact is made and the stops with the switches still depressed. I have read of a behavior where it then is supposed to back off and try again slowly for accuracy. Just for documentations sake, could someone who knows where this code is in Marlin take a look and describe just what is supposed to happen? What variables are then set by this and how are they used later?

Please include the file and location in the code that does this, if possible.

Thanks in advance,

Edited 4 time(s). Last edit at 03/07/2014 03:51PM by revwarguy.
Re: Homing in Marlin
March 07, 2014 04:07PM
Having nearly the same issue with mine.

I had mine working well - then blew F2 fuse. Now, not working right on homing. But...

When it was - Autohome was just issuing a G28 (AFAIK). Each axis would return up, then trip the switches, and then move down about 5mm. They happened in succession, not simultaneously.

I know it's not the full answer you're looking for but maybe it'll help.

Dave
Re: Homing in Marlin
March 07, 2014 04:23PM
Here's a video of what's happening for me. [youtu.be]
Re: Homing in Marlin
March 07, 2014 05:59PM
Found my problem - Y and Z end probes were reversed on the board.
Re: Homing in Marlin
March 08, 2014 11:19AM
Ok, I did some looking. I still don't see where the LCD menu is processed to see if the selection is the same as doing a G28, but I'm going to assume it does.

The G28 command is implemented in Marlin.cpp starting at line 996. There is conditional code for Deltas there, since it needs to home up all three axes at once. To do this, it sets the feedrate at 1.732 times the nominal homing feedrate with no comment. (What is that about - i.e., why the hard-coded weird number 1.732?) Also, it sets the max length of travel until switch trigger at 3 times Z_MAX_LENGTH (why so much - isn't 1.1 already more than what is possible?) It then calls a routine called endstops_hit_on_purpose() which I couldn't find anywhere to see what that does.

After raising all three carriages until any one of the switches is hit, it then calls the regular home routine, homeaxis(int axis) at line 766 for each axis in order, which disables the endstops, backs off the carriages and tries again at the nominal feedrate, then moves the axis up at the homing_feed_rate divided by 10 (for Deltas) until the stop switch is triggered, and then sets the current position and calls axis_is_at_home which resets the max and min lengths.

So, it looks like the expected behavior from doing a "prepare...homing" menu selection is for all three axes to travel up at 1.732 times the homing rate until one of the microswitches are triggered, and then one at a time, each axis backs off a nominal amount (HOME_RETRACT_MM) and re-ascends at 1/10th of the homing_feed_rate until the stop is triggered, and then the carriages are left there.

I must have a problem since I do not see the back-off occurring.

Edited 5 time(s). Last edit at 03/08/2014 11:28AM by revwarguy.
Re: Homing in Marlin
March 09, 2014 04:09AM
Quote
revwarguy
The G28 command is implemented in Marlin.cpp starting at line 996. There is conditional code for Deltas there, since it needs to home up all three axes at once. To do this, it sets the feedrate at 1.732 times the nominal homing feedrate with no comment. (What is that about - i.e., why the hard-coded weird number 1.732?)
It is about sqrt(3). So it is possible that author somehow thought that sin(60°) or cos(30°) should be involved. But I do not have a clue why.

Quote
revwarguy
Also, it sets the max length of travel until switch trigger at 3 times Z_MAX_LENGTH (why so much - isn't 1.1 already more than what is possible?)
1.1*Z_MAX_LENGTH is not not enough but Z_MAX_LENGTH+DELTA_DIAGONAL_ROD would be enough if the printer is already callibrated. The best value would be FLOAT_MAX/k where k is a safety factor which would be determined based on the planner code so that no overflow can happen.

Quote
revwarguy
It then calls a routine called endstops_hit_on_purpose() which I couldn't find anywhere to see what that does.
It is in stepper.cpp. It just clears flags that endstops were hit.
This way the code indicates that the endstop hit was processed at the higher levels.

Quote
revwarguy
I must have a problem since I do not see the back-off occurring.
Probably, I do not use LCD so I'm not sure it calls the same homing code.
Re: Homing in Marlin
March 09, 2014 09:49AM
Thanks, Peter, for the reply!

Quote
hercek
Quote
revwarguy
The G28 command is implemented in Marlin.cpp starting at line 996. There is conditional code for Deltas there, since it needs to home up all three axes at once. To do this, it sets the feedrate at 1.732 times the nominal homing feedrate with no comment. (What is that about - i.e., why the hard-coded weird number 1.732?)
It is about sqrt(3). So it is possible that author somehow thought that sin(60°) or cos(30°) should be involved. But I do not have a clue why.

This number is also about my expenditures divided by my income for last month :^) but what's that got to do with homing? Always find it strange when hardcoded odd numbers get used without comment!

Quote
revwarguy
Also, it sets the max length of travel until switch trigger at 3 times Z_MAX_LENGTH (why so much - isn't 1.1 already more than what is possible?)
1.1*Z_MAX_LENGTH is not not enough but Z_MAX_LENGTH+DELTA_DIAGONAL_ROD would be enough if the printer is already callibrated. The best value would be FLOAT_MAX/k where k is a safety factor which would be determined based on the planner code so that no overflow can happen.

Ah, the "if already calibrated" point is well taken.

Quote
revwarguy
I must have a problem since I do not see the back-off occurring.
Probably, I do not use LCD so I'm not sure it calls the same homing code.

I found where the menu item for "prepare...autohome" just does a G28 - its at line 350 in ultralcd.cpp

I'll look into what is going on with my G28
.

Edited 2 time(s). Last edit at 03/09/2014 10:06AM by revwarguy.
Sorry, only registered users may post in this forum.

Click here to login