Advanced Search

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.

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!

Already replied on the other topic.

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.

Hey Tommylight — thanks for the reply just to close the loop on that earlier issue

I did get past the firmware/install side in the end. After a few messy attempts, I wiped everything and went with a fresh Debian 12 install, then installed LinuxCNC separately (rather than relying on bundled firmware paths). That got the 7i76EU fully detected, firmware loaded cleanly, and all stepgens running perfectly.

Where I’m stuck now is further downstream: the limit/prox inputs. The board, smart-serial, and motion side are all behaving exactly as expected, but the GPIO inputs appear frozen and don’t update in HAL even when shorted directly to GND.

So the original “missing firmware” problem is solved — this is a new issue on the input side, which is what I’m trying to chase down now.

I created a fresh topic on it to try and nail it down as its hopefully my final port of call for a while.

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:

  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

  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 (

  SERVO_PERIOD = 1000000

  )

• halcmd

  shows all inputs

  input-00

  through

  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

  input-XX

  and

  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

  mesaflash --sserial

• Inputs monitored live with

  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)

• mesa_debug.txt

• mesa_hal_config.txt

• mesa_ini_config.txt

Mesa 7i76EU comes with firmware loaded and ready to run, just use the included PncConf or MesaCT wizards to make a configuration for your machine.

Hi all,

I’m setting up a Mesa 7i76E (Ethernet) with a single 7i76 smart-serial I/O board on Debian 12 / LinuxCNC 2.9 and appear to be stuck due to missing FPGA firmware.

LinuxCNC installs and runs fine, PnCconf completes, and the board is reachable over Ethernet, but field outputs never work:HAL signals link to hm2_7i76e.0.7i76.0.output-00halcmd show pin | grep 7i76 returns nothingdmesg shows no smart-serial / 7i76 detectedEstop / stepgens work, but no field I/O activity/lib/firmware/mesa does not exist, and I can’t install linuxcnc-firmware-mesa because the machine is offline and buildbot appears to be down.

I’m looking for a known-good firmware file for this setup (likely 7i76e_7i76x1.bit), or a working mirror / source for Mesa firmware on LinuxCNC 2.9.

Any pointers appreciated — happy to provide logs if needed.

 Thanks!

Tim.

Hey guys!

Hopefully I'm not banging a beaten drum here. 

I am on the very cusp of finishing my build with the MESA 7i76eu, only to find, like other by the sounds of it, that the boards do not come flashed with firmware. Can someone please help me out? this was discovered when navigating to linuxcnc_2.9.3-amd64.hybrid\firmware to find nothing in the folder. 

Please let me know any further information required, and any assistance would be greatly appreciated!

Happy new years!

Tim.

I just updated the 7i92t firmware to include all the latest firmware from Mesa. Select the 7i92t and then Downloads > Firmware to get the latest.

Edit: I also updated the 5i25t, 7i76eu, 7i95t, 7i96s and 7i97t firmware.

JT

Das hier wäre meine Version mit dem geklautem Code aus dem Forum:



########################################
# 7i73/7i75 hal connections for the MPG#
# von Norbert Schechner kopiert #
########################################

# Here the mpg counts are connected
net jog-wheel-counts joint.0.jog-counts <= hm2_7i796s.0.7i73.0.0.enc0.count
net jog-wheel-counts joint.1.jog-counts
net jog-wheel-counts joint.2.jog-counts
net jog-wheel-counts axis.x.jog-counts
net jog-wheel-counts axis.y.jog-counts
net jog-wheel-counts axis.z.jog-counts

# we need a mux component to select the step increments
loadrt mux2 names=jog-mode-sel
addf jog-mode-sel servo-thread

net jog-scale-out jog-mode-sel.in0 <= gmoccapy.jog.jog-increment
# my default on continious jogging is 0,05 mm / count
setp jog-mode-sel.in1 0.050

# need to get the jog mode
# Mode 0 all steps will be done, Mode 1 joint will stop as soon as you stop spinning the mpg
net jog-vel-mode gmoccapy.jog.jog-inc-0 <= jog-mode-sel.sel <= hm2_7i796s.0.gpio.041.in
net jog-vel-mode joint.0.jog-vel-mode
net jog-vel-mode joint.1.jog-vel-mode
net jog-vel-mode joint.2.jog-vel-mode
net jog-vel-mode axis.x.jog-vel-mode
net jog-vel-mode axis.y.jog-vel-mode
net jog-vel-mode axis.z.jog-vel-mode

# already connected cont_joging on jog vel mode selection
# here we connect the physical buttons to select the jog increment
# net jog_cont gmoccapy.jog.jog-inc-0 <= hm2_7i76e.0.7i73.0.1.input-07
net jog_1000 gmoccapy.jog.jog-inc-1 <= hm2_7i796s.0.gpio.042.in
net jog_0100 gmoccapy.jog.jog-inc-2 <= hm2_7i796s.0.gpio.044.in
net jog_0010 gmoccapy.jog.jog-inc-3 <= hm2_7i796s.0.gpio.046.in
# net jog_0001 gmoccapy.jog.jog-inc-4 <= hm2_7i796s.0.gpio.041.in

# This is to change between jog modes 0 and 1
net jog_scale-out joint.0.jog-scale <= jog-mode-sel.out
net jog_scale-out joint.1.jog-scale
net jog_scale-out joint.2.jog-scale
net jog_scale-out axis.x.jog-scale
net jog_scale-out axis.y.jog-scale
net jog_scale-out axis.z.jog-scale

# this is to enable the selected joint / axis
net jog-x-enable joint.0.jog-enable <= hm2_7i796s.0.gpio.034.in
net jog-x-enable axis.x.jog-enable
net jog-y-enable joint.1.jog-enable <= hm2_7i796s.0.gpio.036.in
net jog-y-enable axis.y.jog-enable
net jog-z-enable joint.2.jog-enable <= hm2_7i796s.0.gpio.038.in
net jog-z-enable axis.z.jog-enable

# Buttons START PAUSE STOP mit Gmoccapy

net Button_Start gmoccapy.h-button.button-2 <= hm2_7i796s.0.gpio.035.in
net Button_Pause gmoccapy.h-button.button-4 <= hm2_7i796s.0.gpio.037.in
net Button_Stop gmoccapy.h-button.button-3 <= hm2_7i796s.0.gpio.039.in

See also Mesa 7i96S and 7i76E and 7i95 and many other combos, but for a start 7i96S is the easiest to wire and quite cheap.

Itś all good now. Thanks

1. USB-LAN adapters should not be used on production machines, USB has inherent latency issues
2. from your explanation it seems like interference issues, so is the machine and PC properly grounded?

Hello,
I get the error mentioned when a milling operation has run to completion or when I stop an operation with the stop button.
I have attached some pictures. My Mesa card is connected to a USB-LAN adapter.
Thank you very much for your help.

I just switched MESA connection from the USB-LAN adapter to the intern LAN adapter and the error is gone... the reason i didn´t take the intern LAN was my post monthś ago forum.linuxcnc.org/9-installing-linuxcnc...to-connect-to-github but now it also works.