7i96 Joint Following Error

I'm trying to finish up my configuration tool but I keep getting a joint following error when I jog an axis. The sample configuration is attached. I'm running master uspace 0b443d. Latency test servo thread 52,000.

JT

As we discussed on IRC I suspect your host has poor enough Ethernet latency that some packets are timing out. At the sample configs high speeds (1200 IPM = 20 IPS) a missed packet will result in LinuxCNC using stale position feedback data from the stepgen (and 1 ms stale data would result in a 20 mill following error at 20 IPS)

Its possible to work around this error by "short-circuiting" the commanded stepgen data to the feedback data if a packet error occurs. As long as the errors are infrequent, very little actual position error is cause by a missed packet

Here is a hal file that implements this scheme:



You can also work around the issue by just setting the following error limit to > maxvel*servothread_period
but this has 2 bad side effects: 1. you need to set large following errors so you may miss real problems, and 2.
The PID loop "sees" the bogus stale position data and does a bogus correction, causing a real glitch in the
stepgen position tracking

Thanks so much for your help.

JT

Kinda glad I had a slow pc to test on. I added a couple of tabs to the 7i96 Configuration Tool so you can get the CPU info, NIC info and the tmax. Then added the calculations to show if the packet time is faster than the threshold. What would be a good percentage for packet time to threshold time?





JT

Its a bit subtle because you can make a working system that occasionally drops packets whether from excessive latency or EMI.
In my experience with Preempt-RT, Large Ethernet latencies happen infrequently so its possible to set the threshold to say 1/2 of the max number and only have very occasionally dropped packets, if you add the fix for timed out packets, you will like never notice the dropped packets at all.

If on the other had you never want to have a timed out packet, I would set the timeout to say 70% and make sure the latency is never more the say 35% when tested for an hour or so

In any case its great to have the actual Ethernet timing numbers available in the utility

You might want to indicate that the .79 and .70 numbers are in units of servo thread period
(and perhaps show them as 79 and 70 %) and perhaps suggest increasing the thread period if the number is more than
50% of the total servo thread time

Hello,

I have problem with latency like you. I would like ask you: What should I do?
Better CPU?
Better Ethernet Card?
Something change?
I am not PC specialist.

1. Have you disabled all power management in the BIOS?
(disable all turbo modes, speed-step options, cool-and-quiet, cstates >1 etc)

2. Have you run a standard latency test?
I suggest:
latency-histogram --nobase --sbinsize 1000

Run this for at least 10 minutes while opening windows, doing fie transfers,
watching you-tube videos etc and post the results here

I thought I didn't have to research latency when I had a mesa card.




Originally on this PC was RTAI+parallel port and the latency was below 30,000 ns. But the system was losing steps, so i bought 7i96.

It may be that for whatever reason the Ethernet is slow on your system
( The configurator tmax value indicates that almost 0.9 ms of the total time available
has been consumed by overhead so there is no margin left)

Latency is always important though larger latency can be tolerated
when there is hardware to do things like step generation

It may be that you will need to slow the servo thread on your PC to avoid
real time errors (I would try 2 mS = 2000000)

BIOS is problem for me. I dont understand this, so foto can be downloaded here: www.uschovna.cz/zasilka/YCZ8TCXT5ENUPIDJ-85U/ (it is big) STÁHNOUT VŠE JAKO ZIP = DOWNLOAD ALL LIKE ZIP

It may be that you will need to slow the servo thread on your PC to avoid
real time errors (I would try 2 mS = 2000000)

It is not better Packet Time is 3437844. (at SERVO_PERIOD = 1000000 I probably loaded it imperfectly)