Random read errors on Mesa 7i92

I've had some success!

I ordered a new shielded ethernet cable. When I installed it, I found that my vent fan had shorted out earlier, and taken down the 24V and 5V power supplies, which killed power to the Mesa card. I think that this caused the read error that I mentioned a few posts back.

The new ethernet cable (and also the commercially made regular cable that I used earlier) have eliminated the

hm2/hm2_7i92.0: error finishing read! iter = xxxxxxxxxx

problems that I was experiencing. The old cable I was using was a home made cable that was about 25 years old, and I think that it had a weak connection somewhere that was causing the dropped packets.

I'm still getting the

Unexpected realtime delay on task 0 This message will only display once per session Run the latency test and resolve before continuing

message.

As I mentioned in an earlier post, I'm getting occasional delays of 45-55,000, but in general my latency is fairly low. My understanding is that these are acceptable for the USB Mesa card. I'm not sure what level of latency triggers the realtime delay message, but perhaps it's set at 50,000 or so, and I should just ignore the message.

The latency numbers in the latency test are really just dispatch latency
(the test doesn't actually do anything like allocate memory or perform I/O, things that can have their own latencies)

What is likely happening is that you are running out of time on the servo thread
to check this, watch

servo-thread.tmax

This is the maximum number of CPU clocks that the servo thread took to complete
If its getting close to servo_thread_period*CPU_Clock_Speed, you will get real time delay errors
The solution is to either improve the latency or raise the servo thread period

The ECS Liva X has a Baytrail (Atom) processor running at 1.58GHz (with a 2.25GHz Turbo).

My .ini settings are

[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
SERVO_PERIOD = 1000000

So 1,000,000 x 10E-9 sec x 1.58 x 10E9 clock cycles / sec = 1,580,000 clock cycles per servo period.

I watched servo-thread.tmax using Halshow under the Watch tab for about three hours. It started at 459,116 clock cycles, and crept up to 1,396,994 clock cycles in about an hour.

I would assume that these are "close", and if I let this run for many hours I would expect them to get even closer.

I've been trying different things to decrease the latency for about three months, so I don't think that I'll have much luck there. So, given that I'm reading spindle RPM (10 pulses / rev, 2,500 RPM max, discussed by us in another thread), what would you recommend increasing SERVO_PERIOD to? Or, said another way, what bad things might happen as the period gets longer?

I would set the period to say 1.2 ms and see if the real time errors go away
This is just on the edge of not working with the software encoder at 10 pulse/rev and 2500 RPM
so a custom config with just A and index would be better

Another option is this:
use the eth_pkt_loss branch and run the thread at say 2 KHz and live with the
occasional timed out packets (they should cause no harm)

Note that if you raise the thread rate, the average response time gets better (due to caching)

Here are the results based on your suggestions:

TEST 1: Changed to:

SERVO_PERIOD = 1200000

Got realtime delay error. Checked servo-thread.tmax, and found it to be a little over 2,500,000. That's quite a lot more than what I saw earlier.

(Note: I already have the spindle tach working with A and index only - not sure if that'd change your recommended period.)

TEST 2: Installed new version of LinuxCNC by doing following

pointed to repository

deb buildbot.linuxcnc.org/ wheezy linuxcnc-rtpreempt

then

sudo apt-get update
sudo apt-get install linuxcnc-uspace

A new version of LinuxCNC was installed. Now when I run it, it shows version 2.7.5-18 gaee5dfl

Changed to:

SERVO_PERIOD = 500000

Ran program, and I still get the realtime delay error. I have not yet run an extended test to see if I get the hm2 read error.

can you check if the parameter

hm2_7i92.0.packet-read-timeout

exists

Yes, I have a hm2_7i92.0.packet-read-timeout.

Value is 80

can you check
hm2_7i92.0.read.tmax
to see if its the issue

Value of hm2_7i92.0.read.tmax is 2,599,656 after about two hours running.
I watched hm2_7i92.0.read.time for a bit, and it's bouncing around 250-1,000.