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

You can probably calm this down by using pid.c.maxoutput, set that to 400 (it wants to be just a bit more than the max velocity in C axis mode).

Unfortunately that made no difference -
I tried from 0 to 10000 - see below - with:
Home all. M100 G01 C360 F10000. Goes to 360deg fine. M101 G03 S500, then M05.
Then M100, and the C axis tries to go back to the 360degree pos, but oscillates, quite fast, 3 or 4 times, slowing down and getting there.
The rate of oscillation and time to dampen does not change for any values tried as below

That line [setp pid.c.maxoutput [JOINT_2]MAX_OUTPUT] : is present in the HAL file.

HALScope plot of -Pid.c.command and Pid.c.feedback - attached
Command is orange, feedback is blue, trigger on pid-c-feedback
X scale in millisec
Setup:
Home all > M100 > G0 C360 > M101 > M03 S500 - spin for 5 sec or so > M05 .
Then M100.
C_axis oscillates trying to find the 360deg position.
The command is set at 360,since C was at 360 before the M101. It looks like when the mode is entered (M100) , since the command is at a big number already, its seen as a big step change.

Also did a HALscope capture of Pid.c.command , Pid.c.feedback and Pid.c.coutput.
not including a plot here - output oscillates as does feedback, but 180deg out of phase

Your suggestion :

You can probably calm this down by using pid.c.maxoutput, set that to 400

I tried that in the HAL file. This calms it down, but is not a solution...Value of 50 is still oscillates the same. Value of 5 works, but all C movement rates are severely curtailed - F10000 is the same as F1000...

In addition , with maxerror = 5 , the sequence.
Home all > M100 > G0 C360 > M101 > M03 S500 - spin for 5 sec or so > M05 , then M100 :
Before the final M100, the spindle is in unknown position, the M100 then causes it to go to 360deg ( which is the command value),
but it rotates to that position, say clockwise, then goes anticlock again all the way to that position and stops, stable.
Increase maxerror to 50, and it repeats the to-and-fro a few times, as per plot.

The above all still related to the oscillation problem when switch between C and Spindle modes.

I also have an issue with jogging, which is probably also related to the switch between modes.
I have tried hard to find the issue, but..
I have a 7i73 module with jog wheels and jog pushbuttons attached - All works.
The jog wheels are one for Z, and one selected by a pushbutton for either X or C. 4 buttons jog X and Z plus and minus.
I have the AXIS (GUI) setup with a HOMING_SEQUENCE in ini file, so HOME ALL Button is on AXIS screen.
I also have a hardware Button for HOME _ALL

The problem is thus:
START> HOME ALL ( on AXIS screen button) - all axes home fine - C does not move as it is not enabled ( by M100)
All jog wheels and pushbuttons work at this stage - jogging is fine.
Then : MDI > M100 : Now jogging does not work any more - no handwheels or buttons.
Then if I go to the Jog button on the AXIS main menu, and just jog X or z a touch, the jogged axis jogs OK. And after that the jog wheels and buttons work fine with ALL axes. ( M100 is still active now)
Then if in MDI I do M101, then the Jog wheels and buttons no longer work, and if I jog x/z in the AXIS main menu again, the axis jogs and the wheels and buttons jog X and Z fine again.

I also found - Using the HOME ALL AXIS menu screen button, homes all - If I select it again after all homed, a message pops up - 'axes already homed do you wish to home again', etc. If however I do the FIRST HOME_ALL with my hardware pushbutton, all axes home ok, and if I push that button again, instead of the message above, I get a joint error - 'must be in joint mode to home'

This may help to understand the issue?

On the jog issue, I used halmeter to look at many parameters - not knowing where to look at all, but looking at items that seemed pertinent - Axis-homed, joint-selected, and a dozen more...to see if there was a change or difference between after HOME_ALL and after M100 - I did not find any changes in the true/false status, etc. But I am sure I was probably not looking at the correct parameters...

