Advanced Search

May be an introduced PathPilot bug since their hostmot2 driver has been
changed from LinuxCNC's version and Tormach doesn't use any sserial devices.

When the error happens, do you get a red LED illuminated on the 7I92?
 

I don't use that workflow, but the button is also disabled in both my personal config that uses a tool setter and in the probing sim config. There may also be a separate issue even if the “Probe Height of Current Tool” button is enabled. The current BLOCK HT calculation uses the formula origin = float(INFO.INI.find("AXIS_Z", "MIN_LIMIT")) + value. Using the Z minimum limit doesn't really work or make any sense to begin with for me, but even if the machine was setup for that, the formula would only make sense if the probed value was a positive height measured upward from the Z minimum limit. 

So doesn't directly answer why the button is disabled, but I can confirm it's not unique to your config and the routine in general is very confusing. Hopefully one of the developers who worked on these routines can clarify why the current BLOCK HT calculation does not produce the expected result and explain what setup or value the routine was originally designed around along with why the “Probe Height of Current Tool” button is disabled. 

Post this back to the thread — it's a genuinely useful negative result that narrows things down for PCW. Something like:

Ran the stress test as requested:

60000 packets transmitted, 60000 received, 0% packet loss, time 59998ms
rtt min/avg/max/mdev = 0.105/0.112/0.233/0.011 ms

Clean — no packet loss, tight timing. So it doesn't look like an Ethernet dropout issue. I also removed enable_raw from the config string per tommylight's question, but the same EAGAIN/"Ignoring soft error during init" failure persists.
For what it's worth: I've now reproduced this identical failure with two different bitfiles (7i92_7i76x1D.bit on P2, and 7i92_7i76x2D.bit on P1), on two different SSerial channel instances (.0.0 and .0.2). Both boards' modes print correctly (io_spin/io_ana_spin/io_enc_ana_spin_ff) before the same failure. This is on PathPilot 2.14.4 (LinuxCNC 2.8.0~pre1), if that Tormach fork detail matters.

That last paragraph is worth including since it's new information since your original post — the "reproduced across two different bitfiles/channels" detail might help PCW recognize this as something specific to the PathPilot fork rather than a generic hostmot2/hardware issue.

Yes, it's typically used for debugging.

It allows low level register access to FPGA registers.

Hi NWE, thanks for commenting. Can you share more details on what are you looking for to use for the retrofit ?

Hi RodW, many thanks for answering. Seems you are telling me to use an EtherCAT Beckhoff module for the THC ?

Should I be using only Beckhoff modules or can I go with any other producer, there is a lot of stuff out there. I was evaluating Triomotion modules for motion controll, IO and Analog IO. The Flexslice series (www.triomotion.com/public/products/flexsliceExpansion.php). Seems they should work with LinuxCNC.

Hello Tommylight, many thanks for answering. So if I understand well I should not bother with EtherCAT at all for this. I was looking at the Mesa board and seems reasonable to me.

Right now I have a doubt on the encoders signal feedback. I see the board has only one input for the encoder feedback. But I have 3 drives, so should I leave the encoders
signals from the drive to linuxcnc out ? Or there is a way to connect all 3 encoders to the board ?

Also has LinuxCNC some settings to make the preheat , and open the various gasses vales at ceartain time already in or should I be doing this from zero up ?

Is the "enable_raw" a valid load parameter?

hm2_eth: rtapi_app_main: Resource temporarily unavailable (-11)

Suggests you have lost Ethernet communications during startup

Could be a network setup issue or perhaps marginal  5V power
that drops out with increased power drain at startup with the 7I76.

What does:

sudo chrt 99 ping -i .001 -c 60000 -q 10.10.10.10

report?    ( It should run for 1 minute then print timing statistics )

( replace 10.10.10.10 with 192.168.1.121 if your 7I92 is jumpered that way )


 

ronthomp wrote:

`DRIVER_PARAMS`: `board_ip=10.10.10.10 config="num_encoders=1 num_pwmgens=2 num_3pwmgens=0 num_stepgens=5 enable_raw"`

Just a stab in the dark, but, delete "enable_raw" as that is something i have never seen on Mesa parameters, but i am also pretty sure it might just be valid.

Hi all,
I'm using Claude ai. And it suggested and composed this message, because I am no coder.
...
Good call, and yes — I can't actually post to the forum myself (no login, no ability to submit forms there), but I can draft a clear, complete post for you to paste in. Here's one:

