Step/Dir servos + Encoders = follow errors... and so much pain.....

Yah the plot said it was 2000 data points at 1.33khz which is 750us. (2000 data points because I am tracking 5 things).

What I am asking is what halscope says is the time per division
This is what determines the horizontal scale.

That is, if the acceleration is the same as your previous plots,
this looks like 1 second per division so the delay between
commanded and actual velocity is closer to 30 ms.

His previous plots say a half second/div. (500ms/div.)

Most likely the old control ran open loop and just accepted the delay (and assumed the position loop was closed in the drive). But if you are going to try to close the position loop in Linuxcnc you are going to have to improve that reaction time. Like Peter said check the drive settings for input filters that can be turned off, and try to improve tuning if possible.

The slope of the velocity in the last plot is about double of the 500 ms/division plots
so assuming the acceleration is the same, the last plot is 1 second per division.

Ok so 4th time to write this.. and I am not going through all the trouble of reposting the actual hal log data again..

That being said, depending on the run, while hal scope says that it is using 1.00mSec per sample there are between 5 and 7 rows of data between the joint's first commanded position and the encoder first measurement of a position. So from a dead stop, then a commanded movement the data is command pos changes on say row 400, then row 401,402,403,404,405 and 406 the encoder doesn't show any movement (while the command pos keeps changing), then on row 407 the encoder starts to show movement.... Because sometimes that is 5, 6 or 7 rows then that tells me the lag for the round trip is ~6ms (+/-1ms I guess).

Now I went through every setting in my manual that had an ms unit, ns unit, or had the word "filter" in it... many of them impacted performance (I definitely found my servo's PID settings) ... none of them changed that ~6ms delay from command to measurement.

Todd,
The old controller did not have its own pid.. It did claim to be closed loop (because it used the servo encoders for the DRO) and it definetly used the servo's Z-pulse to home the machine.. But to be honest chinese controllers are often times pretty sketchy on their software... Also being a realtime controller it may not have had the kind of latency issues I am observing given they were probably able to send out pulses in real time rather than send velocity commands ones every servo cycle to a sub-controller...

Just for grins I am going to move my configuration over to the new official distro of Linuxcnc and see if its something to do with the RT build.. I am running off a Mint based distro and maybe the official 2.8 package doesn't like how this distro was built.

Thanks
Josh

The last plot appears to have been plotted at 1 second per division.
The delay is about 1/3 of a minor division (100 ms) so closer to 30 ms

The whole chart isn’t more than 2 seconds of data.

Either way, the actual raw log file opened in Libra Calc shows 5 ~ 7 rows of data between start of command and encoder measurement. Given each row is 1ms. I am pretty comfortable believing the raw data isn’t misrepresenting what 10 rows of data at 1ms sampling period means...

Any ideas where 6ms could be coming from. Is there a way to measure the lag between the Mesa card and LinuxCNC to rule out a crappy network card or something?

If the acceleration is the same in the 500 ms/div plots and the last plot, the time/division in the last plot is close to 1 second

There is no way to have 6 ms of network delay at a 1 ms servo thread (every packet would time out and LinuxCNC would report a read data failure

Its not really 6ms from command to action.. its 6ms from command to measured change... (round trip)..

its probably ~3ms maybe 4ms because you have at least 1ms lag from LinuxCNC command queued to being sent to the mesa card, then there is ~1ms from recorded measure change in mesa to that data making it back into linuxcnc's brains from the servo loop...

But even then the result is that the PID for linux CNC is chasing a delay and that is probably the root of my problem..

.. now to figure out where I can "find" 2 or 3ms

There is no command queueing.

The delay from reading the encoders to writing a new stepgen velocity is typically
less than 300 usec. You can verify this by checking the delay from commanded
position to stepgen feedback position in open loop mode. This has identical
communication delays to closed loop, the only difference being that the position
feedback is taken from the stepgen position feedback register on the FPGA card
not the encoder register on the FPGA card.