Advanced Search

gene_weber wrote:

Rather than starting a new thread about jitter mitigation, I'm just going to add it here.

First, I'm keeping in mind that Peter Wallace said " The jitter is basically unimportant with a 7C81 unless its so bad you
get real time errors at the normal servo thread rate."

I'm also treating the Raspberry Pi + 7C81 as a dedicated controller, not a PC. By that I mean I'm not going to be doing anything on the Pi except LinuxCNC. I may turn on WIFI to update packages, or use email to transfer a file. But I plan to even turn off WIFI before I launch LinuxCNC.


I ran several tests to see which combination of settings offered the most optimized jitter. I ran two Glxgears for all tests as I though that was reasonable, and ran the tests for long periods of time unless they looked bad early on.

I thought that turning off all unused services would decrease Jitter. So I turned off 9 of the 23 services, such as CUPS, Bluetooth, etc. To my surprise this did not decrease jitter.

Screen blank increased jitter a bit, so I turned that off. It doesn't make much sense anyway on a CNC controller.


These are the settings I added to the line already in /boot/firmware/cmdline.txt:

skew_tick=1 kthread_cpus=0-2 irqaffinity=0-2 rcu_nocb_poll rcu_nocbs=3 nohz=on nohz_full=3 isolcpus=3

I tried a few others that some people recommended on various blogs. Nothing else I tried had any noticeable positive impact on jitter, and some noticeably slowed down the responsiveness of the Pi.


Turning off timer_migration did reduce jitter. What I read said that you could make this setting permanent by adding it to the boot command line, or setting it in either of two different system files. Oddly none of that worked. So I setup a cron job to disable it at boot, and that works.
[code]crontab -e
Add the following line:
[code]@reboot sudo sysctl kernel.timer_migration=0


The other thing that helped reduce jitter was changing the scheduling policy to real-time and increasing the priority. I decided to create a shell script to launch latency-histogram, and eventually linuxcnc, which changes these things on the process.

[code]#!/bin/bash
#
# Run with the SCHED_RR real-time policy at the highest priority level (99)
# Uses chrt to switch the process policy and priority immediately after launch.
#
# Gene Weber - January 2025
#
# "The difference between SCHED_FIFO and SCHED_RR is that among tasks with the same priority,
# SCHED_RR performs a round-robin with a certain timeslice; SCHED_FIFO, instead, needs the task
# to explicitly yield the processor." -Claudio

priority=99

# Truncate $1 (the command) to 15 characters starting at 0.
command=${1:0:15}

# Execute the command line provided to rrt as a background task.
`$@` &

# Get the process ID of the command.
PID=`pgrep $command`

# Change the real-time policy to SCHED_FIFO with a priority of $priority.
sudo chrt -r -p $priority $PID


I named it rrt (run real-time). So to launch latency-histogram it's simply:
[code]rrt latency-histogram --nobase --sbins 1000

All spawned sub-processes inherit the policy and priority. So if linuxcnc is launched with rrt:
[code]rrt linuxcnc
all of the processes that are part of LinuxCNC have the policy of SCHED_RR and priority of 99. I used Round Robin scheduling to make sure no LinuxCNC process "starves" another.

I don't know if this will work in the end, but I'm going to give it a try. Nothing ventured, nothing gained.

Implementing all of these, here is the jitter histogram. Good enough.
[attachment=67004]final-16Jan2025-3117.png[/attachment]
 

[/code][/code][/code][/code][/code]

 

I think it's just easier to isolate 2 cores, it really doesn't affect performance. And reading the docs, mainly pertaining to amd64, the general rule is to isolate cores on the same physical die, for reason beyond my pay grade.

One thing that might be worth of note, as development moves along, is to check the Makelfile in the top of the directory as minor revisions can change for the the rpi-linux kernel.

Or you can run

Getting a Hunk #1-9 succeeded, and a few lines later (right after trace.c) a HUNK #1 failed during the patch. 

install and kernel activation does seem to complete if it’s ignored. 

See network can't connect to to them. What am I missing? 

Thank you for helping. it is working. having some troubles with the WIFI see new work can't connect. What file are recommended for the byte to bot set up with the Parallel Port Raspberry Pi Hat and 5 axis breakout board.

