Advanced Search

I can make 7I76EU  + 7I85 + 7I74 firmware but not sure why you would need the 7I74
as there are 6 available Sserial ports with just the 7I76EU (1) and 7I85 (5).

7i76eu_7i76x1_7i85x1d.bin is the firmware for a 7I76EU and a 7I85.

 

Hello,

I am using a Mesa 7I76EU board and would like to know if a firmware configuration exists that supports simultaneous operation with a standard 7I85 board and a 7I74 board.

My planned hardware configuration is:

* Mesa 7I76EU
* Mesa 7I85 (standard 7I85, not 7I85S)
* Mesa 7I74
* Two Mesa 7I84U boards connected through the 7I74

I have successfully tested the following firmware:

7i76eu_7i76x1_7i85x1d.bin

The firmware was loaded successfully, and LinuxCNC correctly detected all six MuxedQCount channels provided by the 7I85.

After loading this firmware, LinuxCNC reports:

* 6 MuxedQCount channels
* 1 MuxedQCountSel channel

The 7I85 board will be used to connect four RS-422 linear scales (X, Y, Z, and W).

The 7I74 board will be used as a Smart Serial Hub for two 7I84U I/O expansion boards.

While reviewing the Mesa firmware archive for the 7I76EU, I could not find a ready-made firmware configuration for:

7I76EU + 7I85 + 7I74

However, I found the following VHDL source file:

PIN_7I76x1_7i85sx1_7i74x1D_51.vhd

which suggests that a configuration for a 7I85S + 7I74 combination exists.

I would appreciate advice on the following:

* Is there an existing firmware configuration for the standard 7I85 and 7I74 combination?
* If not, is it possible to obtain such a configuration from Mesa or build it from the available source files?
* Are there any FPGA resource limitations on the 7I76EU that would prevent simultaneous use of both the 7I85 and the 7I74?

Any information or recommendations would be greatly appreciated.

Thank you.
 

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`)