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

andypugh wrote:

NoJo wrote:

HOME ALL > C rotates to index, stops momentarily ,shoots past, oscillates, converges to index and stops. Axes all show home icon

That was better before, I think?

No - that has remained unchanged - I tamed it down in previous tests by reducing MAX_OUTPUT to below 5 in the ini - but the inherent issue remains.

M101 > Jog works on all axes, C does not rotate but DRO changes.
To be expected, really. Add "setp axis.c.jog-enable 0" to M101 and "setp axis.c.jog-enable 1" to M100 to fix that.

Just to be sure I explained correctly the issue - When executing M101, I understand we should disable the C Axis mode, and are in 'normal' spindle mode, ie, M03 S1000 will now run the spindle @ 1000rpm as normal, so the C axis SHOULD NOT jog in M101 -
What do those added lines do? Presume the '0' disables and the '1' enables - but what is enabled/disabled? The jogging of the physical axis, or the DRO? Or both?
I would have thought the intent in M101 is that the C axis is simply disabled - no jogging of the axis or the DRO,ie, sort of a basic 2 axis lathe..

I may also not have been clear on 'Not jogging anymore' issue - NONE of the Axes physically jog anymore when a M100 is executed, so will the the line setp axis.c.jog-enable 0/1 enable jogging of the x and z axes?

M100 > C does not home but rotates to DRO setting = 270deg, rotate is very fast and oscillates about 270deg, to standstill.
That's odd.
It is starting to look like my idea for a simple way to do this wasn't very good.
I think you had something usable about 2 iterations ago, and it has got worse since?

No, not really - since where the C axis began to 'work', the oscillation has been present when entering M100.
I did not fix that, merely tamed it by limiting the PID MAX_OUTPUT, but
I still don't understand the reason for the oscillation - it is fast, so not good mechanically, and has been there from the first iterations where the C axis started to work - must be to do with the PID being unhappy with entry conditions - If we know that we should be able to fix that?
But a major issue is homing with M100 - that should work..I think one cause of the oscillation will go away if homing works -
If the axis homes , and the DRO is cleared, when the axis is enabled there is no delta between position and DRO.

The oscillation mentioned at the start of this post - after HOME-ALL is a mystery, but I am sure it is related to the PID error, and the time delay in that M100 script you last posted - when the delays time out, the PID output jumps somehow?

Also related to the oscillation - is there a possibility of error due to the index pulse width ( to short to detect 'sometimes'), or the sense of the pulse ( rising edge/falling edge)? - sort of detecting the index, going past, etc? And the MESA counters doing odd things as a result?

Not sure we should give up yet ( unless you have had enough!) - or have ideas regarding a better way..!

I am mixing to many things in a verbose post every time and getting us both in a twist.

In summary, there are presently 3 issues:

1. Jogging-
   Jogging works after HOME ALL, machine is in M100 mode after HOME ALL
   Then M101 - Jog XZ works, Jog C increments the DRO, C axis does not move. DRO should not increment (?)
   Then M100 - JOG XZC no longer works.
   Then M101 - Jog XZ works, Jog C increments the DRO, C axis does not move, as above.
   This all with lines added > setp axis.c.jog-enable 0" to M101 and "setp axis.c.jog-enable 1" to M100
2. Homing-
   HOME ALL works - all axes go to home, C to index - BUT C goes past almost a 1/2 turn and rapidly back to index.
   Thereafter, jogging as as described above.
   Then, do M101 and jog C ( only DRO changes now, C disabled) to 180deg
   Then do M100 - after a +-2sec delay, C moves to 180deg - NOT Home index position, ie, does not 'Home'
3. Oscillations-
   If I make MAX_OUTPUT = 2 or less >
   All Gx Cxxx Moves are clean, stable, no oscillations
   The scenario in Homing above ( last two lines) caused the C axis to move to 180deg, instead of homing it, BUT that move is stable, no oscillation. So all moves are stable and clean.
   HOWEVER...The HOME ALL always does as described above - C goes to index, past +-1/2 turn, and rapidly back to index

NONE of the Axes physically jog anymore when a M100 is executed, so will the the line setp axis.c.jog-enable 0/1 enable jogging of the x and z axes?

M100 puts the system in joint mode to home the C axis. When the C-axis is homed the system _should_ go back in to "teleop" mode. Maybe we do need to unhome the C axis to actually get that to happen?

Your Call...

The PID enables with a very large error, and so commands a very high velocity. Limiting PID.c.maxerror should be able to fix that without affecting normal moves, but you seem to have said that it didn't?

See 3 above...

Try running in spindle mode for a little while, then turn the machine off (F2) and then on again, and then try M100.

This was interesting:
I set MAX_OUTPUT = 2
HOME ALL ( behaviour as in 2 above)
M101, M03 S500 ( run for maybe 5sec), then M05, F2, wait a while....F2, then M100
about a 2sec delay after M100, then the C axis unwinds ALL the turns it did in the M03 S500 period - 5sec of turns @ 500rpm..
I did not look at the C DRO value after the M05, so not sure what that was or if it had changed to a big number..

andypugh wrote:

NoJo wrote:

The PID enables with a very large error, and so commands a very high velocity. Limiting PID.c.maxerror should be able to fix that without affecting normal moves, but you seem to have said that it didn't?

See 3 above...

Ah, no, there is a difference between limiting the max-error (on the input to the PID) and the max-output.

You could limit max-error to (say) 5 (or 1, or less) degrees, and then a 10-turn (ie 3600 degree) error would look like a 5 degree error. So in theory you would retain all the jogging / moving responsiveness but it would not go crazy on huge offsets.

Ok,.....
I was kind of just doing as you said..abt 8 or so posts ago....When the oscillations were first observed,

'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.'...etc,etc

Your suggestion then was:

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

I will try pid.c.maxerror in the morning.

I will try pid.c.maxerror in the morning.

Set pid.c.maxerror to 10, pid.c.maxoutput to 400

All C moves are stable, EXCEPT for the usual HOME_ALL.
I Halscoped these during a HOME_ALL:
pid.c.command
pid.c.feedback
pid.c.error

and pid.c.maxerror, pid.c.maxoutput - these two remain zero during the home_all
Attached a photo of the 'scope..

I tried 0.1 in maxerror - HOME ALL did as usual, C goes to index, then still goes past -+ 1/2 turn, then goes back to index, as usual, but this time VERY slowly, like 1 rev / day...
A 1 in maxerror - same behaviour but return to index is faster - 1 rev /hour.

Then, doing what you asked to first try -

HOME ALL homes X, and then would normally do Z and C, but dies with a joint 2 following error - does not home.
Ignoring HOME ALL on start up, I then activated the spindle on the AXIS Manual screen - this gave Joint 2 following error right away.

Please check the HAL section where I added those lines - some lines appear already, etc..Maybe I messed up.

HAL:

Ok. You would know, I certainly don't!

I can only thank you for all the time you spent on this, and on dragging me along, and apologise for having wasted your time!

Thanks Andy