Unexpected Realtime Delay on task 0....

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)