Homing issues with Marlin

Hi,

I'm trying to switch from sprinter to Marlin (RC2) and I'm running into issues with homing. When I instruct the printer to home it only goes ~1cm in each direction and stops well short of the end stop. If I manually move the head so that the 0 position is in this small window the printer will correctly stop at the end stop. It does not do the slight bounce on the end stop I anticipated coming from Sprinter. This happens if I use the pronterface home command or manually send the G28 command.

If I use M119 and hold the end stops with my hand they seem to be correctly triggering. If I instruct it to move toward a 0 and push that end stop by hand the printer does not react. My understanding is that this is correct behavior for Marlin which only checks the end stops during homing. If I hold an end stop and tell it to home it will not move on the axis I'm currently triggering.

It seems to me like there is only a small search window it will check for the end stops. I can work around this by manual starting it close to the home or spamming home commands until I’m sure it has reached the home but I'm curious if there is some real fix for this.

Thanks.

Sounds like you need to invert the endstops in Marlin.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I thought the logic was right since it stopped moving when I pushed it by hand during a G28 command. I gave that a try anyway and the results are different but still not right.

If I reverse the end stop logic it now does the slight bounce when I manually push the end stop. It still only searches about 1 cm though and now is searches in the wrong direction.

I'm not sure if this is better since now it doesn't seem mutually consistent. For example it 'knows' which way is up when I tell it to move up a few mm. However it is also told that the z end stop is at the minimum and it searches upwards for it. I can probably fix all that by moving end stops or reversing axes but it doesn’t solve the only searches 1 cm problem.

My 2 cents:
1. You may have your software endstops set wrong, making it think your print area is smaller than it is.
2. Possibly in combination with #1, if you didn't copy your steps/mm over from sprinter it might think it has moved 16cm when it has moved 1cm

I looked at that too. If I tell it to move a few cm it moves about the right distance. I haven’t measured it exactly but I copied over the values from sprinter and it looks reasonable. The software limits I set are only ~15% smaller then the default so I doubt that is the issue either.

I’m still confused as to why it seems to work a little better with the end stop logic reversed. My understanding is that marlin is forked from sprinter and my end stop logic was not inverted in sprinter nor have I not made any hardware changes. I should be anticipating a slight bounce on the end stop with Marlin as in Sprinter right? I’m not sure how similar they are in regards to blindly trusting that I can keep axes and end stop logic the same though.

Is it the endstop pullups?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

tsb4k Wrote:
-------------------------------------------------------
> My 2 cents:
> 1. You may have your software endstops set wrong,
> making it think your print area is smaller than it
> is.
> 2. Possibly in combination with #1, if you didn't
> copy your steps/mm over from sprinter it might
> think it has moved 16cm when it has moved 1cm


This seems to be correct. I disabled the software end stops all together and now it homes fine despite them being rather large as it was. It seems to still be having a number of other problems though. I guess I'll give it a few more chances to get nice prints before I roll back to Sprinter.

I am having the same issues having switched from Sprinter to Marlin. When I click home it moves and immediately stops. I have opto stops with a gen 6 electronics, I have tried putting cardboard inbetween sensors, ive tried switching the logic of the opto stops....

In pronter face my positive direction is correct but home and negative are not working. If you got it to work, can you possibly post your "mechanical" section in the configuration.h file so I can compare? I have speant hours and am stumped by this.

Sprinter was very fast and easy to set up the first time around, but wasnt happy with the quality of arcs and circles so I decided to try Marlin, if I can make it work!

---

Ryan
Quality Engineer & Hobbyist
thingsandtrains.blogspot.com

I never got it perform any better than my last post said. Disabling the software end stops in the Marlin configuration solved my initial problem with the short homing distance. However, I still had a great many issues with Marlin and I have rolled back to Sprinter.

It sounds like your problem is the same as my initial one though. The software end stops prevent it from moving below where it thinks the zero point is and for some reason seemed to affect it even when searching for the physical end stop. There is just a Boolean flag in the configuration.h to disable them but make sure you watch your next few prints since mine ended up smacking hard into the sides of the machine.

GOT IT! Wow this better be worth the changeover... here is my mechanical code if interested (steps not calibrated yet)

// Endstop Settings
//#define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors

// The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
const bool X_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops.
const bool Y_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops.
const bool Z_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops.
//#define DISABLE_MAX_ENDSTOPS

