"Following error" on a slow toolpath that's worked before?

I got a following error on my X and Z axes just now running a toolpath I've run several times before, on this and different similar parts. I forget what it means for there to be one on a stepper axis (i.e. no feedback). The X axis wasn't doing much, the Z was bopping up and down a little, but nothing out of the ordinary; well below it's velocity and accel, I think.

This has possibly scrapped my part. I'd like to know how to be more robust in this situation. Any advice?

Can you post your hal and ini files?

Oh sure, sorry. Here they are:

github.com/JetForMe/router-table/tree/at...uxcnc/config/router3

My suggestion would be to widen the following error limits

1.
If LinuxCNC gets a Ethernet RX packet timeout, it will use old
position feedback data , possible resulting on a FE as large
as servo_thread_period x velocity. So my guess is that you
are getting rare timeouts which cause an apparent FE.
Note that this is not a real position error.
A max_ferror of 0.6mm will prevent triggering a following error
at your 600 mm/s and 1 ms servo thread period if you drop a packet.

2.
It may also be that FF2 needs to be tuned a little better
to meet your narrow FE settings


There is a way to deal a bit more cleverly with occasional timeouts
by using the packet error bit to change the position feedback
to the commanded position if there has been a timeout. This prevents
bogus FEs from stale position data.

This has the side benefit of not making bogus velocity corrections
in case of dropped packets (and resulting stale feedback data).

# switch fb data to command on packet error:
net perror hm2_[HOSTMOT2](BOARD).0.packet-error => mux2.0.sel mux2.1.sel mux2.2 .sel

# Joint 0 connections
net emcmot.00.pos-cmd joint.0.motor-pos-cmd => pid.0.command mux2.0.in1
net fb0 mux2.0.in0 <= hm2_[HOSTMOT2](BOARD).0.stepgen.00.position-fb
# feedback position to motion is forced to be commanded position if there's a packet error
net motor.00.pos-fb <= mux2.0.out joint.0.motor-pos-fb pid.0.feedback

Oh wow, this is probably the area I understand the least. It sounds like you're suggesting, rather than doing 1 & 2, I do the mux-on-error thing you show, right?

I would try the simplest thing first (widen the following error to
maxvel*servo_thread_period and min_ferror to maybe 10X larger)

MIN_FERROR should be 10x larger than FERROR? This seems to go against what this page shows: wiki.linuxcnc.org/cgi-bin/wiki.pl?Following_Error

Sorry I meant about 10x larger than it was.