2.8pre gantry racking

I've been trying to configure homing switches on my 2.8.0-pre1-3723-g0661d4b gantry system with partial luck. Appreciate any help ...

The gantry is the X axis.
There are only homing switches, no limit switches.
The X0 micro-switch is wired in parallel with the Y axis micro-switch.
The X1 micro-switch is wired in parallel with the Z axis micro-switch.
All the micro-switches show FALSE in the HAL-meter and show True when tripped.
The HOME_SEQUENCE is Z(0), Y(1), X0(-2) & X1(-2)

Z and Y home perfectly. They are not touching the micro-switches after they are homed so the switches are back to NO.
X0 and X1 travel together in the correct direction, X0 hits the micro-switch and backs off but X1 hits the switch and keeps going. Sigh.

Attached are my ini and hal files. I've googled but my foo is failing me this time ...

TIA,
Rick

Yes, hal meter shows the expected signal states. All FALSE until a micro switch is tripped, then TRUE.

Both sides of X have HOME_SEQUENCE = -2

Appreciate the assist.
Rick

You have your X0 & X1 axes homing with -2 -- could this be doing it:

"The initial HOME_SEQUENCE number may be 0, 1 (or -1). The absolute value of sequence numbers must increment by one — skipping sequence numbers is not supported. If a sequence number is omitted, "Home All" homing will stop upon completion of the last valid sequence number."

linuxcnc.org/docs/devel/html/config/ini-...homing-configuration

Have you tried using -1 for your X sequence? That would appear to adhere to the "absolute value incrementing by 1" guidance.

I could not see anything obvious anywhere other than the -2 for HOME_SEQUENCE mentioned earlier. Gantry homing has been rock solid in the 2.8 development branch for the 18 months I've been using it. Thats not to say I have not had a configuration error or two setting it up. If changing HOME_SEQUENCE to -1 does not fix it, my bet is you have a wiring error more than a config error but I've never shared home switch circuits. I can't see that would be an issue.

Just my 10 cents worth.

I would test it without the Z and Y being paralleled up so as to take them out of the equation

Thanks all, you have given me some more diagnostics.

Stay tuned ...

Rick

Update: It ain't fun being in the Twilight Zone ... 8-)

here are the relevant lines from the hal file:
# home switches: X0 and Y are parallel NO, X1 and Z are parallel NO
net home-x0y <= parport.0.pin-11-in-not
net home-x1z <= parport.0.pin-12-in-not

# home switches: joints are X0 X1 Y2 Z3
net home-x0y => joint.0.home-sw-in
net home-x1z => joint.1.home-sw-in
net home-x0y => joint.2.home-sw-in
net home-x1z => joint.3.home-sw-in

@ DanMN: I changed the HOME_SEQUENCE to -1 from -2 for the gantry X and it didn't make a difference.
@ andypugh: The joint.0.home-state and joint.1.home-state pins never change from 0, the gantry X axis never completes the homing.
@rodW: will check wiring again ...
@clive: Y and Z taken out of commission in the ini file, no difference.

Ok, this is where it gets stranger.
Y and Z are now out of commission in the ini file.
Swap the wires on the parallel port pins 11 and 12, expecting X0 to gag instead of X1. Again, no Y or Z in the HOME_SEQUENCE, Y and Z are set to manual home, and now the gantry X homes perfectly!!! Swap the pins back, and it racks. Weird, but I can live with this.

With the pins swapped, and Y and Z in the HOME_SEQUENCE as Z-Y-X, now Z and Y disregard the micro-switches. Agghhh!!! Of course, I have to hit the STOP to stop the grinding, and it never continues on to home the gantry X. At this point, I can use the drop down menu to manually select just the gantry X and it will home perfectly. Grrrr.

At this point, unless someone has some more insight, I'm going to wire up a second parallel port for more input lines.

Thanks again all,
Rick