After switch to Mesa 6i25 (5i25), home switches not recognized. [Mis-configured]

I still have a few problems left after the move from software step-generation on a parallel port to a Mesa 6i25 card. However, the axes XYZ all jog in LinuxCNC and "Run", back-and-forth, with the Test/Tune buttons in PncConf.

Problem 1:
The Home switches (all I have) are not recognized during the homing sequences.
Problem 2:
Curiously, the Open-loop button in PncConf for the Spindle does not turn it on, although it comes on immediately during when the Test/Tune button is pressed in any axis.
Potential Problem 3:
The probe input.

I am unable to run any G-code for testing because LinuxCNC requires the axes to be homed first--thus giving Problem 1 priority.

I'll present them as different topics.

My question here is how can I go about troubleshooting why the tripping of home switches (which are of the non-contact, metal-proximity type) is not detected? (I suspect the probe--in question will also resolve with this answer.) LEDs give visual confirmation that the switches have triggered.

They worked in the previous parport configuration.

After much fussing-about, I truly believe that I have .hal and .ini files which match the wiring. They are attached.

Thank you for some guidance.

# external input signals

# --- PROBE-IN ---
net probe-in <= hm2_5i25.0.gpio.003.in_not

# --- HOME-X ---
net home-x <= hm2_5i25.0.gpio.013.in_not

# --- HOME-Y ---
net home-y <= hm2_5i25.0.gpio.014.in_not

# --- HOME-Z ---
net home-z <= hm2_5i25.0.gpio.015.in_not
---
--
-
Remove "_not" from all those lines and try again.

The result for the home switches was that:
X and Y reversed their search directions (X now searching in + dir, Y in -, Z was in same, +, direction)
none of the switches had any effect although they lit

Owing to this I didn't check the probe.

Reversed homming direction has nothing to do with switches, it is set in the ini file by:
HOME_SEARCH_VELOCITY
HOME_LATCH_VELOCITY
HOME_FINAL_VELOCITY
seting the forst to negative by adding - in front of the numetical value will change direction, or removing it if it is already there.
Might need to add or remove to the other above values, also.

tommylight wrote:

Reversed homming direction has nothing to do with switches, it is set in the ini file by:

Tommy, I didn't touch the .ini file, but I edited the .hal file again to confirm the behavior I saw.

This is the excerpt from the .hal file, with trailing #comments--which do not affect LinuxCNC's abiity to read the file:
home-[xyz] settings: copied from .hal and verified
QUOTE
# --- HOME-X ---
net home-x     <=  hm2_5i25.0.gpio.013.in_not #X searches -/left
#net home-x     <=  hm2_5i25.0.gpio.013.in #X searches +/right

# --- HOME-Y ---
net home-y     <=  hm2_5i25.0.gpio.014.in_not #Y searches +/away
#net home-y     <=  hm2_5i25.0.gpio.014.in #Y searches -/toward

# --- HOME-Z ---
net home-z     <=  hm2_5i25.0.gpio.015.in_not #Z searches -/up [CORRECTED]
#net home-z     <=  hm2_5i25.0.gpio.015.in #Z searches +/down
ENDQUOTE

This setting in .hal really does change the homing-search direction.

The problem is that the signals from the home-switches are not recognized by LinuxCNC.

Did you verify that the home switches work by using halshow?

in axis: Machine --> Show Hal Configurattion --> Watch --> Signals --> home-x

and then verify that home-x is true (yellow) when the X home switch
is activated and false (dark red) when not activated
(then repeat for the other axis)

If you get no response, this is likely a wiring or interface error of some kind.
If the response is backwards (yellow when not activated, red when activated)
you will need add or remove the .not from GPIO pin name.

The input inversion will change the homing direction because the polarity
will determine if LinuxCNC sees the switch as not activated or activated
which will either cause a motion in the SEARCH direction (looking for the
home switch) or LATCH direction (backing off the activated home switch)