Marlin firmware not homing correctly

I have a DIY delta printer using RAMPS 1.4/Arduino Mega 2650. I first tried Repetier-Firmware but couldn't get anything to work properly so I switched to Marlin with much better luck. At first I was using an older version of Marlin (files dated 2015-01-11) that worked correctly for homing (all carriages return to MAX position), but when I issue a 'G1 Z-10' manual command the Y and Z carriages descend slightly (more than 10mm), but the X carriage descends all the way down the tower until I kill the power before it breaks the diagonal rods.
So, I then tried the latest marlin firmware release as posted on the marlinfw,org site (1.1.6), using the generic delta example configuration as the baseline. This version will not home properly: the Y and Z carriages home to the MAX point, but the X carriage doesn't move.
I am finding this exercise extremely frustrating as I can't seem to find a version of marlin that works for everything. Some versions work for homing, but not for manual effector positioning, some work for manual positioning, but not homing, etc.
I'm pretty sure it isn't a hardware issue, as all carriages move correctly in one version or another, but none of them work correctly for all homing and manual movement.
Can anyone point me to a version of marlin (or rep-fw) that actually works for delta printers. My printer is a pretty basic delta with a pretty standard hardware configuration - no fancy features, so I am very surprised at the amount of difficulty in finding a generic delta configuration that works. I would have thought it would be a pretty standard 'out-of-the-box' installation with a bit of tweaking for rod & carriage dimensions and offsets, etc.
Attached is my configuration.h file for the latest 1.1.6 build.

Update: I just tried the latest marlin-ac build (1.1.6-AC), that version homes correctly, but when I try G33 to auto-calibrate I get an 'M665 Bed radius is implausible' error. I have attached the AC version config file.

Edited 1 time(s). Last edit at 11/15/2017 12:47PM by cheddy.

// Set the radius for the calibration probe points - max DELTA_PRINTABLE_RADIUS*0.869 for non-eccentric probes
#define DELTA_CALIBRATION_RADIUS 121.5 // mm
...

// Print surface diameter/2 minus unreachable space (avoid collisions with vertical towers).
#define DELTA_PRINTABLE_RADIUS 120.0 // mm

So 120 * 0.869 = 104.28 is the maximum allowed for DELTA_CALIBRATION_RADIUS for a probe that uses the nozzle for an eccentric probe it's even less

Capisce? It's mistakes like this that causes all kind of problems. I would check your setup thoroughly if I were you and make sure everything works fine as expected before calibrating.

Edited 1 time(s). Last edit at 11/16/2017 04:21AM by LVD.

Ok, I see what you are saying. Thanks for pointing that out.
However, I seem to be having more basic problems than auto-calibration. Using your latest marlin (1.1.6-AC) my printer won't home properly. The Y and Z carriages home as expected but the X carriage stops about 10cm short of the endstop on the first home command. A second home command homes it correctly. Also, when homing the Y and Z carriages respond immediately, but the X carriage delays for a couple of seconds and emits a high-pitched whine while it waits. Is this expected behavior? Also, sending a 'G1 Z200' command after homing causes the X carriage to descend to the expect position, but the other two remain at the home position. I thought that Z movement commands would affect all 3 carriages. Also any X or Y movement commands cause the X carriage to move solely, no movement on the other two. I am starting to wonder if I have some hardware issues with the stepper drivers, etc. It looks almost as if the Y and Z motors are disconnected or not responding. However, the fact that they do respond when homing tends to discount that possiblity. I'm going to do some experimentation with swapping motors, drivers, and endstops, etc. and see if I can pinpoint a hardware issue.

BTW, do you know of any simple diagnostic firmware that can be used to just exercise the individual motors without all the extra processing overhead of the full blown marlin?

Thanks for your help.

Update: I swapped the X and Y motor and endstop connections and the above behavior moves from the X carriage to the Y carriage, which pretty well eliminates the possibility of any hardware issues (i.e. if it was a motor or driver issue I wouldn't expect it display the same behavior.) I suppose it could be an issue with the RAMPS shield itself, but the above test would seem to discount that theory. It does seem to point to a firmware issue. I don't see anything in the configuration that could affect individual motor operation. If DELTA is specified in the config, then the standard delta operative principles should pertain (i.e. all 3 carriages should move in response to movement commands.) I am now at an impasse, don't know what to try next. I have another RAMPS shield and set of stepper drivers on order, which I will try when they arrive, but I'm not very hopeful that will make any difference.

Edited 2 time(s). Last edit at 11/16/2017 11:22AM by cheddy.

Quote
cheddy
... above behavior moves from the X carriage to the Y carriage, which pretty well eliminates the possibility of any hardware issues

Could be a faulty board