So, on both the oscillation and the jog issues I am a at a loss, and I don't think anyone other than you, Andy, will be able to chip in!
This lathe is becoming rather complex - I am learning a lot from you, but slowly..

Thank You
Joe

Current HAL and ini related to above post attached

On the oscillation, you are not going to have much luck tuning the C axis
without using FF1 (FF1 should be 1 if the scaling is right)

Thanks for commenting PCW..
I suspect however it is not that 'simple'....
There is a lot of lead-up in the preceding half dozen or so posts which you would need to read to understand what the problem is.
The C axis IS in fact currently 'well' tuned - when in C-axis mode ( M100) , any rotational move is very well controlled, totally stable, no overshoot, nice deadband of 0,05deg and rock solid. So the loop is fine - ONLY with FF1=0

here is probably a summary of the path getting to this status..

Initially any setting of Pgain between 3 and 0.001 was still unstable, with P>1 being very bad. Small changes in angle <5deg were 'reasonably' quick and almost stable, so this had to be related to the magnitude of the position change.
Looking at how the PID controller output is structured, the Feedforward term (FF1) would appear to be the culprit since it is multiplied by the command derivative - this forms part of the PID output, and since the change in command is large and instantaneous ( say from 0deg to 360deg), the contribution could be excessive.

I set FF1 = 0 to verify, and it works...the angular changes (G0 C0, G0 C360, etc) are rapid, stable, with no discernable overshoot at all.
There was a slight wobble around setpoint, but Deadband was set to 0.0 - and so since I have a 4096 ppr encoder = 0.088deg/encoder line, I set Deadband to 0.05 and now it is dead still around setpoint.

The problem is not while in M100, but , after Homing all axes and then enabling C and moving it to a setpoint and then moving C off that position in spindle mode, doing some machining ( that is, M101) mode in this setup, and then activating the C axis with M100 again - the system moves the C axis back to the last C Axis position, and this move is unstable - you would need to read the previous posts to follow the reasoning and attempted solutions - it does not really have anything to do with 'tuning' the PID - remember that the spindle/C axis motor is an internally closed loop step/dir servo.

This is another exerpt from a previous post..

It is as though there are some PID parameters not being used in that initial move to setpoint angle? ( when setpoint and current position differ and we do M100 - a step change)
( Andy responded with some ideas here)
Yes, that's right. When you switch to C-mode the position-feedback to the PID will be (for example) a million degrees, and the PID output will be correspondingly very high. This _is_ a step change in input to the PID.
Then the index-enable does it's thing and the position-feedback becomes zero, which is a second step-input.

You can probably calm this down by using pid.c.maxoutput, set that to 400 (it wants to be just a bit more than the max velocity in C axis mode).

It's 'those' step changes that are the problem, and the loop cannot be 'tuned' to manage those situations - a different approach is needed for that initial C_axis activation where the current position and setpoint differ greatly, ie, a step change. For that situation, in my initial tests, I had FF1=1 and the spindle went berserk during that switch to C mode ( M100)...
And what that approach might be is somewhat more complicated than I can manage!

FF1 is required for decent performance of a velocity mode control loop
Fixing the initial move when returning to C mode may require different
PID tuning but that should not compromise normal C mode operation.

You should be able to reduce the initial error by making sure that C is at 0 before
switching to spindle mode, clearing the encoder before switching back to
C mode and then re-homing to index.

The step when index occurs should be masked by the PID (so FF1 is not relevant)

It is difficult for me to try explain - I am an amateur wrt HAl and the deeper functions Andy is implementing, so I cannot comment intelligently wrt the way the functions are implemented. My posts are far to verbose in my attempt at getting the detail across, and then the reader is overwhelmed by my guff and loses the essence of my problem...or loses interest.

I am not inexpert in PID control loops , however , but in the aeronautical world - flight control and autopilot systems for military jets and large UAV's - PID's are PID's no matter what application, so I am no out of my depth there.

