Spindle Step/Dir servo ramp down before stop on M stop command.

FF1=1 assumes the steps/turn=encoder counts/turn. Is this not the case?

That is the first time I have had that explained! I have not found that definition anywhere..

When you say steps/turn do you mean spindle servo motor steps/turn?
They are different - motor steps = 8000steps/rev. Encoder is 1024 lines=4096 edges/rev. ( which is 4096 encoder counts correct?)
This was setup in the original Pncconf where I did the 'scale' setup for spindle. Spindle RPM does read correctly when running in spindle mode, so encoder is set correctly, as is step pulse rate for that rpm.

So is the C axis re-homed when changing to AXIS mode?

I have nowhere near the ability to do anything like that - I don't even have a sound understanding yet of how what you have implemented actually works Andy.
I don't know and cannot find how the encoder/reset/index mechanism works when switching between modes.
I did post about 5 or 6 posts previous all the parameters I looked at with halmeter, etc, but need guidance in that as I have no idea..
There are also the jog issues I raised in those posts, and I have really tried and searched to find the reason for that too.

Chaps, if this is becoming bothersome and a burden, please say so and I will cease and desist..I cannot fix the current issues and I am not able to simply rewrite a solution in HAL - if I could I would have done so long ago instead of floundering in the wings, trying my best to learn!
Simply beyond my ability with my present knowledge.

Thank You

Have you tried a small FF1(say 1/360)?

I had tried 1 down to 0.1 all of which are unstable, worse with larger values. I now tried 0.05 which is fine, 0,002777 (1/360) which is also fine.

I think I have a config which is largely functional, with some quirks.
I have used Andy's suggestion of limiting pid-c-maxoutput = 5 ( see ini below)
Also increased MAX_VELOCITY /ACCEL values and the C_Axis behaves well - does rapids fast and stable.
This config is 'tame'



There is some remaining odd behaviour still , the implications of which I must evaluate with some real Gcode files.
I believe this all is still to do with how the encoder value is maintained, when it is cleared, when the index is used or not used, etc, which I have not understood yet.

To try and explain briefly (!)
Note: the Spindle, in spindle or C axis more, is always enabled, so immovable - by design.
Note: the tests below are with pid-c-maxoutput = 400, so expect instability.

The FIRST C_axis move after M100 is pot-luck....
After HOME_ALL, in MDI > M100 then G0 C360 : C moves to (say) 360, nice and stable, but on the ODD occasion, reaches setpoint, stops momentarily and then rapidly shoots around another 360 and comes to a stable halt. Thereafter any size move is stable and on position. This is not always repeatable, and is also more prevalent when that first move is large, ie, 180deg or more - happens quite often with a 720deg move.

Then ; scenario 1 - Spindle 'UNWIND' phenomena:
Once in 'stable M100 mode' :
Move C to say 360.
Then press F2 to disable the axes, ie, I can move the spindle by hand now.
Rotate the spindle 3 turns.
F2 to enable spindle again.
Spindle spins rapidly UNWINDING the 3 turns, past the setpoint and oscillates for seconds around the setpoint, finally stopping there.

Now, Scenario 2 - same concept but NO UNWIND:
Again, Once in 'stable M100 mode' :
Move C to say 360.
Then MDI > M101
Then press F2 to disable the axes.
Rotate the spindle 3 turns.
F2 to enable spindle again.
Then MDI>M100
Spindle spins rapidly just past the 'setpoint' ( does NOT unwind the three turns) oscillates for
seconds (less than scenario 1)around the setpoint, finally stopping there.
I emphasized 'setpoint' here as this point is a reference line marked on the spindle pulley, referred to a 'zero' mark on the headstock.
When I do G0 C0, these marks line up - and line up in both above scenarios.

The two behaviours seem at odds, as the encoder tally should be 3 turns in both cases, but in one case the return to zero seems relative to an encoder index, and the other to an encoder absolute count - I have no idea..
As indicated, this behaviour was tested with pid-c-maxoutput = 400 , just to illustrate the difference in behaviour in the two operations - maybe this helps in pinpointing the issue?

I cannot explain any shorter than this!

halscope plots of encoder position and commanded position in the three cases would help to see what is happening

Is it possible to do a full re-home on the C axis when returning to Axis mode?

I wonder if some of the behavior is motor drive related, that is, does the drive "remember"
its position when disabled?