Motor following error 7i76e

Hi,

I'm using PlasmaC with an old i3-Laptop and an Mesa 7i76e-Card on my cnc-plasma-cutter.
I use 2 Motors on the Y-Axis. Sometimes I get an Motor following error.

The Jitter-values are not very good >200 000. But LinuxCNC only sends the position to the Mesa-Card and the mesa-Card takes care of the realtime-stuff with the fpga-chip. Did I understand that correcty ? So jitter isn't really important for the 7i76e-card ?

Maybe the configuration isn't correct ?
The ini-file is attached.

Thanks for your help...

Laptops aren't usually recommended, this is pretty much stated in the docs.

Thanks.

But I get the same error when I copy the machine-configuration to a pc and run it from the pc. Its an older pc though (~20 years old).

You can get following errors if packets are dropped because
they timed out. This is almost always a latency issue.
To check this, see if:

hm2_7i76e.0.packet-error-total is >0

What happens if a RX packet times out is that stale stepgen
feedback data is used (from the previous servo thread) this causes
a following error of current_velocity*servo_thread_period

Fixes:

1. Improve the PCs latency
This includes disabling all power management in the BIOS,
including Cstates >C1 EIST, turbo modes Cool&Quiet etc etc,
Also disable hyperthreading and on corporate PCs, disable AMT
Additional options are using isolcpus and pinning the Ethernet
interrupt to the isolated real time CPU. There's a script to do this here:

forum.linuxcnc.org/38-general-linuxcnc-q...ead-and-irq-affinity

If improving the latency with the above methods does not help, there are some
other work-arounds:

2. Increase the DPLL pre-sampling time

setp hm2_7I76e.0.dpll.01.timer-us -200
setp hm2_7i76e.0.stepgen.timer-number 1



3. Raise the servo thread period. (to say 1500000 ns) The main side effect of raising
the servo thread period is that there will be fewer velocity steps during acceleration,
leading to rough motion on high acceleration machines

4. Increase the joint following error limits to > max_velocity*servo_thread_period

5. Add some hal plumbing so that when there is a lost packet, the (stale) feedback
position data is ignored and the commanded data is used instead. This also has
the advantage of smoother motion since the bogus correction (in the PID loop)
from the stale data is not performed.

Here is an example hal file that does this: