LinuxCNC on Raspberry Pi 5

Hi,
Here is a YouTube link that may be useful.

I found a sweet spot for a moment. github/raspberrypi/linux rpi-6.6.y was at 6.6.12 (rpi-6.6.y is now at 6.6.13). I used patch-6.6.12-rt20.patch.xz The patch applied with no problems.
 uname -a
Linux RaspberryPi5-1 6.6.12-rt20-v8-16k+ #2 SMP PREEMPT_RT Mon Jan 22 08:35:10 CST 2024 aarch64 GNU/Linux

I haven't done any testing yet. If it looks good I will try to create a release for the .debs on github.

 

I now have a RPi 5 8 GB model and Mesa 7i96S card. I have downloaded and installed onto a 32 GB micro SD card "LinuxCNC 2.9.2 Raspberry Pi 5 OS based on Debian Bookworm Raspberry Pi 5 Uspace compatible with Mesa Ethernet and SPI interface boards."

I have the Pi (10.10.10.1) talking over ethernet to 7i96S (10.10.10.10) following a W5 jumper change on 7i96S and Linux command:

sudo ip address add 10.10.10.1/24 dev eth0  /* this will work but DON'T USE THIS as it will not persist after a reboot */

ping 10.10.10.10

To ensure the settings persist after a reboot, AND noting that Linux networking commands seem to have recently changed, the following works:

nmcli con show  /* this will show the RPi 5 wireless and wired "ethernet" connections, and the NAME e.g. "Wired connection 1" for TYPE "ethernet" */

sudo nmcli con mod "Wired connection 1" ipv4.addresses 10.10.10.1/24  /* dunno where this gets saved in RPi OS */

Test if persistent by rebooting, then typing again:

nmcli con show  /* DEVICE should now = "eth0" */

ping 10.10.10.10  /* ping the Mesa 7i96 card -- I get a ping time of 30-40 us */

This editor is ghastly

Yup, I find it kinda funny that a site catering to technology uses such a terrible editor

I have used a lot of forums but never seen one this bad

If it wasn't for the great people here it'd just be too painful hahahah.

The good news is that the RPi and Mesa 7i96s are communicating and appeared to be doing so reliably using the Dragon GUI until a string of these messages appeared:

hm2/hm2_7i92.0: error queuing read! iter=xxx
hm2/hm2_7i92.0: error finishing write! iter=xxx

If I run the following, there appears to be dropped packets:

sudo chrt 99 ping -i .001 -q 10.10.10.10  /* forum.linuxcnc.org/27-driver-boards/4837...rite?start=20#266420 */

About 25% were dropped when using a 30 cm CAT cable (not sure what type, shown in photo above). Changing to a longer CAT 5e cable resulted in a tiny percentage of dropped packets. Nevertheless, the errors keep appearing when running Dragon GUI -- I'm not suggesting that Dragon GUI is the issue here.

Its a hardware issue. please read my tutorial here
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing

Thanks, I will give that a try tomorrow and report back.

Hey Richie, how did you go with the RPi 5? I have the same + Mesa 7i96s in Blenheim…

Running this on RPi 5 8 GB with Mesa 7i96s:

latency-histogram --nobase --sbinsize 1000

With essentially no load on the Pi, have after about 400 seconds:

min (us) = -18.8
max (us) = 19.2
sdev (us) = 0.9

With 1x Glxgears, after about 80 seconds:

min (us) = -16.6
max (us) = 14.5
sdev (us) = 0.9

With 2x Glxgears, after about 80 seconds:

min (us) = -20.4
max (us) = 15.2
sdev (us) = 1.6

With 3x Glxgears, after about 80 seconds:

min (us) = -18.6
max (us) = 16.5
sdev (us) = 2.2

With 4x Glxgears, after about 80 seconds:

min (us) = -17.2
max (us) = 18.3
sdev (us) = 2.6

With 5x Glxgears, after about 80 seconds:

min (us) = -21.6
max (us) = 20.6
sdev (us) = 3.0

With 6x Glxgears, after about 80 seconds:

min (us) = -16.5
max (us) = 18.1
sdev (us) = 3.1

With 10x Glxgears, after about 80 seconds:

min (us) = -23.8
max (us) = 16.6
sdev (us) = 3.5

Seems that the 7i96s ethernet connection to the Pi has died again during these tests.

======================

Repeating the 10 gears version on HP i5 8100 Elite SFF x86_64 6.1.0-13-rt-amd64 2.9.1 3.6 GHz

With 10x Glxgears, after about 200 seconds:

(1000 us servo thread)
min (us) = -80.8
max (us) = 79.3
sdev (us) = 1.5

(25 us base thread)
min (us) = -24.9
max (us) = 42.4
sdev (us) = 0.8
 

Being new hardware, its possible you are a victim of enegy efficient ethernet.

ref:  www.juniper.net/documentation/us/en/soft...e%20link%20is%20idle .

Could you try disbale it by adding
igb.EEE=0

to your boot parameters (where you put isolcpus) I think its boot.txt on the pi
I have no idea if this will work!