Advanced Search

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.

They are actually subroutine macros, the GUI is just generating the parameters for it based on the inputs. After that they are just called one after each other with a subroutine call.

Thanks, I understand it now. I have 1 more question.

Today I'm connecting the encoders and limit switches, but I have a question about the drive enables.

My machine has relays for the drive enables. Is it a good choice to keep those? 'Cause the 7i97T has optocoupled drive enables, but I don't know if it's a problem for the control or the board. I have to verify if the coil uses less than 50mA or buy new ones.

But is it good practice to have an extra layer of protection, or is it better to operate them directly?

Or not. it still faults randomly on xyz. we did not find a fix, but we did find the "cause" and created a patch plan which I will do in the morning.

Basically, if you watch PLL error, you see occasional spikes. Spikes that hit a threshold of about 100000 (this number is relative to the refclocksynccycles) trigger a DC phased even dropping it to 0. these only last one frame. They do not seem to ordinarily cause an issue. Once in a while (could be a minute, could be an hour) we get a joint error on one or all of the xyz axes which are omron, but not the A which is leadshine. When you look at this error in the scope, it comes a few frames after a pll error spike, and it EITHER sends the position feedback to 32 bit int rollover, OR to 0. Hence, joint error. I did notice that SOMETIMES we get a bad position value that does NOT roll over or go to 0, and this then gets corrected the next frame, and there is no joint error.

We can induce more events by changing refclocksynccycles form -1 to 300, and a value of 1 totally prevents anything from starting for more than a few seconds.

Why this occurs seems to be about timing, or maybe interference or noise corrupting values. hard to say still. Why is it seeming to be only the omrons? Other people have reported joint errors as well, perhaps we need to compare notes.

ANYHOW... the solution is just to filter the "actual position" feedback and remove any invalid frames. They are pretty easy to spot, if you are at 8000000 counts, and suddenly it goes to 0, or 2.1 billion, we just replace that value with the previous. Since we are in CSP mode, this doesn't have any effect.

The filter needs to be a bit smart, and check back 3-4 frames I think to detect the trend of motion. I shall figure that out in the morning and once it works, post the hal file here so others with this issue can use it.

This should also at the same time eliminate idle random soft limit errors, which happen for the same reason. (it wont really help with soft limit errors when right on the limit of course)

Thanks for all the help in the various threads and discords.