7i76EU GPIO inputs completely frozen - not updating in real-time

Summary (TL;DR)I have a Mesa 7i76EU on LinuxCNC where everything works except the GPIO inputs.
The board is fully detected, stepgens and smart-serial work perfectly, but all 32 inputs are frozen and never change state — even when shorted directly to GND.System

• Mesa 7i76EU (Ethernet, 192.168.1.121)
• Debian 12 (Bookworm)
• LinuxCNC 2.9.8
• RT kernel:
  Code:

  6.12.57+deb13-rt-amd64
• WECON VD2 servos (X/Y/Z)
• NPN 3-wire proximity switches (brown +24V, blue GND, black signal)

What Works (100% solid)

• Mesa discovered every startup
  Code:

  hm2_eth: discovered 7I76EU
• Board pings reliably
• Smart-serial working (FW v43)
• All stepgens work flawlessly (axes move correctly)
• E-stop and brake control functional
• No timing issues (
  Code:

  SERVO_PERIOD = 1000000
  )
• Code:

  halcmd
  shows all inputs
  Code:

  input-00
  through
  Code:

  input-31
• No errors in logs, dmesg, or startup

The Actual ProblemALL GPIO inputs are frozen.Input values never change in HAL, even when:

• Triggering physical limit switches (LEDs light correctly)
• Shorting input pins directly to GND
• Switching between
  Code:

  input-XX
  and
  Code:

  input-XX-not
• Power cycling the Mesa
• Restarting LinuxCNC

This applies to all 32 inputs, not just the ones in use.What I’ve Already Ruled Out

• Wiring verified multiple times
• Bypassed switches entirely (direct GND test)
• Tested raw vs inverted inputs
• Verified HAL nets (no duplicates or syntax issues)
• Confirmed good network latency
• Smart-serial confirmed via
  Code:

  mesaflash --sserial
• Inputs monitored live with
  Code:

  watch halcmd show pin
  — completely static

Example output (never changes):
  The TRUE/FALSE pattern looks random and does not correlate to real input state.Why This Feels Strange

• Stepgens work → Mesa comms are good
• Smart-serial works → daughter card is talking
• But GPIO inputs behave as if they’re not being refreshed at all

Almost feels like the input register isn’t being updated or latched.Questions

• Is there any known 7i76EU case where outputs work but inputs don’t update?
• Anything firmware-related that can cause frozen inputs?
• Any HAL / driver parameter that explicitly enables input scanning?
• Worth reflashing the Mesa firmware?

I have PNP switches on order, but since even direct GND shorting doesn’t change inputs, I don’t think this is a sensor-type issue.Attachments (if needed)

• Code:

  mesa_debug.txt
• Code:

  mesa_hal_config.txt
• Code:

  mesa_ini_config.txt

7I76EU inputs are sinking inputs, that is, they detect a positive voltage
relative to field power ground. They will read "low" in hal until there are at
~60% of field voltage (~+14.4V at +24V field voltage)

If you use proximity switches, they should be PNP (sourcing) type.
NPN type switches would need a pullup (say 2.2K 1/2W) resistor to
+24V to work.

Thank you so much for the response, I have been going through a trial and a half with this install :') I bought some 2.2k 1/2W resistors just for this project, and have been battling to get a result

In halshow, none of the inputs change state, even the estop. But watchpin in the terminal shows clearly that estop, probe and for whatever reason, Z max (Home) limit switch change state even though it currently doesn't have a pullup. I only get a reaction from Z max when sensor is active.

I currently have a pullup on my X min, but can't get any reaction out of it no matter what state the proximity switch is in (on/off or jumper to GND) when using watchpin.

Just for reference as to wiring, I have all +wires > COM+> +WAGO fed by +FIELD, same setup for GND. Then individually connected sensor wires to MESA inputs. Pretty obvious, but just in case, I figured I best note it.

Also, I figured I will include multi readings in both states for all inputs with sensors on and off. X max excluding as I have found it to be dead. I will be replacing all of these anyway with PNP when they arrive. But was hoping to atleast get it running.

Readings are as follows:

X max DEAD
X min 3.9 off, 7.8 on
Y max 14.7 off, 18.4 on
Y min 12.3 off, 8.3 on
Z max 8.0 off, 14.9 on
Z min 12.4 off, 9.0 on

Readings might be telling or maybe not?

My GUI is also massive and a PITA, so I have mostly been doing my stuff through SSH. No matter what commands I send, I cant get the GUI to scale properly that's everything on the screen though, for whatever reason, my mini pc with Debian 12 cant seem to recognize the screen through HDMI. Any suggestions there would be absolutely amazing!

Had the same issue, double check your wiring of the orange block. If it's wrong it won't power up and you'll get the issue your are seeing.

Those voltage values indicate a wiring issue.

With NPN sensors, one state should be very close to GND  (<1V)
How high the voltage is in the other state depends on the pullup resistance
which may be infinite (no pullup) or some intermediate voltage depending on the
pullup resistance (some NPN proximity switches have built in weak pullups)

Because the low levels are not close to GND, it sounds like the the NPN proximity
switch common is not connected to the field power common.

 

I rewired my psu input from psu > wagos > mesa input > field to psu > mesa > field > wagos but no change sadly.

Oddly enough, I can jump between gnd and input pins 13 and 12 and get a change of state using showpin, but nothing down to pin 8. And thats without a resistor on any input except for 8.

If you wish to test the inputs, disconnect all external devices from the inputs
and test each input by connecting it to field power (+24V in your case)
Note the touching the screw on the connector is not reliable unless the screw is tight

If the NPN limit switch outputs are not very close to ground in one state,
you still have a wiring error.