The issue here is not really a PID problem.
As Andy said :

This method works here largely because you are using step/dir drives with an internal position loop. It wouldn't generally work so well for a VFD or similar.

The result is a fully functioning, stable, well tuned C axis. It positions well, fast and is critically damped.
it does NOT work with any FF1 of note...I suspect because the loop is closed inside the servo..

The issue is that there is a step change ( and this is how I see it - this is NOT a PID issue, but one of how the function is implemented)
resulting from the enable of the C axis while there is a big delta between actual and required angle. This feeds the C_Axis PID control loop which is not tuned for such step changes and will never see such changes while it is enabled and working normally.

Why I said this implementation may need adapting is because the homing of the C axis is not to the encoder index - the current mechanical position of the axis is taken as home = 0 : everything is reference to that thereafter, which is acceptable.

The C axis does not move mechanically on initial HOME, since Z and X are active, and M100 is inactive, so the axis will not move.
But the home makes the Caxis DRO=00, and the axis takes that position as 0 as well.
A 'step change' in commanded angle in a G0 C360 ( say from 0deg), for example goes through the PID and is well controlled and stable, well damped and fast.

I fail to understanding why that works, and why the 'step change' during a M100 selection with the commanded and actual angles different, by a similar amount, does not work - it is obviously because the PID is not initialised in the same manner, or something, but I cannot see how - I do not fully understand Andy's C axis implementation , obviously!

The step generator is running in velocity mode therefore FF1=1 is required for optimum performance, this is not in question. The best solution would be to eliminate the step position commands (or rather step differences in commanded and feedback positions)

Do you clear the encoder before changing to C axis mode?

A G0 command is not a step change but obeys the motion acceleration and velocity constraints

The step generator is running in velocity mode therefore FF1=1 is required for optimum performance, this is not in question. The best solution would be to eliminate the step position commands (or rather step differences in commanded and feedback positions)

I can post a video if you wish of the operation with FF1=0 and FF1>0 - I am quite sure of this...ANY positive value for FF1 and the axis, in normal C axis movements, ie, G0 Cxx or G01 Cxx Fxxx becomes increasingly unstable.

If FF1=1 the axis is violently unstable - with halmeter of Pid-command and Pid-feedback not showing signs of converging- at least not in the 5 second realm! With FF1=1, there is no value of Pgain that even begins to tame the axis... reducing FF1 and things calm down - with FF1=0 there is no more instability, unless you make Pgain to high of course.
Pgain is presently 0.1 - make it 1 and it is VERY unstable.
If FF1 must be = 1 , then there is something else lurking in the implementation that is a problem...

Do you clear the encoder before changing to C axis mode?

I don't know if the encoder is cleared - I think my understanding of how the implementation works is inadequate, and so my explanation as well.

After power on, HOMING the axis accepts the current axis position as zero( DRO=00) - I presume that implies the current encoder count, not the encoder index position, etc. It does not first move the axis to the encoder index position - I presume it just takes the encoder value as the homeposition.

Then with M100 enable the axis, and since the current position and commanded position are the same ( zero), there is no movement.
Now a G0 C270 moves the axis in a controlled manner to 270deg. Moving to any other angle is similarly well controlled.
Then a M101, and M03 S1000 ( for example) - moves the spindle ( and encoder) elsewhere, since the spindle is spinning at 1000rpm.
Then M05 - stop spindle.
NOW - the spindle is not where we were before at the last G0 Cxx move, so an M100 tries to get the spindle back to that last position -NOT the encoder index position with a move to the last position. IAW, the spindle does not do a 'home to index' and then rotate to required angle - it just moves to the required angle directly, but oscillates...If the delta is small, maybe less than 10degrees, the movement is gentle, with overshoot.
So I do not know how that is achieved - it is one of the things I wished to ask Andy to explain in depth..somehow the present encoder count and last encoder count before M101 must be kept and subtracted, or something...??