Joint following error

Hi all.
I started a drilling job (about 70 holes) but after about 20 minutes (15 holes) the machine stopped with 2 error messages:

- hm2/hm2_7i76e.0:error finishing read!
- joint 0 following error

I suppose is something related to ini or hal files, but honestly don't know ho to fix it (and more understand why it happens).

Thanks

Andrea

hm2/hm2_7i76e.0:error finishing read!

Means that you have lost contact with the 7I76E
This may be an electrical issue or a problem with latency on the host PC

What do you get for times if you ping the 7I76E?

What Host hardware do you have?

What OS are you running (uname -a)?

Ping results:
23 packages
Avg 0.069ms
Min 0.049ms
Max 0.113ms
0% loss

Hdware:
Asrock Q1900M
Intel celeron J1900 1.99Ghz
RAM 8Gb
Onboard lan port (for mesa) + additional lan port (web)

OS:
4.9.0-8-rt-amd64 #1 smp preempt rt debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/LINUX

I run a latency test while retrieving the os data,getting this:
Max jitter 82864 (servo thread) - 62588 (base thread)
Running 10 instances of glxgears (and terminal windows):
82864 (servo thread) - 1555650 (base thread)

Are all power management/Turbo modes/Cstates > C1 disabled in BIOS?

Sorry for late reply (time difference with the "old world").
Currently I'm at workplace, but as far as I remember everything is disabled (that's why when I installed the mesa board I got a good increase, or better a "decrease", of latency).
BTW, as soon as I'll back home in the late afternoon (about 8 hrs) I'll check the bios settings too.

Well, I checked the bios settings.
This is a resume of some various settings:

- Intel Speedstep Technology (Disabled)
- CPU Cstates support (Disabled)
- Enhanced Halt State (C1E) (Disabled)
- No execute memory protection (Disabled)
- Intel virtualization technology (Disabled)
- IGPU multimonitor (Disabled)
- Onboard HD audio (Disabled)
- Deep S5 (Disabled)
- Sata aggressive link power management (Disabled)
- Hard Disk S.M.A.R.T. (Disabled)
- Intel smart connect technology (Disabled)
- Suspend to RAM (Auto)
- ACPI HPET Table (Enabled)
- PS2 Keyboard Power on (Disabled)
- PCIE Device Power on (Disabled)
- Ring-in Power on (Disabled)
- RTC Alarm Power on (Disabled)
- USB keyboard/remote Power on (Disabled)
- USB mouse Power on (Disabled)
- USB controller (Enabled)
- Intel USB 3.0 Mode (Auto)
- Legacy USB Support (Enabled)

I think everything unnecessary is disabled.....

Running 10 instances of glxgears (and terminal windows):
82864 (servo thread) - 1555650 (base thread)

This indicates a major latency issue but a better test would be to run
without a base thread:

latency-test 1ms 1ms
or
latency-histogram --nobase --sbinsize 1000

I'll try this one too and let you know.

I tried both commands

The first gave me a Max Jitter of 22845; then when I started the browser to write this post, the value raised up to 168149 (no glxgears instances)

The second command (with 10 instances of glxgears): 1st test without browser, 2nd test with browser, 3rd test only browser (no glxgears instances)

Reading some posts in the forum about people with the same issue, I red the solution gaven to fix it: the parameter FERROR in the INI file.
In particular, to set this value as 1 (not higher).
I tried to set my values to 1 (they were 10), then started a .... fake job (spindle off and no bit). Everything was fine, so I risked to start a complete job.
The machine accomplished the task, without any issue.

My doubt: this was the solution to my problem or just a lucky strike / coincidence?

Reading the FERROR documentation, as I understood (?) it concerns the axis position control for open loop systems. My is a closed loop one. Does it matter?