Failed stepgen outputs are most likely due to a problem with one of the
the output driver chips. For stepgens 0..3 these chips are a 74ACT541 (for the + outputs)
and a 74ACT540 (for the - outputs)

Does the  step3- output work? If not, it may be a deeper hardware issue
(PCB or soldering issues) These kinds of issues are rare.

Bad step/dir outputs caused by driver chip failure  are not rare but usually
traceable to accidental contact  of the step/dir pins to a voltage outside
the 0 to 5V range perhaps during initial wiring.

Probably a lost cause, but just in case ...
Turned on my CNC and the Z axis did not move.
After swapping out the stepper driver found that the stepgen no3 on the mesa was not outputting any step pulses as shown on my oscilloscope. Direction pin was changing as expected.
Changed it to number 4 and all is ok.

Assume just a hardware / output driver issue.
Is this a common fault on these cards. It is at least 5 years old. It lives in a pretty protected environment.

At this point I only need 4 stepper outputs so can live with it as is.

I just ordered two Mesa 7I76EUs, two Mesa THCAD2s, two Hp elitedesk 800 G1 USDT with i5 2.9ghz 16gb ram 512gb ssd, and two cat 8 ethernet cables. So I really want to keep trying until I have a working system. This is my third attempt at trying to achieve a working plasma table and so far I have only got to use my machine for five minutes at a time at most. I really appreciate the amazing support from you all

How many of those 30 machines run Bookworm or Trixie? I used to think like you.  In my view its mandatory today and I get much better latency results on the same hardware I used with stock kernels back when  we used to have to compile the PREEMPT_RT kernel to run Mesa cards. One day you will strike a PC which will cause you to rethink your views the hard way just like I have.

Ooops, I saw the pings but missed the disconnect window. So to my mind, the only things that could cause this is faulty hardware, crappy network cable or a flakey power supply on the Mesa card. The Mesa power can be eliminated at this point. Time to follow PCW's advice to isolate that piece of hardware is causing it.

But the ping times are also too slow.

None of my suggestions are out of scope  of a  mesa card and earlier screen dumps showed no isolcpus was set so a lot of work to do there 

Here is a checklist of the key optimizations required for a `PREEMPT_RT` real-time kernel on Debian, specifically tailored for network performance on interface `eno1`.

### 1. BIOS/UEFI & Hardware Level

* Disable **Intel SpeedStep / AMD Cool'n'Quiet**
* Disable **Global C-States** (C1E, C3, C6, etc.)
* Disable **Intel Turbo Boost / AMD Core Performance Boost**
* Disable **Hyper-Threading (SMT)** *(highly recommended for strict determinism)*
* Disable **System Management Interrupts (SMIs)** / Advanced Power Management

### 2. Boot Command Line (`grub-customizer`)
lastcore = the last CPU you have. say its 3 on a 4 core CPU but yours may be different
* Add `isolcpus=3` to isolate specific CPU cores for RT tasks
* Add `nohz_full=3` to enable full dynticks on isolated cores
* Add `rcu_nocbs=3` to move RCU callbacks off isolated cores
* Add `processor.max_cstate=0` and `intel_idle.max_cstate=0`
* Add `pcie_aspm=off` (disables PCIe Active State Power Management)
* Add `skew_tick=1`

### 3. Network Interface (`eno1`) Optimizations

* Disable **Adaptive Interrupt Moderation** (`ethtool -C eno1 adaptive-rx off adaptive-tx off`)
* Set static interrupt coalescing to 0 (`ethtool -C eno1 rx-usecs 0 tx-usecs 0`)
* Disable offloads causing latency spikes:
* Generic Receive Offload (`ethtool -K eno1 gro off`)
* Large Receive Offload (`ethtool -K eno1 lro off`)
* TCP Segmentation Offload (`ethtool -K eno1 tso off`)
* Bind `eno1` queues to the single dedicated, isolated CPU core

### 4. Operating System & IRQ Tuning

* Increase the real-time priority of the `eno1` threaded IRQ handlers (using `chrt`)
* Set the `eno1` IRQ affinity mask to use isolated core
* Set the system power management policy to performance (`cpupower frequency-set -g performance`)
* Disable the `irqbalance` daemon (`systemctl disable irqbalance`)

 

Do you have anther PC or another Mesa card to see which device is dropping the connection?

These are my HAL and INI files    
I can ping 10.10.10.10 but every time it goes over 0.500 ms it throws the error 
These are my W2 and W3 jumpers
This is power to the board 
This is the power supply to the board 
And I also have a Meanwell MDR 60 24 for testing its just a really old one. 

I'm a bit confused, Initiially an IP address was not set but in later ip a dumps it was correctly set for a Mesa board at 10.10.10.10, It was never made clear after that if the Mesa board was pingable. I assumed it was. 
I would like to see the Hal and ini files to confirm the MESA IP address.
Can you ping the card?

Also from photos of the board, it would be great if PCW could confirm that the links are set for the 10.10.10.10 address is set correctly. W2 down, W3 Up

Also, need to check out the 5 volt power supply to the board which is usually powered form field power which seems to be the case. But are the links set correctly to send 5 volts to the logic side? Can PCW confirm?

The final thing to check on physical wiring, What is the field power voltage? What is the actual power supply? What is the power supply current available? There have been numerous instances where borderline power supplies cause network failure with Mesa cards. This must be ruled out. If need be get a good industrial power supply such as Meanwell MDR-60-24.

It might be worth setting the IP address back to automatic (DHCP) and connecting the PC to your normal network using this NIC card to confirm networking is working.

I mentioned it before but be sure to set the IP address and coalescing as shown in man hm2_eth (use your IP address and 
linuxcnc.org/docs/stable/html/man/man9/h...h%20static%20address

So if all of that checks out and a new network cable does not fix things AND the network is connecting but drops out every 45 seconds or gets error finishing read., there will likely be one of several power saving settings kicking in periodically.





 

So this is the current setup 
And I have this HP PC here I can use for testing. 

Yes, this does not seem to be a latency issue but a connection issue.
Not really sure what the cause is. I have a 800 G1 here running
LinuxCNC without any Ethernet connection issues so I don't know.

Is is possible to try another PC to try and isolate the issue?



 

There are a lot more tuning settings required but lets get the main one
Can you type: echo $(nproc)
and then back in grub customizer add isolcpus=X where X = $(nproc)-1 from what is printed from the line above.
Then reboot.