[SOLVED] Mesa 7i76E - Joint Following Error - Error Finishing Read

That's what I was thinking

The leds do count up while pinging

Here is the ping output

PING 10.10.10.10 (10.10.10.10) 56(84) bytes of data.
64 bytes from 10.10.10.10: icmp_seq=1 ttl=64 time=0.196 ms
64 bytes from 10.10.10.10: icmp_seq=2 ttl=64 time=0.111 ms
64 bytes from 10.10.10.10: icmp_seq=3 ttl=64 time=0.110 ms
64 bytes from 10.10.10.10: icmp_seq=4 ttl=64 time=0.091 ms
64 bytes from 10.10.10.10: icmp_seq=5 ttl=64 time=0.108 ms
64 bytes from 10.10.10.10: icmp_seq=6 ttl=64 time=0.106 ms
64 bytes from 10.10.10.10: icmp_seq=7 ttl=64 time=0.111 ms
64 bytes from 10.10.10.10: icmp_seq=8 ttl=64 time=0.112 ms
64 bytes from 10.10.10.10: icmp_seq=9 ttl=64 time=0.107 ms
64 bytes from 10.10.10.10: icmp_seq=10 ttl=64 time=0.103 ms
64 bytes from 10.10.10.10: icmp_seq=11 ttl=64 time=0.111 ms
64 bytes from 10.10.10.10: icmp_seq=12 ttl=64 time=0.106 ms
64 bytes from 10.10.10.10: icmp_seq=13 ttl=64 time=0.106 ms
64 bytes from 10.10.10.10: icmp_seq=14 ttl=64 time=0.094 ms
64 bytes from 10.10.10.10: icmp_seq=15 ttl=64 time=0.106 ms
c64 bytes from 10.10.10.10: icmp_seq=16 ttl=64 time=0.105 ms
64 bytes from 10.10.10.10: icmp_seq=17 ttl=64 time=0.120 ms
64 bytes from 10.10.10.10: icmp_seq=18 ttl=64 time=0.113 ms
64 bytes from 10.10.10.10: icmp_seq=19 ttl=64 time=0.100 ms
^C
--- 10.10.10.10 ping statistics ---
19 packets transmitted, 19 received, 0% packet loss, time 747ms

Pulled the board out of the control panel and hooked it up to a different power supply.

Errors are gone.

Maybe interference from mains voltage or flakey power supply.

Not to jump on and steal your thread, but I'm having very similar problems with my setup (RPi4/7i96). I'll try the power supply fix again (already switched it out once, but worth a shot)

Quick question, what were you getting for ping times when you had it hooked up to the RPi4?

I've tried all the ethtool tricks and can't seem to get my connection below ~.250-.300ms. I'm curious what others are getting.

What is your servo thread period?

There are basically 2 ways that you can get the dreaded "error finishing read":

1. You have lost all Ethernet communications (say a power supply related dropout)

2. Too many timeouts are happening and you have exceeded the threshold

The default timeout threshold for read data is 80% of the servo period. To get an idea if you are getting timeouts, you can look at the hal tmax values:

halcmd show param *.tmax

(When LinuxCNC has been is running for a while)

These numbers are in ns on the RPI

I've been tuning the different variables to see their effects. As I crank up the velocity, I start getting following errors. As I increase the servo period (1,000,000), those following errors get worse and at lower velocities. If I decrease the servo period (500,000), I get the "error finishing read" quicker (lower iteration numbers). Since I'm running galvos, velocity is of the essence

Multivariable problem for sure. Including Ferror and PID tuning. I was just curious if my ethernet connection is functioning normally. Seeing folks with <100 ms ping from desktop machines got me wondering what a "normal" value for RPi4 is.

I think the RPI4 cannot manage a 1 KHz servo thread over Ethernet so 500Hz is suggested.

Tuning for stepgens/XY100 is normally fixed:

FF1=1.00
P = 1/Servo thread period (so 500 for a 2 ms servo thread)

Also for minimum following error, the DPLL should be used
(and timesyncd replaced with ntpd)

Won't the max speed ultimately be limited by the servo thread? Too many commands, not enough time to communicate htem? Shouldn't I get that to the maximum rate my hardware can handle? That was my thinking when chasing down ethernet connections. Get to a stable state where I'm not getting anymore "error finishing read" with the maximum possible thread rate. Then work on the other variables to fix the joint following errors to get the max speed

Can you explain that last comment ("and timesyncd replaced with ntpd") a bit more?

For reference, here's what I currently have for a set up

The maximum velocity is independent of the servo thread rate
(velocity is just a value written to a register every servo thread invocation)

What will change is the chord error because the velocity is only updated
every servo thread so the motion will be divided into a set a line segments
where velocity is constant.

timesyncd makes big steps in LinuxCNCs timebase which can be avoided
by using ntpd (not sure if this has already been done with LinuxCNC RPI images)

I would probably set the DPLL time to about -100

I was trying to be careful about usage of the words velocity and speed. By "speed" I was thinking about a curvy line or rastering. Whereby the more points along that line and the higher the velocity (less divisions between ptN & ptN+1), you start running out of time for all the necessary course commands.

I'll research timesycncd vs ntpd and adjust the DPLL

Thank again for your help!

Yes, acceleration determines path following errors = chord errors
(though these will not cause following errors)

With your current DPLL settings (write time same as read) the velocity update
will always be 1 ms after the nominal read time with 1 ms servo thread. If this is the case, you can
improve the following error by setting the FF2 parameter to 0.001
(FF2 should be the number of seconds between read and write)

A halscope plot of the joint following error+joint velocity would
help to figure out the cause of the following errors.