Unexpected real time delay on servo system

I'm confused about this error "Unexpected real time delay check dmesg for details"

My system is D525MW - Every possible option in BIOS disabled
Mesa 5i25 + 7i77
Operating a Bridgeport R2E3 (Boss 8) servo machine, original servos and amps.

My latency test results are pretty high considering other results I've seen:
Servo: Max jitter 29500
Base: Max jitter 58500

Using Isolcpus=1
Servo: Max jitter 27500
Base: Max jitter 29500

They are the results of hour long tests, glx gears etc. I'm pretty sure it's the screen saver which causes the spikes. I don't tend to use the Isolcpus boot option because it slows the computer down so much.

Anyway, there is no BASE_PERIOD in my ini file, only SERVO_PERIOD = 1000000

Why am I still seeing the error?

The dmesg file ends in:

Thanks for your time,

Tom

Hi

What GUI are you using?

It is probably Axis, so if you open the ini file and change
[DISPLAY]

DISPLAY = axis
to
DISPLAY = xemc

do you still get the problem?

Linuxcnc can throw a 'one-off' error when starting, due to intensive openGL in gremlin (the Axis plot viewer), coupled with disk reads, module loading etc to open the program.

Your error comes very soon after 5i25 registration, so right at the loading stage.

If you don't get the error when using xemc, it is possible that using a graphics card to take the load off the CPU and RAM would help with Axis, but unless you get any other problems
I should just try using it and ignore the initial error.

regards

Hi, thanks for replying so quickly.

I'm using Gmoccapy, which has the same plot viewer as axis. I rebooted then tried with xemc, no error, then I tried again with gmoccapy, no error. I don't get this error reliably but I have seen it a couple of times.

I don't think there is an option of dedicated graphics with D525MW, I only have one PCI slot and i'm using that for the 5i25.

So it is safe for me to ignore the error if it persists? I mean, i'm not step generating so I shouldn't have any problems...?

Just had another go (using Gmoccapy)

It took about 5 mins before the real time delay error came up, I managed to drill two holes...

[102177.945222] In recent history there were
[102177.945225] 1604880, 1789515, 1800765, 1798749, and 1983708
[102177.945227] elapsed clocks between calls to the motion controller.
[102177.945238] This time, there were 1994256 which is so anomalously
[102177.945241] large that it probably signifies a problem with your
[102177.945243] realtime configuration. For the rest of this run of
[102177.945246] EMC, this message will be suppressed.
[102177.945248]

These numbers are in CPU clocks (the D525 has a 1800 MHZ clock)

I'm pretty sure RTAI based versions of LinuxCNC report real time errors when a >20%
thread timing error occurs,

Two of the above thread intervals comprise a set with > 20% change

1604880 = 891.6 uSec
1994256 = 1107.9 uSec

So despite what the latency test shows, the D525 is showing latencies in the order of 100+usec

This matches my experience with the Atom MBs, decent latency test results but relatively poor performance when actual working latency is measured, for example its not possible to run a 2 KHz servo thread on a Atom D525 without real time errors even though a latency test suggests it should be possible.

EDIT forgot to add:

Is it safe to ignore? probably...

If you consider the side effects of a real time delay on a servo system you can decide whether its important enough to fix

The primary side effect of a real time delay on a servo system is changing the time of sampling the encoder counter, This will cause a bogus error input into the PID loop thats proportional to velocity
(so has no effect if axis are not moving)

For example at a 1 KHz servo thread rate, a 100 usec delay spike when moving 120 IPM will result
in an apparent 200 uInch error (assuming 0 error before and perfect velocity control)

Typically delay spikes have low density so a single 1 ms sample with a 200 uInch apparent error will be filtered by the PID loop, motor drive and mechanics so will cause a smaller than 200 uinch actual path deviation.

the second dmesg dump ended with:

So if my D525 does have latency of +-100usec, can I simply increase my servo_period? Will I need to increase my following error etc as well? This kind of sucks.

Sorry, didn't see your edit.

So at 120IPM (3000mm/min) which is pretty fast, one spike is 0.005mm (I cant think in imperial). I wonder how many spikes there are though, doesn't take long for the error to occur. I guess at finishing speeds its less than 0.001 which is an order of magnitude less than accuracy of my machine.

as an aside, I also get this error whenever switching on my coolant (please see attached image)



I have a push button linked to a field input on the 7i77, then a field out drives a 24v relay which operates my coolant pump. The functionality always works, it just sometimes gives me that error...

as an aside, I also get this error whenever switching on my coolant (please see attached image

I have a push button linked to a field input on the 7i77, then a field out drives a 24v relay which operates my coolant pump. The functionality always works, it just sometimes gives me that error...

I think this error is caused by the serial link going down.

One thing that will certainly cause it, is an interruption in the field supply to the daughter board.

PCW will be able to say for sure.

Just makes me think about wiring and the source of the supply voltage.

regards

Yes the error can be caused by the loss of momentary power ,

this could be either the power supply is not able to supply demand to pull the relay etc , and theirs a surge on the field power
so check out your supplys , or perhaps the wiring is too thin for the current used etc