// For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1
#define X_ENABLE_ON 0
#define Y_ENABLE_ON 0
#define Z_ENABLE_ON 0
#define E_ENABLE_ON 0 // For all extruders

// Disables axis when it's not being used.
#define DISABLE_X true
#define DISABLE_Y true
#define DISABLE_Z true
#define DISABLE_E true

#define INVERT_X_DIR false // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR true // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR false // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false

// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define min_software_endstops true //If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops false //If true, axis won't move to coordinates greater than the defined lengths below.
#define X_MAX_LENGTH 180
#define Y_MAX_LENGTH 180
#define Z_MAX_LENGTH 40

// The position of the homing switches. Use MAX_LENGTH * -0.5 if the center should be 0, 0, 0
#define X_HOME_POS 0
#define Y_HOME_POS 0
#define Z_HOME_POS 0

//// MOVEMENT SETTINGS
#define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E
#define HOMING_FEEDRATE {20*60, 20*60, 1*60, 0} // set the homing speeds (mm/min)

// default settings

#define DEFAULT_AXIS_STEPS_PER_UNIT {31,31,1259,353} // steps per unit for ultimaker
#define DEFAULT_MAX_FEEDRATE {500, 500, 5, 45} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {9000,9000,100,10000} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.

#define DEFAULT_ACCELERATION 3000 // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION 3000 // X, Y, Z and E max acceleration in mm/s^2 for r retracts

//
#define DEFAULT_XYJERK 20.0 // (mm/sec)
#define DEFAULT_ZJERK 0.4 // (mm/sec)
#define DEFAULT_EJERK 5.0 // (mm/sec)


it successfully moves +/- and homes! wow 3 nigths of work

---

Ryan
Quality Engineer & Hobbyist
thingsandtrains.blogspot.com

banthafodder7400 Wrote:

>
> it successfully moves +/- and homes! wow 3 nigths
> of work

Thanks Ryan that helped.

Well its 10pm now and I think I finally have it working too. Several hours.
I also had to (in the advance config file):
comment out #define ENDSTOPS_ONLY_FOR_HOMING had stopped me hand tweaking the z end stop posiiton.
the line looks a bit dangerous anyway. Presumably a speed trade off.

in pins.h
set #define X_MAX_PIN -1
same for Y and Z

which I think brought back the debounce on homing a la sprinter. Having spent enough time on time on this I havent the inclination to reverse the edit & test.


Edit, next day: Nope, still not working. The problem with not being able to nudge the z endstop is back. Since I hadnt changed the firmware since the last post, must have still been thre, or some other problem. Looks like on startup marlin assumes the z is at it lowest limit.

Time guillotine on marlin.

Pleasure to return to sprinter.

Edited 1 time(s). Last edit at 05/22/2012 03:10PM by 3D2B.

I was having the same issue, and I found that setting

#define min_software_endstops = false

solved the homing issue.

I have the same problem with my new MendelMax with RAMPS 1.4.

(#define min_software_endstops = false) will allow me to home, however, you lose the use of the soft-stop to prevent accidental ramming of the carriage pass home and displace the home switch.

My first RepRap, a Prusa with Gen6 controller running the same software, works perfectly with no homing issues, and retains the use of the Min soft-stop.

Only thing I can think of is that there is a RAMPS 1.4 compatibility issue with Marlin.

I too am having the same issue having switched from Sprinter to Marlin. When I click home it moves and immediately stops. There's no bounce back motion. I noticed in the configuration_adv.h file there is:

//homing hits the endstop, then retracts by this distance, before it tries to slowly bump again:
#define X_HOME_RETRACT_MM 5
#define Y_HOME_RETRACT_MM 5
#define Z_HOME_RETRACT_MM 1

but doesn't describe how to activate.

It's on all the time, the reason you're not seeing the bounce off the endstops is probably because you have nothing connected to the MAX endstops so when it hits the Min endstop and tries to go +ve it immediately thinks it hit the right endstop so it doesn't bounce off.
It manages to run after homing because of the #define ENDSTOPS_ONLY_FOR_HOMING

You can either specify
#define DISABLE_MAX_ENDSTOPS in config.h
or you can set the unused pin assignments to -1 in pins.h

Uncommenting #define DISABLE_MAX_ENDSTOPS solved the problem with end stops for me.