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

I want to make sure I understand what needs to be done in the new hal component.
1- Set a steps_per_rotation value that represents step count per rotation.
2- Monitor the step count (mod) steps_per_rotation ==0 and toggle a simulated output pin
3- Connect this to the encoder index input of 7i92.

I was thinking the following pins:

fb-in in float (360 degrees per turn)
fb-out out float (360 degrees per turn)
fb-turns out float = fb-out/360 (utility to avoid needing a scale component)
index-enable bi-directional bit

No hardware connections would be needed
The fb-out pin follows fb-in until index enable
has been set and fb-in mod 360 has crossed
the 0 point (new fb-in mod 360 < old fb-in mod 360 )
at which point the fb-out pin is offset by the full
number of turns and index-enable is cleared
Since there is no reset, there is no loss of the
original reference position.

Andy Wrote
To an extent you are always masking issues with PID. You have to find a compromise that works in all conditions.
Something that might work would be to set the pid.c.maxoutput to a low value in the M100 script, wait a few seconds, and set it back.

I think that inserting

Code:

halcmd setp pid.c.maxoutput 1 sleep 2 halcmd setp pid.c.maxoutput 10

Might work.

I tried this and it works, but is limited in what it can achieve -

I need to understand how the C axis re-positions itself after it is moved -
In M100 mode, do a G0 C2160 ( 6 full turns).
Then exit - M101
then spin the spindle - say M03 S1000, then stop and re-enable C - M100

The spindle seems to rotate to a zero position ( always the same place - is it the index position of the encoder?), and then rotates the 6 turns to get to the 2160 deg. IAW, does the M100 cause a rotate to index position, then rotate to required (DRO) angle?

The sleep X instruction works well if the required angle, is 'small' - ie, the sleep '2' does not time out before the required angle is reached.
This has ramifications when, eg, milling a large pitch spiral in the side of a shaft - this may be 10-20 turns, whatever.
If you then use spindle mode to say face the shaft end, then go back to C_Axis mode, that is many turns to wind up..
Setting sleep long enough to cope with that means that smaller angles will reach endpoint before sleep times out and
execution of the next Gcode begins before the time out, with odd results I notice...

So not really the way to go I guess.

I also believe the 'the M100 cause a rotate to index position, then rotate to DRO angle' is not appropriate -
I have not seen a C axis based lathe do that in real machining...
Should it not rather do something like this - if the required angle ( the angle the axis was at when we exited via M101)
is say 1280deg, then the angle to move to should be physically 200deg - ie, 1280deg/360 = 3.5556, so there are 3 full turns -
ditch those 3 and we are left with .5556 turns to move = 200deg. That way we never move more than almost 1 full turn to get anywhere.
The actual position ( C axis DRO position ) remains at 1280deg.

PCW wrote: If LinuxCNCs motion comp could be asked to rehome a joint including
the part where it forces its commanded joint position to equal the current
joint feedback position, this would be easier.

This might actually be possible...

Firstly, the machine would probably need to be configured to start up in C-axis mode, and with the C-axis as part of the homing sequence.
The C axis should then be configured in the INI with HOME_USE_INDEX = 1 , HOME_SEARCH_VELOCITY = 0 and HOME_LATCH_VELOCITY = 100 (or some suitable number)
Then connect joint.2.index-enable to the encoder index-enable

Remove the "setp index-enable" line from the M100 script. Instead use:
This will index-home the C axis using the normal LinuxCNC homing sequence. It should start from the current axis position, and so there shouldn't be any step change in command.

NoJo wrote: I also believe the 'the M100 cause a rotate to index position, then rotate to DRO angle' is not appropriate -
I have not seen a C axis based lathe do that in real machining...

In that case I think that the answer is to re-home, as I mentioned in a recent reply (that crossed your last message in the Æther)

andypugh wrote:

NoJo wrote: I also believe the 'the M100 cause a rotate to index position, then rotate to DRO angle' is not appropriate -
I have not seen a C axis based lathe do that in real machining...

In that case I think that the answer is to re-home, as I mentioned in a recent reply (that crossed your last message in the Æther)

This becomes tricky, or at least as I understand it. Would simply re-homing not clear the C_Axis DRO to zero?
If so , that would lose the historical position of the C axis when re-entering C_Axis mode - would that matter?

Firstly, the machine would probably need to be configured to start up in C-axis mode, and with the C-axis as part of the homing sequence.

How do I set this up?