- Configuring LinuxCNC
- Advanced Configuration
- Spindle Step/Dir servo ramp down before stop on M stop command.
Spindle Step/Dir servo ramp down before stop on M stop command.
26 May 2021 21:09 #210395
by andypugh
The step scale needs to be right to get the correct RPM, but the position is closed-loop to the encoder.
But, make the step-scale correct first, as it will affect all PID tuning and speed/accel limits.
Replied by andypugh on topic Spindle Step/Dir servo ramp down before stop on M stop command.
I don't understand how it works at the moment with it @ 1600 - the angular position the C axis moves to is correct ( except for the 180.547deg issue - will verify tomorrow) so somehow that step_scale is not used - presumably because the C axis position is from the encoder? Is it unused here?
The step scale needs to be right to get the correct RPM, but the position is closed-loop to the encoder.
But, make the step-scale correct first, as it will affect all PID tuning and speed/accel limits.
The following user(s) said Thank You: NoJo
Please Log in or Create an account to join the conversation.
27 May 2021 09:37 - 27 May 2021 15:50 #210434
by NoJo
Replied by NoJo on topic Spindle Step/Dir servo ramp down before stop on M stop command.
Step_scale @ 8000.
played with Velocities and Accelerations - Seems the best I can get it currently.
Still fighting Homing..
Home Issue-1
HOME ( start with C physically at abt 45deg )
> XZ OK as usual
> C goes to index slowly, reaches index then VERY FAST past and all way around, past index again, then stops, rotates the other way, slowly, back to index and stops.
Changing stepgen_Velocity and Acceleration changes this behaviour, but it is never clean - does the same type of movements, but very slow if values are small ( 10 or less) or faster as values are made larger.
HALscope of one of the home cycles attached - not sure if I recorded the correct parameters.
The vertical spike is where the first cross of index occurs
Home Issue-2
HOME ( as above)
XZ ok, C homes with above oscillation.
XZ DRO @ HOME position + ini offsets.
C DRO = 0
Then MDI M03 S100 , then M05 stop spindle.
C then goes to the C DRO position, very rapidly ( bit too rapid for chuck inertia, etc..) but VERY stable, single move, no overshoot, every time..
Now hit F2 and move spindle manually to say 260deg ( simulates disabling spindle to turn chuck to insert chuck key etc)]
Then hit F2 again to enable
C stays where it is, since DRO is where it is.
NOW do HOME ALL again...
C does slow move to just past index, reverses at speed, and stops suddenly abt 5-10deg other side of index.
Spindle is disabled now, Joint 2 following error, and C DRO reads -11179deg...
The system responds well when I HOME ALL after startup, do MDI M03 S1000, M05.
Always goes to C DRO position very cleanly with no overshoot, but very rapidly.
Then the C DRO Position after a C move:
still reads incorrectly after a C move -
HOME ALL then G0 C180 ends up 180.527deg ( sorry, previously I said 180.547 - typo)
There is no home offset I could find for C...HOME in [Joint_2] = 0
EDIT - Also checked @ various angles:
@45 shows 45.088
@180 shows 180.527
@360 shows 360.967
@720 shows 722.021
def not an offset - almost looks like a rounding issue somewhere.
played with Velocities and Accelerations - Seems the best I can get it currently.
Still fighting Homing..
Home Issue-1
HOME ( start with C physically at abt 45deg )
> XZ OK as usual
> C goes to index slowly, reaches index then VERY FAST past and all way around, past index again, then stops, rotates the other way, slowly, back to index and stops.
Changing stepgen_Velocity and Acceleration changes this behaviour, but it is never clean - does the same type of movements, but very slow if values are small ( 10 or less) or faster as values are made larger.
HALscope of one of the home cycles attached - not sure if I recorded the correct parameters.
The vertical spike is where the first cross of index occurs
Home Issue-2
HOME ( as above)
XZ ok, C homes with above oscillation.
XZ DRO @ HOME position + ini offsets.
C DRO = 0
Then MDI M03 S100 , then M05 stop spindle.
C then goes to the C DRO position, very rapidly ( bit too rapid for chuck inertia, etc..) but VERY stable, single move, no overshoot, every time..
Now hit F2 and move spindle manually to say 260deg ( simulates disabling spindle to turn chuck to insert chuck key etc)]
Then hit F2 again to enable
C stays where it is, since DRO is where it is.
NOW do HOME ALL again...
C does slow move to just past index, reverses at speed, and stops suddenly abt 5-10deg other side of index.
Spindle is disabled now, Joint 2 following error, and C DRO reads -11179deg...
The system responds well when I HOME ALL after startup, do MDI M03 S1000, M05.
Always goes to C DRO position very cleanly with no overshoot, but very rapidly.
Then the C DRO Position after a C move:
still reads incorrectly after a C move -
HOME ALL then G0 C180 ends up 180.527deg ( sorry, previously I said 180.547 - typo)
There is no home offset I could find for C...HOME in [Joint_2] = 0
EDIT - Also checked @ various angles:
@45 shows 45.088
@180 shows 180.527
@360 shows 360.967
@720 shows 722.021
def not an offset - almost looks like a rounding issue somewhere.
Last edit: 27 May 2021 15:50 by NoJo. Reason: Re-checked C axis angular error @ various angles
Please Log in or Create an account to join the conversation.
27 May 2021 22:13 #210475
by andypugh
Replied by andypugh on topic Spindle Step/Dir servo ramp down before stop on M stop command.
There is an obvious error here in caxis.comp
offset needs to be converted to degrees, so it should probably beThough I am not sure that is the problem.
It might be the case that the caxis component needs to watch index-enable too, and do something clever. But I will need to do more experimentation to find out, and it's a bit late tonight.
case 0: // C-axis mode
if (spindle_on){
state = 1;
}
pid_enable = 1;
spindle_velocity_out = pid_in;
position_cmd_out = (spindle_revs - offset) + position_cmd_in;
position_fb_out = (spindle_revs - offset) * 360;
break;offset needs to be converted to degrees, so it should probably be
position_cmd_out = position_cmd_in - (offset * 360 );It might be the case that the caxis component needs to watch index-enable too, and do something clever. But I will need to do more experimentation to find out, and it's a bit late tonight.
Please Log in or Create an account to join the conversation.
30 May 2021 15:11 #210682
by andypugh
Replied by andypugh on topic Spindle Step/Dir servo ramp down before stop on M stop command.
After a little more tinkering.
1) The return to set position after the spindle stops is best controlled by limiting the pid.c.maxoutput. That only needs to be as large as the max jog velocity, with perhaps a hint of overhead.
2) The caxis.comp should not try to manipulate both command and feedback, that is just asking for trouble. Delete the commented lines and replace with the uncommented one3) Things go a bit haywire after re-homing in the existing comp. Replace with the attached and re-run halcompile.
1) The return to set position after the spindle stops is best controlled by limiting the pid.c.maxoutput. That only needs to be as large as the max jog velocity, with perhaps a hint of overhead.
2) The caxis.comp should not try to manipulate both command and feedback, that is just asking for trouble. Delete the commented lines and replace with the uncommented one
net angle-cmd joint.2.motor-pos-cmd pid.c.command
#net angle-cmd joint.2.motor-pos-cmd caxis.0.position-cmd-in
#net c-pos-cmd caxis.0.position-cmd-out pid.c.command
The following user(s) said Thank You: NoJo
Please Log in or Create an account to join the conversation.
30 May 2021 18:30 #210712
by NoJo
Replied by NoJo on topic Spindle Step/Dir servo ramp down before stop on M stop command.
Thanks for the update Andy.
I have tested it and bar the initial Homing of C it is all very well behaved.
The initial home is still a back and forth affair, as before, no change. I have slowed down the back and forth by setting [Joint_2]
MAX_OUTPUT = 2.0
Anything more and the oscillation worsens. 20 is scary...
What is max jog velocity?
I presume the pid.c.maxoutput you indicate is the MAX_OUTPUT I mention above? If so, being picky, the return to C DRO position after a spindle run is still very quick with MAX_OUTPUT = 1.0. In fact, that return does not seem to change with MAX_OUTPUT values from 2 to 20...Am i fiddling with the wrong parameter?
The lathe has a 5C spindle currently, ie, the 5C collet taper is in the spindle itself, so the spindle has very little inertial mass. For a number of reasons ( ATC/headstock crash clash, etc) I am changing this to a 5C collet Chuck assy - this will add a fair bit of spinning mass and the rapid return to DRO position may be problematic.
Otherwise, the C DRO readings are correct, the return to C DRO position is fast, but very clean with no overshoot, etc.
A G0 Cxxx command is likewise clean and stable, but VERY slow - maybe 8-10sec for 360deg -
Is that due to MAX_OUTPUT = 2 ?
In the ini below - Is it MAX_VELOCITY that limits the G0 Cxxx rate?
What is the significance of STEPGEN_MAXVEL to the G- Cxxx rate?
Also, In this setup, if I increase STEPGEN_MAXVEL to > 80, I get an error -
stepgen.02.maxvel is to big for current step timings and position-scale setting..
Why is that? In spindle mode the step pulses for 2500RPM are way faster than in C axis mode, etc, so I don't understand why it should be to 'big' in this mode.
I am really grateful for your help in this Andy - it is looking good! Maybe you are close to done, but for me it begins and I would appreciate if I can continue to bother you a while longer - I would like to understand better how this all works and have a good grasp, but there are still some things that elude me! Some of the issues I have queried above..
Thank You!
I have tested it and bar the initial Homing of C it is all very well behaved.
The initial home is still a back and forth affair, as before, no change. I have slowed down the back and forth by setting [Joint_2]
MAX_OUTPUT = 2.0
Anything more and the oscillation worsens. 20 is scary...
1) The return to set position after the spindle stops is best controlled by limiting the pid.c.maxoutput. That only needs to be as large as the max jog velocity, with perhaps a hint of overhead.
What is max jog velocity?
I presume the pid.c.maxoutput you indicate is the MAX_OUTPUT I mention above? If so, being picky, the return to C DRO position after a spindle run is still very quick with MAX_OUTPUT = 1.0. In fact, that return does not seem to change with MAX_OUTPUT values from 2 to 20...Am i fiddling with the wrong parameter?
The lathe has a 5C spindle currently, ie, the 5C collet taper is in the spindle itself, so the spindle has very little inertial mass. For a number of reasons ( ATC/headstock crash clash, etc) I am changing this to a 5C collet Chuck assy - this will add a fair bit of spinning mass and the rapid return to DRO position may be problematic.
Otherwise, the C DRO readings are correct, the return to C DRO position is fast, but very clean with no overshoot, etc.
A G0 Cxxx command is likewise clean and stable, but VERY slow - maybe 8-10sec for 360deg -
Is that due to MAX_OUTPUT = 2 ?
In the ini below - Is it MAX_VELOCITY that limits the G0 Cxxx rate?
What is the significance of STEPGEN_MAXVEL to the G- Cxxx rate?
Also, In this setup, if I increase STEPGEN_MAXVEL to > 80, I get an error -
stepgen.02.maxvel is to big for current step timings and position-scale setting..
Why is that? In spindle mode the step pulses for 2500RPM are way faster than in C axis mode, etc, so I don't understand why it should be to 'big' in this mode.
[JOINT_2]
TYPE = ANGULAR
HOME = 0
FERROR = 1000
MIN_FERROR = 1000
MAX_VELOCITY = 120
#120deg per sec
MAX_ACCELERATION = 200
STEPGEN_MAXVEL = 50
#@200 stepgen velocity to big > error
STEPGEN_MAXACCEL = 100
#was 300 for stepgen_vel=200
P = 0.1
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 0.0
# see joe ini
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.05
MAX_OUTPUT = 2.0
#Was 0.0
# these are in nanoseconds
DIRSETUP = 5000
DIRHOLD = 5000
STEPLEN = 1000
STEPSPACE = 1000
STEP_SCALE = 8000
MIN_LIMIT = -36000
MAX_LIMIT = 36000
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL =0
HOME_LATCH_VEL = 100
HOME_USE_INDEX = 1
HOME_SEQUENCE = 1I am really grateful for your help in this Andy - it is looking good! Maybe you are close to done, but for me it begins and I would appreciate if I can continue to bother you a while longer - I would like to understand better how this all works and have a good grasp, but there are still some things that elude me! Some of the issues I have queried above..
Thank You!
Please Log in or Create an account to join the conversation.
30 May 2021 20:56 #210738
by andypugh
So, open a halmeter and look at pid.c.output, then see what value it has during max-speed jogs and G0 moves.
Then you can set the pid.c.maxoutput to just a bit more than the maximum you see there. Then you still have all the responsiveness for jogs and G0, but don't have far-too-fast moves when the index resets.
Now, it would be _possible_ for the caxis component to "lie" about the feedback position so that the final move to home was controlled, but I think that is an over-complication.
[code]setp pid.c.maxoutput [JOINT_2]MAX_OUTPUT
Which MAX_OUTPUT are you changing? It needs to be the one in the [JOINT_2] section. And it might need to be less than 2 (2 revs per second?)
Replied by andypugh on topic Spindle Step/Dir servo ramp down before stop on M stop command.
Simplistically it is the max that the angular axis slider will go to. But what you need is the PID output that still allows full-speed C axis movement, but not stupid-fast C-axis movement.What is max jog velocity?
So, open a halmeter and look at pid.c.output, then see what value it has during max-speed jogs and G0 moves.
Then you can set the pid.c.maxoutput to just a bit more than the maximum you see there. Then you still have all the responsiveness for jogs and G0, but don't have far-too-fast moves when the index resets.
Now, it would be _possible_ for the caxis component to "lie" about the feedback position so that the final move to home was controlled, but I think that is an over-complication.
Possibly. The HAL will tell you.I presume the pid.c.maxoutput you indicate is the MAX_OUTPUT I mention above? If so, being picky, the return to C DRO position after a spindle run is still very quick with MAX_OUTPUT = 1.0. In fact, that return does not seem to change with MAX_OUTPUT values from 2 to 20...Am i fiddling with the wrong parameter?
[code]setp pid.c.maxoutput [JOINT_2]MAX_OUTPUT
Which MAX_OUTPUT are you changing? It needs to be the one in the [JOINT_2] section. And it might need to be less than 2 (2 revs per second?)
Please Log in or Create an account to join the conversation.
31 May 2021 08:09 #210778
by NoJo
Replied by NoJo on topic Spindle Step/Dir servo ramp down before stop on M stop command.
Well, I think you have cracked it!
WRT pid.c.output;
In AXIS screen jog mode with slider set to max (5000deg/min = 83deg sec)
A jog of approx 360deg takes approx 4sec, so the numbers tally.
during that jog a halscope of pid.c.output shows a max of 0.23
In MDI a G0 C720 shows a peak of 0.8. I used 720deg as 180deg never achieved max velocity before end.
So I set C Axis - [JOINT_2] - pid MAX_OUTPUT = 1.0
Now everything is very well behaved, except for that initial HOME of the C axis - but that is now very tame and unobtrusive so lets live with that.
all jogging, all spindle run then halt/return to C DRO position, all C axis moves, etc are very clean and stable.
I believe you have sorted the C axis implementation! very nice indeed.
If I may repeat a question from my previous post please:
How do I work out what this value should be?
Thanks Andy - I do appreciate what you have done!
I think this is VERY neat!
Joe
WRT pid.c.output;
In AXIS screen jog mode with slider set to max (5000deg/min = 83deg sec)
A jog of approx 360deg takes approx 4sec, so the numbers tally.
during that jog a halscope of pid.c.output shows a max of 0.23
In MDI a G0 C720 shows a peak of 0.8. I used 720deg as 180deg never achieved max velocity before end.
So I set C Axis - [JOINT_2] - pid MAX_OUTPUT = 1.0
Now everything is very well behaved, except for that initial HOME of the C axis - but that is now very tame and unobtrusive so lets live with that.
all jogging, all spindle run then halt/return to C DRO position, all C axis moves, etc are very clean and stable.
I believe you have sorted the C axis implementation! very nice indeed.
If I may repeat a question from my previous post please:
if I increase STEPGEN_MAXVEL to > 80, I get an error -
stepgen.02.maxvel is to big for current step timings and position-scale setting..
Why is that? In spindle mode the step pulses for 2500RPM are way faster than in C axis mode, etc, so I don't understand why it should be to 'big' in this mode.
How do I work out what this value should be?
Thanks Andy - I do appreciate what you have done!
I think this is VERY neat!
Joe
Please Log in or Create an account to join the conversation.
31 May 2021 08:41 #210781
by andypugh
I think that part of the problem is that the HAL is taking some numbers from the [SPINDLE_0] section and some from the [JOINT_2] section.
The stepgen.02 scale is taken from [SPINDLE_0]STEP_SCALE which is 8000.
If you have a step scale of 8000 and a maxvel of 80 then that is a step rate of 640 kHz. That means that STEP_LENGTH + STEP_SPACE must be less than 1500ns. As they are both set to 1000ns there simply isn't time to pulse that fast.
Thinking about it, for consistency, the HAL should be getting STEPGEN_MAXVEL and MAX_ACCEL from the [SPINDLE_0] section (the entries don't exist, you should move them there) . The system uses a velocity controlled spindle, calibrated in revolutions, to control a C-axis via an encoder calibrated in degrees. In effect the C-axis does not have a stepgen at all so the limits should not be in that section.
Anyway, 80 revs per second is 4800rpm. For a 2500rpm spindle it really only needs a STEPGEN_MAXVEL of 50.
Replied by andypugh on topic Spindle Step/Dir servo ramp down before stop on M stop command.
if I increase STEPGEN_MAXVEL to > 80, I get an error -
stepgen.02.maxvel is to big for current step timings and position-scale setting..
Why is that? In spindle mode the step pulses for 2500RPM are way faster than in C axis mode, etc, so I don't understand why it should be to 'big' in this mode.
I think that part of the problem is that the HAL is taking some numbers from the [SPINDLE_0] section and some from the [JOINT_2] section.
The stepgen.02 scale is taken from [SPINDLE_0]STEP_SCALE which is 8000.
If you have a step scale of 8000 and a maxvel of 80 then that is a step rate of 640 kHz. That means that STEP_LENGTH + STEP_SPACE must be less than 1500ns. As they are both set to 1000ns there simply isn't time to pulse that fast.
Thinking about it, for consistency, the HAL should be getting STEPGEN_MAXVEL and MAX_ACCEL from the [SPINDLE_0] section (the entries don't exist, you should move them there) . The system uses a velocity controlled spindle, calibrated in revolutions, to control a C-axis via an encoder calibrated in degrees. In effect the C-axis does not have a stepgen at all so the limits should not be in that section.
Anyway, 80 revs per second is 4800rpm. For a 2500rpm spindle it really only needs a STEPGEN_MAXVEL of 50.
Please Log in or Create an account to join the conversation.
31 May 2021 09:56 #210786
by NoJo
Replied by NoJo on topic Spindle Step/Dir servo ramp down before stop on M stop command.
Thanks, Now I understand.
Again, much appreciated for all you have done!
I will no doubt trouble you again once the ATC and live spindle are built..
On the ATC, the design uses pneumatics to push the toolplate away from the ATC body, disengaging the Hirth coupling, and a stepper to rotate the toolplate to next tool. Removing the air pressure causes a powerful spring to push the toolplate back, engaging the Hirth coupler. More or less conventional..
I have looked at many of the ATC implementations, mostly EMCO and Denford ORAC, some Boxford.
I would like to try implement something along these lines :
The ATC would have a small processor within, handling the stepper, tooplate position and sensing, motion of toolplate, etc.
I envisage 3 wires from the MESA card to the ATC processor indicating desired tool, a single line being Tool Select Request and a Ready line from the ATC processer back to LCNC.
The principle being that LCNC on toolchange sets the desired tool number in binary on the 3 lines and sets the Tool Select request
The ATC processor sees the request, deselects the Ready line back, does the tool select and then sets the Ready line and waits for LCNC to de-assert the Tool request line..
It that sensible?
Would it make for a 'simple' tool change setup, ie, maybe only ini and HAL and not need a special component?
Again, much appreciated for all you have done!
I will no doubt trouble you again once the ATC and live spindle are built..
On the ATC, the design uses pneumatics to push the toolplate away from the ATC body, disengaging the Hirth coupling, and a stepper to rotate the toolplate to next tool. Removing the air pressure causes a powerful spring to push the toolplate back, engaging the Hirth coupler. More or less conventional..
I have looked at many of the ATC implementations, mostly EMCO and Denford ORAC, some Boxford.
I would like to try implement something along these lines :
The ATC would have a small processor within, handling the stepper, tooplate position and sensing, motion of toolplate, etc.
I envisage 3 wires from the MESA card to the ATC processor indicating desired tool, a single line being Tool Select Request and a Ready line from the ATC processer back to LCNC.
The principle being that LCNC on toolchange sets the desired tool number in binary on the 3 lines and sets the Tool Select request
The ATC processor sees the request, deselects the Ready line back, does the tool select and then sets the Ready line and waits for LCNC to de-assert the Tool request line..
It that sensible?
Would it make for a 'simple' tool change setup, ie, maybe only ini and HAL and not need a special component?
Please Log in or Create an account to join the conversation.
31 May 2021 10:09 - 31 May 2021 10:10 #210787
by andypugh
I don't think it makes sense to add an extra processor. LinuxCNC can do all that is required. See, for example, the sim config sim->axis->vismach->vmc-toolchange
This uses the "carousel" hal component to decide which direction to move the tool carousel, and a G-code routine to handle the sequencing. One advantage of doing it as a G-code routine is that it makes it possible to abort gracefully, and with a meaningful error message. (G-code lines such as "(abort, failed to unlock tool)")
Replied by andypugh on topic Spindle Step/Dir servo ramp down before stop on M stop command.
The ATC would have a small processor within, handling the stepper, tooplate position and sensing, motion of toolplate, etc.
I don't think it makes sense to add an extra processor. LinuxCNC can do all that is required. See, for example, the sim config sim->axis->vismach->vmc-toolchange
This uses the "carousel" hal component to decide which direction to move the tool carousel, and a G-code routine to handle the sequencing. One advantage of doing it as a G-code routine is that it makes it possible to abort gracefully, and with a meaningful error message. (G-code lines such as "(abort, failed to unlock tool)")
Last edit: 31 May 2021 10:10 by andypugh.
Please Log in or Create an account to join the conversation.
- Configuring LinuxCNC
- Advanced Configuration
- Spindle Step/Dir servo ramp down before stop on M stop command.
Time to create page: 0.108 seconds