RPI5 needs the hm2_spix driver

Unfortunately linuxCNC terminates immediately with the following errors:
hm2_rpspi: Cant map peripherals: Invalid argument
hm2_rpspi: Cant map peripheral memory.

And so on (as far as I remember these were the original errors you had way back right?)
Is there anything specific I have to set up? I just pulled my machine config & tried to run it.

Thank you

Oh ok, some users have reported issues with other images with RPi imager.

works now! thanks yeah the RPi imager can be used with a custom image and works like balena then.

cnc
cnc

These images aren't based on the raspios, they are based on Debian bookworm.
I'm actually surprised the RPi imager worked with the image. Usually balena etcher or some other utility is required.

@cornholio I'm sure I'm just stupid... but I can't seem to get past the first login/pw check? No matter what I setup in the rpi imager, it always tells me that the password is wrong.. I have also tried all default passwords (like root/root & pi/raspberry..) any idea?

andypugh wrote:

pncconf does call mesaflash so if you don;t have mesaflash that might explain why discovery is not working.

Does "sudo apt-get install mesaflash" work?

Did you manage to create a config in Debian 12? If you did, then that same config should work in 11.
 

Hi Vector, tommylight and andypugh,

Thank you for the trouble-shooting discussion on Unspecified Error with Discovery option.

My computer is Raspberry Pi 4, Debian 12 Bookworm, the Kernel is Linux picnc 6.6.59-rt45-v8-behai-rt-build+ #1 SMP PREEMPT_RT Sat Nov  2 10:20:46 AEDT 2024 aarch64 GNU/Linux.

I am also able to ping it at 10.10.10.10, and I did have the same error when used Board Discovery.

Failing discovery, I selected:

[
Board name = 7i96s-Internal Data
Firmware = 7i96s_d
]

It appears to work, since I can move to other screens... I was not able to proceed any further, because I don't know what to do next yet.

Then I retry by running sudo apt-get install mesaflash, and afterward Board Discovery works:

[
Board name = Discovered: 7i96s
Firmware = ~/mesa0_discovered.xml
]

I am happy, this is a progress for me. I have read the configuration the HAL parts of the manual. But it still not registered yet... I have to do some more reading.

And also I have to learn how to connect the CL57T-V4 closed-loop motor driver the 7i96s.

Thank you and best regards,

...behai.

 

Hi,

I have just received my Mesa 7i96s today from Mr. Andrew Beck of BECK CNC.

I left W4 and W5 at their default setting ( I can't see jumpers ) And I have followed the instructions given in this thread, and I am able to ping it.

This is what I have done:

With the Ethernet cable connected between Mesa 7i96s and Raspberry Pi4

[
behai@picnc:~ $ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether d8:3a:dd:25:8c:37 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
    link/ether d8:3a:dd:25:8c:38 brd ff:ff:ff:ff:ff:ff
]

I notice that eth0 shows <BROADCAST,MULTICAST,UP,LOWER_UP>

With the Ethernet cable disconnected:

[
behai@picnc:~ $ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
    link/ether d8:3a:dd:25:8c:37 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
    link/ether d8:3a:dd:25:8c:38 brd ff:ff:ff:ff:ff:ff
]

I notice that eth0 shows <NO-CARRIER,BROADCAST,MULTICAST,UP>

So I guess my hardwired ethernet is eth0.

Then I log into my home router to verify that 192.168.1/24 is not in used as per the official manual instruction.

I then added the following lines into /etc/network/interfaces:

[
auto eth0
iface eth0 inet static
address 192.168.1.121
hardware-irq-coalesce-rx-usecs 0
]

Then I ran sudo ifdown -a followed by sudo ifup -a, both ran successfully. I.e. they produced no output.

Then finally: ping 192.168.1.121

The response is continuous until I pressed Control + C to interrupt.

I HAVE A QUESTION, PLEASE:

While the pinging was running, I disconnected the Ethernet cable, I expect the response to stop or at least to halt, but it did not. It continues to produce pinging notifications. Is this normal, please?

Thank you and best regards,

...behai.




 

Thank you! Will try it out on friday.

Ok I’ll make a note of that.
Thanks for testing.