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.

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.

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)

Earlier I wrote:

...I truly believe that I have .hal and .ini files which match the wiring.

After sleeping on it, I came at the problem with fresh eyes and found that I--STILL--had confused P3 function numbers with DB25 pin numbers. (ohforpityssake)

One thing I learned was that, despite all my fears about and preparations to guard against powering up with signals on the wrong pins, I did it anyway--AND nothing smoked.

I started ironing them out, one-by-one by looking, first, at the output of:
mesaflash --readhmid --device 5i15
again, to see the matchup between DB25 pin numbers (col. 1) and GPIO functions (col. 2). I immediately noticed, this time around, that I'd used gpio15 where I wanted db25pin15.  (It's difficult--but not always impossible--to save someone who keeps shooting themselves...)

Another thing I'd done was to add # Trailing Comments to lines in the .ini--to help my future self understand what I'd done.  LinuxCNC didn't complain--in some places, but crashed-on-start with ambiguous errors on others.  Best to give #comments their own lines.

PCW wrote:

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

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

Peter, I actually had done this, and that's where I woke up to the fact that my .hal file was still incorrect.

I put a bunch of Signals into the Watch tab, and I saw CRAZY things lighting up where I expected other things. That's what tipped me off to go back to verifying the mesaflash --readhmid/.pin file.

I've got home switches recognized now. Finally. Just need spindle-enable and probe-in and I'll be back-to-normal.

Spindle-enable is sorted now too. M3 turns spindle on and sets speed.

Halshow indicates that the two probe signals (probe-in and probe-in-not) are lit Yellow/Brown when not contacted and toggle to Brown/Yellow when contact is made.

So the probe-in "should" work too, but I've yet to find my handy-dandy utility routines folder that I used almost daily a year and a half ago.

Editing later: it was. In fact, everything worked, finally: axes, spindle, home switches, and probe.

I was so giddy from the fact that I immediately tried to run the model I was working on in March 2021, when the old controller machine's motherboard expired, and I began my "two-to-three-week" quest to set up a more future-proof replacement. Cue the Alice-in-Wonderland music...  (I started to run the G-code and shortly discovered that the new setup with the Mesa 6i25 is losing steps too. ...but that's for another post.)

Thank you again, all, for all the information you sent my way. I certainly couldn't have gotten this far without you.