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

What was your old control?

Are you seeing the same performance and accuracy running Linuxcnc open loop (encoder feedback turned off) and P=1000 as you had with your old control?

Is it possible that your servo tuning in the drives and real positional accuracy during moves aren't quite as good as you thought, and when you close the loop in Linuxcnc, now those errors are found?

Do the Halscope plots of the following error and joint velocity feedback, like PCW asked. Post screenshots of the traces.

Old controller was an Adtech 9960... I got a firmware update from them to fix some translation issues and they broke the spindle behavior.. After 3 months of emails back and forth for them to fix that AND the issues with their "unique" implementaiton of Macro-B, I ripped the controller out and am replacing it with LinuxCNC..

As for accuracy, I mean gauge blocks are gauge blocks, if I sweep from oneside to the other of a 4" guage block and I get 101.60 (+/-.002mm) consistently then the DRO isn't the issue. I can also see .001mm movements on a heimer so when 1 tick moves the needle .001m according to the haimer its pretty safe to say that is what is happening..

Will post other details after lunch today.

I do think the issue is in the acceleration tuning... the F-error never climbs.. It oscillates and settles to near zero at the beginning and end of a move...

And I can't seem to find a P value that it doesn't follow error out during accelorations that are more than very gentle.

Surely you aren't going to get great transient response if you simply rely on P alone. The D term is intended to improve the response to fast / step changes, which seems to be the problem here. I've not tuned a servo in LinuxCNC yet but the PID controller function is surely fairly conventional.

I wasn't referring to accuracy in position at rest, but the accuracy while moving. That is what we need to check in Halscope.

If the drives have a lot of lag time in response to movement inputs. it will cause havoc with the following error and PID tuning.

I set my ferror up to 100 and min_ferror up to 10 & my P was set to 150 with an accel of 225mm/s (old controller had an accel set to 600mm/s)... Jog speed was tested 50% of rapid (except the first one, that was 100% rapid). These are the results of jogging the z axis up and down.. (trigger was on a velocity up, so some time I bumped the velocity before giving it a go)...

I should note at a P of 160 I could cause oscillations.

(super close up)






Not sure what happened here but yah SUPER not happy during that jog lol..






For grins I ran at a P of 10..

To me it looks like the drive itself is not well tuned.
That is, even with P=0, the step frequency that LinuxCNC
generates is very close to correct due to FF1=1 and the
fact that the hardware stepgen frequency resolution and accuracy
are quite high.

P should basically just be used to correct for minor
time base differences and various rounding errors

What I am saying is that a P of 10 should be fine
if the drive accurately follows to the pulse train.

So you brought up a good point, and your description about how really this is about managing the time dilation between command and execution caused me to wonder about my controllers tuning... So I set P to 0, and there it is... The servo seems to be off by about 6ms (tested at 1ms thread speed and 750us thread speed and both came back at 6ms delay so I am guessing its not a clock thing between Mesa and computer and just a "cost of the operation" time)

So now I understand the intent of PID tuning is to "race" to make up for 6ms of delay between where the machine "things" things are, and where they actually are..
(Red is follow error, green is commanded velocity, purple is encoded velocity, orange is commanded pos, and blue is encoded pos.

This does beg the question.. is 6ms between command and feedback high, low, expected?

The delay is an issue (and 6 ms is pretty high) do you have all filtering disabled
or minimized in the drive?

What is the time per division on the plot?

That plot was run at 750us servo thread speed so it was 750us/plot..

I ran the same test with 1ms servo thread speed and got the same speed. (fewer steps but resulted in the same 6ms).

Is there anything in LinuxCNC, in the MESA card or in Linux in general that could account for that? I am guessing given its a "round trip" the actual time delay is 3ms..

I will dig through the servo driver manual.. But its a slog given its chinese & the closest thing I have to a translation is the manual run through google translate.

I mean what is the time/division of the halscope plot.
This is independent of the servo thread period
(though the servo thread period does determine the time resolution)