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

More
12 May 2021 17:39 #208637 by PCW
FF1=1 assumes the steps/turn=encoder counts/turn. Is this not the case?

Please Log in or Create an account to join the conversation.

More
12 May 2021 20:08 #208644 by NoJo
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.

Please Log in or Create an account to join the conversation.

More
12 May 2021 21:56 #208662 by andypugh

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


My concern with that idea is that it might mean that the system does not pass through the index and reset to true zero.

I had assumed that no matter how huge the initial error, once the spindle index cleared the error would be no more than half a turn.

If this was my own machine, by now I would be done with "simple" and be writing a custom HAL component. :-/

Please Log in or Create an account to join the conversation.

More
12 May 2021 22:12 #208665 by PCW
So is the C axis re-homed when changing to AXIS mode?

Please Log in or Create an account to join the conversation.

More
12 May 2021 22:35 #208667 by andypugh

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


That was the idea.

Partly based on my first LinuxCNC lathe that would lose counts at max spindle speed, though that really shouldn't be an issue here. I really need to learn to trust encoders :-)

Maybe we should use the orient component after all?

Please Log in or Create an account to join the conversation.

More
12 May 2021 22:41 #208669 by NoJo
If this was my own machine, by now I would be done with "simple" and be writing a custom HAL component. :-/

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

Please Log in or Create an account to join the conversation.

More
13 May 2021 00:14 #208678 by PCW
Have you tried a small FF1(say 1/360)?

Please Log in or Create an account to join the conversation.

More
13 May 2021 09:07 - 13 May 2021 09:13 #208717 by NoJo
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'

[AXIS_C]
MAX_VELOCITY = 1440.0
#was 360
MAX_ACCELERATION = 12000.0
#was 3000
MIN_LIMIT = -3600
MAX_LIMIT = 3600

[JOINT_2]
TYPE = ANGULAR
HOME = 0
FERROR = 1.0
MIN_FERROR = .1
MAX_VELOCITY = 1440
MAX_ACCELERATION = 12000

P =0.1
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 0.0027777
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.05
MAX_OUTPUT = 5
#was 400
MIN_LIMIT = -3600
MAX_LIMIT = 3600
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = 0.0
HOME_LATCH_VEL = 0.0
HOME_SEQUENCE =  1
#******************************************


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!
Last edit: 13 May 2021 09:13 by NoJo.

Please Log in or Create an account to join the conversation.

More
13 May 2021 22:14 #208763 by PCW
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?

Please Log in or Create an account to join the conversation.

More
14 May 2021 13:32 #208802 by andypugh

[code]
I don't know and cannot find how the encoder/reset/index mechanism works when switching between modes.


Typically, when the system wants to synchronise to an encoder it sets the encode.N.index-enable pin high. This signals to the encoder counter that it should zero its output counts next time it sees the encoder index. Then the encoder signals back that is has seen the index by setting the index-enable back to false.
We are using that mechanism to "unwind" all the preceeding (turning mode) revolutions.


Simply beyond my ability with my present knowledge.

But you are learning, and it isn't like I have done this before either, so we are making it up as we go along too.

Can you clarify the current status:
Position mode works OK if the lathe hasn't been used in lathe mode
After using lathe mode, position mode sort-of works, but takes a very long time and many oscillations to settle?
I am not clear if jogging works in position mode. (Do you see the DRO angle change if you jog?)

Please Log in or Create an account to join the conversation.

Time to create page: 0.122 seconds
Powered by Kunena Forum