Unexpected Realtime Delay on task 0....

Does it need to be under load? I'm running a longer test now with GLXGears running.

I had increased servo period before to 2 million... still got errors but that was an eternity ago (at least 3 days )

I've seen this typed a bunch, standard servo period is 1 million in INI file units (one and 6 zeros?). I've seen 10 mil a couple times and 100K once in various forums.

While I'm nitpicking... Can you please enlighten me on units in the INI? I'm using GMOCCAPY and my gosh the mix of machine units per min and machine units per sec is maddening. Is there a rule of thumb to make sense of it?

Finally, my Z axis is herky-jerky. I was able to tune timing (the step space, step length, dir setup and dir length settings) to get X and Y behaving, I have the same driver and stepper but different pitch thread on my Z (and corresponding step rate) and Z is still awful. Any insight there?

Almost all low level motion units in the ini file are specified in machine units
(mm or inches) per second except for spindle speed.

User interface and gcode values (like feed rates) are usuall specified/displayed
in per minute units.

If you still get real time errors at a 2 ms servo thread rate, it suggests that there
are either some latency related BIOS settings the have not been disabled or that the
PC is simply not suitable for real time use.

(this is often true of laptops because they have power saving features that
cannot be disabled)

Not sure on you Z axis but would note that step timings don't really
need to be tuned, they should just be set to say 2X the drives
minimum specs. Longer timings never hurt unless they limit your
desired step rate.

Changed the period to 2000000 and the P value to .5 and holy crap it's like a different machine. All moves are smooth, no trembling at stop. Z would continue that behavior for a second or so, but all axes had some of it, but now they don't.

I'm leaving it running for a bit. in the past I'd get a realtime delay error pretty quickly after starting LCNC... hope that's solved.

is the peak of the histogram the max delay? The running copy (ran for half hour) had a max.peak north of 900,000 on the Y scale of the graph.

This is an Intel NUC computer. so probably laptop-ish hardware but in a single board computer format. Gonna doublecheck SMI and disable onboard audio... if this has it licked then I'll be overjoyed.

THANK YOU for your help.

P should be 500 for a 2 ms servo thread

On the histogram, the Y peak is the number of samples
(which will increase the longer you run) the largest X deviation
from the X center is the maximum jitter.

histogram peak makes more sense. duh.

so P is the "amplitude" to move during a step? so if you double the length of the step you have to halve the input or you'll overshoot?

P is the velocity correction applied (position_error*P)

The stepgen PID loop is 99.9 % controlled by just setting
the stepgen velocity to LinuxCNC's commanded velocity.
This is done by the FF1=1.00 PID term. Because
the stepgen hardware clock is not exactly the same
as LinuxCNC's clock and the position read and
velocity write times are not exact, there are small
errors in position that the P term of the PID loop
corrects


A P value of 1/servo period (so 500 for a 2 ms thread)
means that any detected position error is corrected by
the next waypoint (one servo period later)

Interesting, so before it was overcorrecting maybe , causing the vibrate behavior I saw?

Probably. If you have bad latency its possible that the DPLL settings result
it a 2 servo period delay between the position read and the position write
This can result in instability

If the P term is > 2X 1/servo_thread_period the control loop
will be unstable (This is expected because at 2X, the correction
will be twice as large as needed so you get a new error as
big as the original error but in the opposite direction)

Unfortunately I saw that error again this evening. I went back through the bios, didn't see anything else to turn off. I may try disabling SMI, maybe with the "SMICTRL" approach...

Anything else I can try? Will this run on a RaspberryPI 3B? or 4?

I'm beginning to get really discouraged.

I'm still getting "unexpected realtime delay" or the "error finishing read" and "error queueing read".

I uninstalled the newer networking package, reinstalled network-manager per some instructions. It looks like sometimes the UI is "spinning" trying to establish a connection, while its already connected.

I disabled SMI with SMICTRL.
I used ETHTOOL to turn off IRQ Coalescing (sudo ethtool -C <connection> rx-usecs 0) and it said it was already disabled/nothing to change.

I left a ping running in the background on one test and I saw "network is unreachable" for part of the pings. I tried again and it seems that ping is blocked while GMOCCAPY/LinuxCNC is running?

I ran the Halcmd show param *.tmax thing:

hm2_7i96.0.read.tmax is 1963800 on one run and 1996640 on another. I think that's the problem. for write I saw 5537720 on the slower one, 66740 on the prior test.

I'm about to rip out the computer and chuck it into the yard. I've spent so many days and weeks fighting it. one step forward and two steps back. how does one get Mach going? (half kidding)