Advanced Search

I got the ENA setup and working properly. Enabling the machine turns on the drives as expected. Now I just have to work on handling the ALM signal when there is a problem reported. What is the current way of handling this? I think I need to tie in fault-in from the motion module.

Hello again!
I finally received the drawings of the electrical, hydraulic and air circuits. Now I will count the exact number of I/Os. Then I will make a list with the exact signal of each I and O needs. It would be nice, if someone could correct me on my choice of mesa cards.

Here they are (lower resolution), maybe I can help someone with this:
 

Already replied on the other topic.

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

  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

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.