touch off don't zero the axis

Then something is wrong here.
What I know for sure is that the drive is well tuned as it was tested and tested.

Using the recommendation of PCW we were not able to get a proper working system. Please take a look below for what we had and was working:


and using the PCW recommendation we changed to (only changes are present, the others are the same):

We have immediate following error.
Is the following error in velocity mode, positions or velocity?

Sure, This is expected (you have 1/16.7 of the former P gain so the servo will probably barely follow the commanded position)

you should go through JTs tuning tutorial:

gnipsel.com/linuxcnc/tuning/servo.html

Note the part where you increase P until you get oscillations and then back off
(You want the highest value of P you can get and still remain stable)

FF1 around 1 should be about right

For a velocity mode drive most of the tuning is just forwarding the
velocity command through the PID loop via FF1

(there is no hope of decent results without using FF1)

To resume what happened, as I do not like to leave open threads and it can help others:

Having :
MAX_VELOCITY = 167
MAX_OUTPUT = 167
OUTPUT_SCALE = 167
OUTPUT_MIN_LIMIT = -167
OUTPUT_MAX_LIMIT = 167

or

MAX_VELOCITY = 10
MAX_OUTPUT = 10
OUTPUT_SCALE = 10
OUTPUT_MIN_LIMIT = -10
OUTPUT_MAX_LIMIT = 10

did not made any difference, except the PID had to be retunned (basically what PCW said was correct: if with the settings = 10; the P=1, testing with the settings = 167, the same result was achieved with P=16.7).

Regarding the PID: It was working relative ok with the P=1 (or with P=16.7). No large difference was noticeable.

Running the halscope and tunne the PID, we managed to lower a bit the following error (FF1 ended to be 0.6) and now we have 0.3mm following error peck at acceleration and deceleration. During the rapids the following error gets near zero. Machine is moving at 10m/min. Motors are enough to move easily the axis.
I was expecting a better result, but we could not improve it.

was 1 (or 16.7) the highest gain (P) you could achieve without oscillation?

did you try and tune out the spikes on accel with (a small amount) of FF2?

With all the values at 167, we could increase the P up to 70, starting oscillating near 80. We ended to use around 30, where it oscillates less during fixed velocity, at a cost of a higher setting time.
The FF1 centered the error during movement, and the FF2 changed (but for only a small amount) the fixed error (error is not zero during stop). The title of this thread is the result of the error not be zero when the axis is stopped (in the attachment z_scope.png this is visible). The FF2 did not changed the initial or final spike, and I did a LOT of tests.

Changing the FF3, corrected the "fixed error" but at a high cost of a more jerky movement.

FF2 should only affect accelerated motion (its acceleration feed forward for a PID loop that works on position)
so should only affect the error during the ramp-up and ramp-down phase of your jog

What is FF3?

Like Andy says, the I term can be used to remove that last bit of static error,
but proceed with caution, too much I term will lead to instability.

edit:

One more note: what is the time per division? its clipped off in the halscope images
there seems to be significant delay between the command and the start of motion
this may indicate a tuning issue in the drives (command input filter for example)

PCW wrote:

FF2 should only affect accelerated motion (its acceleration feed forward for a PID loop that works on position)
so should only affect the error during the ramp-up and ramp-down phase of your jog

What is FF3?

My mistake, when I wrote, I was not on the machine and I had to myself that the values started at 1, so FF1 FF2 and FF3. They were really FF0, FF1 and FF2.
With more tunning, we ended up in using:

P=65
I=2.5 (in one axis) the other 0.7
D=0.2
FF1=0.59
FF2=0.004 (in one axis) the other 0.002

This improved the response and now we have max peck of 1/3 in relation with the previous results AND the actual position on the DRO is near the commanded position as the ferror stationary is near 0.001 mm.

PCW wrote:

One more note: what is the time per division? its clipped off in the halscope images
there seems to be significant delay between the command and the start of motion
this may indicate a tuning issue in the drives (command input filter for example)

200mSec.
This was quite a nice tip! I am almost sure that the drive input filter is on. Will check it.

Done!

The input filter on the drive was making a large difference. We had to readjust all, and the ferror now is minimal. We have the graphs attached!
Thank you. Again.