---

**Subject: 7i92 + 7i76 on P2 — "Ignoring soft error during init" then "board fails HM2 registration" (EAGAIN -11)**


Working on a non-Tormach retrofit using PathPilot 2.14.4 (LinuxCNC 2.8.0~pre1) with a 7i92 and a single 7i76. Bitfile is `7i92_7i76x1D.bit`, confirmed via `mesaflash --readhmid` to match the official `.pin` file exactly (5 stepgens, 1 SSerial module, 1 QCount, all on P2; P1 is unused GPIO).

With the 7i76 cabled to **P1**, everything works fine — boots clean, X/Y/Z stepgens register, GPIO pins behave as expected. No SSerial devices show up (expected, since P1 has no SSerial module in this bitfile).

Per the `.pin` file, the 7i76 needs to be on **P2** to access its real field I/O via SSerial. After (removing the ribbon) moving the ribbon cable to P2 (direct pluging to db25) and confirming proper 24V field power + 5V logic power to the 7i76 (jumper on the 7i92 adjusted to supply 5V to P2 instead of P1 — two LEDs now lit on the 7i76 confirming both supplies are good), I get this on every boot attempt:

```
hm2/hm2_7i92.0: Smart Serial Firmware Version 43
Board hm2_7i92.0.7i76.0.0 Hardware Mode 0 = standard
Board hm2_7i92.0.7i76.0.0 Software Mode 0 = io_spin
Board hm2_7i92.0.7i76.0.0 Software Mode 1 = io_ana_spin
Board hm2_7i92.0.7i76.0.0 Software Mode 2 = io_enc_ana_spin_fv
hm2_eth: Ignoring soft error during init
board fails HM2 registration
hm2_eth: rtapi_app_main: Resource temporarily unavailable (-11)
```

So the board is clearly detected correctly (modes print fine) but registration fails right after with EAGAIN. I've tried:
- Removing `sserial_port_0=` entirely (letting it auto-detect per the hostmot2(9) manpage's note that no config should be needed)
- Explicitly setting `sserial_port_0=0xxxxxxx` (mode 0 for the one channel, rest disabled)
- Full power-cycle of both the PC and the 7i92/7i76 (not just a warm reboot)
- Enabling `debug_module_descriptors=1 debug_modules=1` on the hostmot2 load — descriptors parse fine, same failure point every time

`DRIVER_PARAMS`: `board_ip=10.10.10.10 config="num_encoders=1 num_pwmgens=2 num_3pwmgens=0 num_stepgens=5 enable_raw"`

Any idea what "soft error" is actually being ignored here, or what typically causes a valid-looking SSerial handshake to still fail registration with EAGAIN? Happy to post the full boot log if useful.

Thanks!

---

Feel free to tweak tone/details before posting — and if you want, mention you're happy to run any diagnostic commands PCW or others suggest, since that tends to get faster responses on that forum.
...
Thanks!

VAC*1.41=VDC
VDC/1.41=VAC

Yes, a 160V  bus supply is good for 163V BRUSHED motors, Sorry I mixed you up with the OP (with BRUSHLESS motors)

reboots wrote:

160V seemed reasonable for the 163V rating of my brushed DC servos.
 

Brushed DC servos, yes, that is correct, but not for AC motors:

Look at an oscilloscope trace of 120VAC sine wave. The tops and bottoms of the trace touch +/- 170VDC, you can't create that off 120VDC with an h-bridge.

This will also cause a bridge rectifier+capacitor to produce ~170VDC from 120VAC.

I still remember my first experience with a rectifier, how amazed I was to get about 17VDC when I powered it with 12VAC from a transformer. The 12VAC is the actual power, sort of an average. "Average" is not technically the correct term here, but it is the idea. RMS is the term normally used.

PCW wrote:

A 160V DC bus supply can only provide about 110 VAC to the motor
so you would be limited to about 1/2 the servo motors full speed.

Can you clarify this? I had thought DC servo drives were typically an H-bridge, which would make for +/-160VDC output minus power semiconductor voltage drops. (Bipolar transistors in my Bosch drive, so not negligible.)

160V seemed reasonable for the 163V rating of my brushed DC servos. OP has 210V brushless servos, so their supply requirements are somewhat different.