Hi,
I installed EasyProbe exactly following video and instructions.However, I can’t use the midpoint and distance probing functions because I keep getting an error related to M130.LinuxCNC shows “Unknown M code used: M130” when I press the X0 / Y0 / Z0 / R0 buttons or when an abort occurs.I already set the M130 file as executable , but the error still happens.Could you please clarify:
– where exactly the M130 file must be located macros, nc_files, or another folder?
– and whether M130 must be a file or a shell script?I’m using LinuxCNC 2.9.4.

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.

Hi Rod,
thanks a lot for your comments.
For me and my profile of usage, the homing is not usefull because of several reasons:
- I use a centering microscope or the touch-off by the miller to zero the axes in Axis
- My workpieces typically fit into a "space" of 50 x 50 x 10 mm. Homing would leed to a lot of additional movements and would create much more wear and tear on the gearboxes, leadscrews and dovetails.
- I would doubt, that my limit end switches have a repeatablility of +.-1 micron. So the home position would not be very precise.
- And finally the esthetic aspect: if my mill would sit at the end positions when it is not used, it would look odd to me
Best regards
Hartwig

der plotter ist cool

der unterschied ist, das im test gui nur gesagt wird das der pulsgenerator (FPGA->Stepdir) eine bestimmte frequesnz erzeugen soll, also die steps (velocity mode).

in linuxcnc hängt der pid-regler drin, der schaut wieviele steps schon erzeugt wurden und passt entsprechend die velocity/frequenz im step-generator an.

Bin leider auch kein mathematiker, aber ich denke
wenn LinuxCNC nun auf 0.01mm genau fahren will, der stepper aber nur 1/12 mm genau kann, dann spingt der PID regler als am ziel vorbei.

Es ist gar nicht so einfach Bilder hier hochzuladen, ich habe es jedenfalls nicht geschafft (waren auh nicht zu gross).
Ich habe die Bilder unter github.com/freylax/riocfg/img eingestellt. Es ist ein alter selbstbau Plotter aus DDR Zeiten den ich als CNC Testobjekt verwenden moechte bevor ich mich an die richtige Maschine bei meinem Freund ranwage.

Raspberry PI5, Olimex ICE40 EVB, Adapter und CNC Breakout Board, Stepper Driver.

Ich kann die Mikrosteps einstellen, allerdings scheint das nicht ganz zum Erfolg zu fuehren. In der rio-test app kann ich den 
Motor schrittweise steuern, das klappt. Aber wenn ich in der axis app Manuell zb 5mm anfahre und auch eine geringe Geschwindigkeit einstelle, dann vibriert der Motor nur und es werden  keine richtigen Schritte daraus. Was mach rio-test anders?
Ich studiere auch den Code um das zu verstehen.

liebe Gruesse,
Robert 

HOME with index should be available, nothing about homing should have changed other than the homing movements being now jerk controlled, but I'll double check on my end, you still have to enable

HOME_USE_INDEX = YES

In the ini file for each joint you want to home using index

Edit:

Yeah, triple checked, homing index should work as expected, just has to be set proper, mind that machine movements will be effected by the s-curve even while homing, if you do not want that, you can link all joint.N.homing pins with or2, then to a mux2, and then to the ini.traj_planner_type pin in hal, so when you home you can have planner 0, otherwise planner 1, I originally had an INI flag to disable s-curve while homing, if you guys think is necessary I'll add it back, but I ended up not liking the machine shaking up only when homing, I want it always to be smooth now, I'd rather readjust the homing vel to compensate for the longer but smoother movements.

is homing at joint.0.index_enable avaible?

I can not home my profibus sstuff it looks like index_enable is still down .. 

I have had to uuse the NO_FORCE_HOMING = 1

thanks

@Dave3891

it's in the master branch now: github.com/multigcs/riocore/blob/main/doc/MODBUS.md

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:
  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

I wonder if TSN works. At least without modifications.
Do you have any real-world experience with that?

In the  flyer I read that while the master can be unaffected, at some point the slave needs to support TSN either directly or via a TSN switch in front of it.

The i210 is an excellent choice, albeit a bit old now. I have good luck with the i217 and also with the latest dirt-cheap i226-v adapters. Older adapters use the igb driver, newer use the igc driver, with some different options and defaults.

Thanks a lot for your reply. I ran the latency test at the beginning of this project. At first I had some issues because of the drivers (realtek 8168), and sometimes it would stop with a “Finished reading” error. After a bit of trial and error I changed the drivers as suggested in some threads, and now it runs fine: no packet loss, and both average and maximum latency stay below 70 µs, so I think I’m good.

JT wrote:

Also note that there is no /etc/apt/sources.list.d/debian.sources in my Debian 13 after doing a full upgrade.

JT

yes the old format is retained on a full upgrade from Bookworm but it will nag you on an apt update to run sudo apt modernize-sources if I got the spelling right...

Debian says the old format will be removed in time.

Hartwig wrote:

Dear members,

my Leinen FM1 is now running with LinuxCNC on all 4 axes.
I have built a small cubicle containing the required components. I have not modified the original setup at all. The CNC cubicle can be activated by a simple changeover of the original plugs coming from the mill (HONDA MR 50 pin and 20 pin plugs and the 4 Heidenhain plugs) from the original control panel to the CNC cubicle.
The relevant hardware I'm using is
- MESA 7i97T
- 1 Heidenhain EXE with 3 channels from a MAHO mill (1 my resolution)
- 1 Heidenhain EXE 610 for the rotary axis (0,001° resolution)
- 2 Mattke two channel Tach DC motor controller MTRG 25/2D
- 1 Mattke MTRM 061/5 Tach DC motor controller for the spindle motor
- 1 cycloidal transfer 60VAC for the spindle
- 1 cycloidal transformer 2 x 22VAC for the axes motors
- 1 5VDC and 1 12VDC power supply
- 1 All-In-One PC
Only the MESA card is new. All the other other equipment is bought second hand and mostly about 40 years old. But it works !
To be sincere, without help I would not have been able to configure LinuxCNC.on my own. A very kind and knowledgeable member of this forum did this work for me. Thanks a lot to him.
If anybody needs the INI and the HAL files, I would be happy to send a copy.
The following functions are implemented::
- x-, y-, z- and rotary-axis control
- end switches for the 3 linear axes
I have and I need no homing function.
The spindle speed is controlled outside LinuxCNC with an old Beckmann 10-turn potentiometer. I know them from the 80th of the last century, using them in the university labs.
Furthermore I have installed an original old style Waldmann machine light
Best regards
Hartwig

You should be able to use your existing end switches as home switches and limit switches. It is so much easier if set up completely. Just make sure you have a home_offset to move the axis away from the limit switch (even 0.5mm is enough, sometimes less). Otherwise the limit switch will trigger as homing completes.