Advanced Search

I'm very new to this so please pardon the questions.  I recently acquired an INTEL NUC core-i3 with 8GB of ram. This is intended to drive a MESA 7i76e board on a plasma table.  

tldr; I'm primarily curious to know if the latency results I'm getting are going to work (if that's possible to advise).

I've downloaded the latest iso and  went through performance tuning.  I *think* I've done all the things.  It's sometimes hard to follow all the different threads on tuning.

1) Turned off things in BIOS (hyper threading, power management etc.). This left me with two CPUs
2) Grub configured (including isolcpus)
3) CPU governor set to performance
4) IRQ coalescing disabled (intel NIC)
5) CPU core isolated for LinuxCNC (cpu 1) (I am not sure how to confirm this is actually working as intended)
6) Ethernet IRQ pinned to isolated CPU (cpu 1)

The latency histogram as a result looks like this (6 glxgears & running YT videos):
 

~60 us of max latency.   Is this worth continuing to try to use or should I be looking at a better computer?  Any advice appreciated.

I have not hooked it up to the machine yet to try it.  Hope to be attempting that in coming weeks.  Thought I'd post this to see if I need a different computer first.

- Dave

 

Drives usually have only optocouplers on the inputs, so chances are low for it to short, higher chances of loosing sensitivity (light output as inside the is an LED and a photodiode).
Much higher chances of interference from the spindle and/or VFD that caused a spike, might even be moisture messing things up.

Also another thing, is that I have changed the stepper driver to a new one as I thought initially that might be the problem.

*possible* that the original is faulty and took down the output. Not prepared to test it on another channel though (:

Firstly made a minor mistake on the numbering i.e. 3rd stepgen therefore stepgen.2

This is a small cnc in my home so pretty clean environment using DM556 drivers.
Scoped it with the driver disconnected and hooked between gnd (first pin) and step+.
Figured that since the dir pin toggled when I jogged the Z up and down, that all programming was connect.
Scope looked fine on stepgen.3 and Z now works on that channel.

No, not a common fault at all, i am sure i have over 80 Mesa boards (more probably) and none of them ever failed, and they are mostly on industrial machines, and all are in use daily, some are never switched off, for over 10 years. And most are on plasma machines, by far the worst machines for EMI/interference.
What machine is yours?
Did you disconnect the stepper drive when checking with scope?

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.

Again, thank you, but again, i never ever used isolcpus in my life, yet i have over 30 machines running LinuxCNC and Mesa hardware happily, every day, on mostly industrial machines, for over 10 years.
Still, i understand that sometimes isolcpus and some other tuning can help.
P.S. that 30 above does not include over 15 PC's and laptops i own, all with LinuxCNC and used on machines with Mesa boards, and therein lies my dilemma, i have plenty of laptops that run LinuxCNC out of the box, but i can not advise on getting the same laptops as i had two of the same make and model where one was OK and the other was utterly useless. And i use USB-to-LAN adapters and switches, but i never ever advise others to do the same thing, as i am fully aware of the consequences, if something fails.

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 

Rod, this would have been much more useful in the "driver boards" or EtherCAT or both sections, not here as OP has actual networking disconnecting, same as physically removing the cable.
I really appreciate you trying to help, but i really do not like when you point members of this forum and whoever reads this in the wrong direction.
This is the second time i am mentioning on this topic that none of that tuning will help with a disconnected link.

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.