5i25 + 7i85s +....

Nope, that is quite false

With properly tuned PID the velocity mode stepgen is more accurate than the LPT system
(partly because its feed back works on fractions of a step in fact 1/65536s of a step)

If you use encoder feedback you will see larger errors (since your drive and its motion are not perfect)

Its easy to get better than 100 nm absolute pulse train accuracy with the Mesa stepgen at 30000 mm/m
this is impossible with the software stepgen

I was just hoping, you tell me something like that, so im able to get back on Track


I hooked up a Linearscale as Step/Dir source sraight to the Step/dir Imput of my Servodrive.
Then i measured the Scale on Chanel 1 and the Servo drives encoder output on Chanel 2.

I almost wasnt able to move the Scale fast enough, to get a difference of more then 0,2 Degree.
And we talk about 1-2m/sec so 60-120m/min.

This tells me, the hardware PID is unbeliveable fast.
But its useless as long as there are no straight "point to point" pulse informations.

I'm just saying that the PID+velocity stepgen with Mesa hardware gives a
nearly perfect pulse stream. If you are seeing significant position errors
with a local feedback stepgen system, you have a setup issue.


If you are seeing these issues when using a stepgen and encoder feedback, thats
likely a LinuxCNC position loop tuning issue or a drive tuning issue.

Dont get me wrong, im still totally impressed about Linuxcnc!
English is just still not my native language

So i write es short and direct as possible. In the hope, that i dont sound like an 12y old all the time.
This may sound cheeky/rude sometimes.

My tuning atm is capable to manage a acceleration of 1200 with a max following error of about 1mm.
(depending on load)

Just imagine, whats possible if the Drive internal hardware PID gets the control!
But for that you will need a different setup, where Linuxcnc sends coordinates and hardware calculates
the whole movement in Steps.

Look at my Z-Axis and you will understnd my need vor perfeckt movement

If you want to use the drives position PID then just run LinuxCNC/Mesa in stepgen mode
(feedback from the local stepgen counter) and the drive is in full position mode control

At this point you could use the encoder feedback to check how well the drives PID is doing
(by subtracting the commanded position from the feedback position and plotting the result)

You may find the the errors are mainly in the drive...

Thats something i wish to try.

But how does it work?
In Servomode Axis just sends velocitiy/acceleration informations to Mesa and Mesa generates the Steps.
How does Mesa know the correkt Steps. It just listens for the software PIDs information. Or im wrong?

Thats it, when i talked about the difference of Steppermode and Servomode. -> Set of Steps VS regulation.

Yes, it generates steps at the requested rate and there is position feedback
(note that the position feedback is accurate to 1/65536th of a step)

This keeps the actual steps generated equal to the requested position
( to within a _very_ small fraction of a step )

Ok, i better keep that 65536th of a step in mind if i engrave parts for Intel or AMD in the future.

But as i noticed, if i use hm2_5i25.0.stepgen.00.position-fb the PID is still in action.

It shows up, when PID is in a bad setup. -> doesnt reach final position or dfrifting.
But i will test it again. Maybe i missunderstood something.

Btw. i know i talk to an verry experienced goat.
I just need to see it to get a feeling for everything that happens.

If it does not reach the commanded position in local stepgen feedback mode,
there's some kind of LinuxCNC setup error.

If it does not reach the commanded position in encoder closed loop mode,
it could be either LinuxCNC tuning issues, motor drive tuning issues or both

The PID stepgen is a nearly perfect first order control loop so has nearly ideal step generation capabilities
This is because:

1. The rate settability is 32 bits (well somewhat lower because the top bits are typically not used)
2. The rate is updated 1000 or more times a second based on fine position feedback
3. There is very little delay between reading the current position and updating the velocity to intersect the next waypoint
( This delay can be compensated for if desired with FF2 )

Note that a encoder feedback system will show _much_ larger errors since
there are significant following errors in the drive/motor/load