caxis.comp status
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1905
- Thank you received: 762
17 Jan 2024 05:00 #290925
by spumco
Replied by spumco on topic caxis.comp - problems
Adding some "D" made a huge difference.
I also confirmed that, at least in my config, rotary axis values are in degrees per minute, not seconds. Needed to bump all the values way up before the C-axis performed properly.
So the basic scheme is:
Latest halscope below during a G0 C0, G0 C360 tuning program.
I also confirmed that, at least in my config, rotary axis values are in degrees per minute, not seconds. Needed to bump all the values way up before the C-axis performed properly.
So the basic scheme is:
- Home C-axis first
- If it isn't homed, a spindle command will result in a following error after stopping the spindle
- C-axis remains enabled until a spindle command is given
- Can jog, MDI, and G-code the c-axis with no issues.
- Spindle command works both directions, and RPM is +/- 10rpm according to the encoder.
- Accel/decel are aggressive but smooth
- Can go M3 to M4 with no pauses or issues
- M5 - spindle stops, then rapids to the last c-axis position prior to engaging the spindle
- No unwinding, the return move is always <360 degrees
- G-code
- No problems running a program with both spindle and c-axis moves in it
- C-axis PID could still use some tuning but I'm not sure what else to do.
- It goes where it's supposed to and doesn't get out of control... but I there's too much oscillation during homing or during the automatic return-to-last-position when the spindle is stopped.
- I've had to set the joint/axis ferror & min_ferror pretty high, otherwise it vomits during homing.
- No way to unlock the servo spindle unless I disable the servo enable-in signal.
- If I disable the spindle, upon re-enable it rapids back to the prior position
- Rotating the spindle a few revs by hand trips the following error (simulating a 4-jaw chuck)
- I need to think about how to disable the f-error when the spindle enable is de-asserted
- Jogging
- MPG jog required a scale comp to be added to compensate for degrees vs. ipm. It was way too fine at the standard 0.0001/.001/.01 increments, so I bumped it by 100 for the c-axis.
- Continuous jogging needs some work. Reasonable linear jog speeds (10-100ipm) are painfully slow in degrees/min. Due to my particular config I'm going to have to fiddle a bit. My jog-speed pot sets the speed for all axis/joint continuous jogs... I may have to split the rotary axis out and scale it. Not insurmountable.
- Caxis.comp appears to only permit a single instance
- I tried to set up my sub-spindle as a B-axis tonight but LCNC errored out when created a second caxis.comp instance.
- 'addf failed' was the error message. No variation of names= or counts= worked.
Latest halscope below during a G0 C0, G0 C360 tuning program.
Attachments:
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1905
- Thank you received: 762
17 Jan 2024 05:05 #290926
by spumco
Replied by spumco on topic caxis.comp - problems
Current (working) PID values:
MAX_VEL = 2880
MAX_ACCELERATION = 15000
P = 85
I = 50
D = 2
FF0 = 0
FF1 = 0.144
FF2 = 0.00665
FF3 = 0.000015
maxoutput = 500
deadband = 0.01
MIN_FERROR = 500
FERROR = 500
MAX_VEL = 2880
MAX_ACCELERATION = 15000
P = 85
I = 50
D = 2
FF0 = 0
FF1 = 0.144
FF2 = 0.00665
FF3 = 0.000015
maxoutput = 500
deadband = 0.01
MIN_FERROR = 500
FERROR = 500
The following user(s) said Thank You: COFHAL
Please Log in or Create an account to join the conversation.
- COFHAL
- Offline
- Platinum Member
-
Less
More
- Posts: 350
- Thank you received: 42
17 Jan 2024 12:15 #290946
by COFHAL
Replied by COFHAL on topic caxis.comp - problems
Your work is very interesting. You could post all your configuration to work on.
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1905
- Thank you received: 762
17 Jan 2024 12:36 #290949
by spumco
Replied by spumco on topic caxis.comp - problems
My config is a bit of a mess right now. I could just zip up the folder, but there are files in there that don't belong... plus hal files that have extraneous comments.
I'll try cleaning things up a bit and post a work-in-progress version later.
I'll try cleaning things up a bit and post a work-in-progress version later.
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1905
- Thank you received: 762
18 Jan 2024 13:55 #291025
by spumco
Replied by spumco on topic caxis.comp - problems
So I've been fooling with the caxis.comp setup for a couple days now and I'm thinking about trying some other spindle/axis scheme.
Tuning issues aside, caxis.comp works. But I don't like it - just personal preference. The behavior is not like other controls I'm used to, and I think I prefer c-axis 'mode' to be user-switchable via M-codes rather than automatic as with caxis.comp. The spindle, I think by design, acts like an axis/joint with spindle capabilities... and I'd prefer a spindle with axis/joint capabilities. Subtle difference, but this has been bugging me since the first time I tried it out.
I believe the M-code switch plan was what NoJo and Andy P originally attempted a couple of years ago before Andy wrote caxis.comp. I think the fundamental issue with using an M-code to switch between spindle and axis mode was that you can't home/re-home an axis in the middle of a g-code program.
If you can't re-home, you can't switch on the c-axis in the middle of a program and have a repeatable reference position. There will be a massive following error when you switch to axis mode, but I think that was dealt with by setting the encoder-index-enable pin high... so the f-error was never more than 360 degrees.
So the answer was caxis.comp, with automatic return-to-last-position instead of re-homing the axis in the middle of a program.
But... what if we use orient.comp to position the spindle before re-connecting the encoder to the axis/joint? You can't re-home a joint in the middle of a program, but you can certainly do M19.
My hypothesis is that a 2-step switch will work and eliminates the need for caxis.comp. Basically it looks like this:
That's the rough idea anyway. I'll see if I can work it out.
Tuning issues aside, caxis.comp works. But I don't like it - just personal preference. The behavior is not like other controls I'm used to, and I think I prefer c-axis 'mode' to be user-switchable via M-codes rather than automatic as with caxis.comp. The spindle, I think by design, acts like an axis/joint with spindle capabilities... and I'd prefer a spindle with axis/joint capabilities. Subtle difference, but this has been bugging me since the first time I tried it out.
I believe the M-code switch plan was what NoJo and Andy P originally attempted a couple of years ago before Andy wrote caxis.comp. I think the fundamental issue with using an M-code to switch between spindle and axis mode was that you can't home/re-home an axis in the middle of a g-code program.
If you can't re-home, you can't switch on the c-axis in the middle of a program and have a repeatable reference position. There will be a massive following error when you switch to axis mode, but I think that was dealt with by setting the encoder-index-enable pin high... so the f-error was never more than 360 degrees.
So the answer was caxis.comp, with automatic return-to-last-position instead of re-homing the axis in the middle of a program.
But... what if we use orient.comp to position the spindle before re-connecting the encoder to the axis/joint? You can't re-home a joint in the middle of a program, but you can certainly do M19.
My hypothesis is that a 2-step switch will work and eliminates the need for caxis.comp. Basically it looks like this:
- M5
- spindle stops. No other activity
- Mxxx
- Calls M19
- Spindle orients
- Encoder resets because of encoder-index-enable
- is-oriented goes high
- M66 check for is-oriented
- Reconnect C-axis
- Set position to C0 via G10
- PID to encoder
- Reconnect c-axis jog controls
- C-axis is already at index mark so no massive following error and no need to re-home
- Calls M19
- Mxxx
- Same thing in reverse to disconnect c-axis
- Need an interlock to stop an M3/M4 while in C-axis mode, maybe with error message
That's the rough idea anyway. I'll see if I can work it out.
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1905
- Thank you received: 762
21 Jan 2024 18:32 #291268
by spumco
Replied by spumco on topic caxis.comp - problems
After a few days of creating a stupidly complicated M-code switched spindle-orient-axis scheme, I've come to the conclusion that Andy's caxis.comp simply works better than anything I can come up with. I'll live with the automatic return-to-position behavior.
So... back to the remaining issues with caxis.comp:
Thanks in advance for any suggestions.
So... back to the remaining issues with caxis.comp:
- Acceleration
- I don't really understand the acceleration settings, and that's probably hindering my ability to tune the setup.
- Here are the cases
- Homing
- G0 axis moves
- M3/M4 spindle ramp up/down
- M5 return to position caused by caxis.comp
- Part 1: initial re-position gets really close
- Part 2: pid.c takes over to get it exactly in position
- I've got the following pins/parameters/values
- INI - [TRAJ] MAX_ANGULAR_VEL (7200)
- INI - [TRAJ] MAX_ANGULAR_ACCEL (30000)
- INI - joint/axis MAX_VEL (2880)
- INI - joint/axis MAX_ACCEL (15000)
- INI - spindle MAX_ACCEL_RPM/RPS (300/50)
- caxis.0.spindle-maxaccel (parameter in caxis.comp)
- if low (~50) - M3/M4 ramp up/down is really lazy, as well as the initial return-to-position
- if high (~2000), M3/M4 ramp up/down is brisk but not 'banging'
- What's got me confused is that the return-to-position accel & speed are not the same as a G0 move.
- G0 moves are much 'softer' than the return-to-position or initial homing.
- Is this because the commanded vs position error is much greater during 'Part 2' of the return-to-position move than with a G0/G1 axis move?
- Fundamentally... I can't seem to get the same accel/speed for all cases.
- Tuning
- It's not settling down in axis mode. Once the spindle is turned off and it returns to last c-axis position, pid.c seems to continually hunt back and forth around the commanded position.
- Not fast, not vibrating... but creeping back and forth +/- 5 or so encoder counts (40k/ppr encoder).
- I've upped the pid deadband a bit but that doesn't seem to settle it down.
- I can't get the following error down to what I think an axis (at least this one) is capable of. It's probably good enough for my use-case, but I'd really like some help... or at least someone smarter than me to say "it's not getting any better"
- Do I need to up the gains in the drive and then re-tweak the LCNC PID?
- It's not settling down in axis mode. Once the spindle is turned off and it returns to last c-axis position, pid.c seems to continually hunt back and forth around the commanded position.
- Axis/Spindle disable
- As I've mentioned this is a servo spindle, so I can't manually rotate the spindle without disabling the drive. Once I disable and rotate the spindle the c-axis f-error goes banannas and errors out when I re-enable the spindle.
- The only thing I can think of (right now) is to have the amp-enable de-asserted signal unhome the c-axis, and force a re-home on amp-enable.
- I can't imagine a situation where I'd want to manually rotate the spindle in the middle of a program.
- Multiple instances
- I'd really like a second caxis.comp instance for my subspindle. I'll repeat my earlier plea for help: how is a comp written (more specifically edited) to permit multiple instances?
- If it a hard no-go, I'll fall back on spindle orient.
Thanks in advance for any suggestions.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
- Aciera
-
- Offline
- Administrator
-
Less
More
- Posts: 4195
- Thank you received: 1844
21 Jan 2024 18:46 #291269
by Aciera
Replied by Aciera on topic caxis.comp - problems
Have you tried:
loadrt caxis count=2
loadrt caxis count=2
Please Log in or Create an account to join the conversation.
- Aciera
-
- Offline
- Administrator
-
Less
More
- Posts: 4195
- Thank you received: 1844
21 Jan 2024 18:50 #291270
by Aciera
Replied by Aciera on topic caxis.comp - problems
I think that a component can be written so it is callable ony once. See 'singleton':
linuxcnc.org/docs/html/hal/comp.html
I don't know if that means that if a component is not defined as 'singleton' it can be called more than once but you could certainly try.
linuxcnc.org/docs/html/hal/comp.html
I don't know if that means that if a component is not defined as 'singleton' it can be called more than once but you could certainly try.
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 19786
- Thank you received: 6688
21 Jan 2024 18:52 #291271
by tommylight
Replied by tommylight on topic caxis.comp - problems
Or edit the comp by changing something singleton to false and recompiling ?
Please Log in or Create an account to join the conversation.
- spumco
- Offline
- Platinum Member
-
Less
More
- Posts: 1905
- Thank you received: 762
21 Jan 2024 20:11 #291280
by spumco
Replied by spumco on topic caxis.comp - problems
Thanks all.
I've tried
There's no 'singleton' or other text I can see that would limit how many instances.
A cookie for anyone who can spot something obvious in the comp below.
component caxis "Control a spindle as a C-axis";
//original from andy with no userkins section
pin in bit spindle-on;
pin in float spindle-revs;
pin in float spindle-velocity-in;
pin out float spindle-velocity-out;
param rw float spindle-maxaccel = 50;
pin out float position-fb-out;
pin out bit pid-enable;
pin in float pid-in;
pin out bit spindle-at-speed;
pin out signed state;
license "GPL";
author "andypugh";
function _;
;;
#include "rtapi_math.h"
FUNCTION(_){
static float offset;
switch state{
case 0: // C-axis mode
if (spindle_on){
state = 1;
}
pid_enable = 1;
spindle_velocity_out = pid_in;
// detect index-reset
if (fabs(position_fb_out - (spindle_revs - offset) * 360) > 180){
offset = round(spindle_revs);
}
position_fb_out = (spindle_revs - offset) * 360;
break;
case 1: // Spindle has been enabled, do accel
pid_enable = 0;
spindle_at_speed = 0;
if (! spindle_on){
state = 3;
break;
}
if (spindle_velocity_in > 0){
spindle_velocity_out += spindle_maxaccel * fperiod;
if (spindle_velocity_out >= spindle_velocity_in){
state = 2;
}
} else if (spindle_velocity_in < 0){
spindle_velocity_out -= spindle_maxaccel * fperiod;
if (spindle_velocity_out <= spindle_velocity_in){
state = 2;
}
}
break;
case 2: // spindle running normally
if (! spindle_on){
state = 3;
spindle_at_speed = 0;
break;
}
spindle_velocity_out = spindle_velocity_in;
spindle_at_speed = 1;
break;
case 3: // spindle ramp to zero
if (spindle_on){
state = 1;
break;
}
if (fabs(spindle_velocity_out) < spindle_maxaccel * fperiod){
spindle_velocity_out = 0;
spindle_at_speed = 1;
offset = round(spindle_revs);
state = 0;
break;
}
if (spindle_velocity_out > 0){
spindle_velocity_out -= spindle_maxaccel * fperiod;
} else {
spindle_velocity_out += spindle_maxaccel * fperiod;
}
}
}
I've tried
- count=2
- addf caxis.0
- addf caxis.1
- names=caxis.0,caxis.1
- addf caxis.0
- addf caxis.1
- and other name variations
There's no 'singleton' or other text I can see that would limit how many instances.
A cookie for anyone who can spot something obvious in the comp below.
Warning: Spoiler!
component caxis "Control a spindle as a C-axis";
//original from andy with no userkins section
pin in bit spindle-on;
pin in float spindle-revs;
pin in float spindle-velocity-in;
pin out float spindle-velocity-out;
param rw float spindle-maxaccel = 50;
pin out float position-fb-out;
pin out bit pid-enable;
pin in float pid-in;
pin out bit spindle-at-speed;
pin out signed state;
license "GPL";
author "andypugh";
function _;
;;
#include "rtapi_math.h"
FUNCTION(_){
static float offset;
switch state{
case 0: // C-axis mode
if (spindle_on){
state = 1;
}
pid_enable = 1;
spindle_velocity_out = pid_in;
// detect index-reset
if (fabs(position_fb_out - (spindle_revs - offset) * 360) > 180){
offset = round(spindle_revs);
}
position_fb_out = (spindle_revs - offset) * 360;
break;
case 1: // Spindle has been enabled, do accel
pid_enable = 0;
spindle_at_speed = 0;
if (! spindle_on){
state = 3;
break;
}
if (spindle_velocity_in > 0){
spindle_velocity_out += spindle_maxaccel * fperiod;
if (spindle_velocity_out >= spindle_velocity_in){
state = 2;
}
} else if (spindle_velocity_in < 0){
spindle_velocity_out -= spindle_maxaccel * fperiod;
if (spindle_velocity_out <= spindle_velocity_in){
state = 2;
}
}
break;
case 2: // spindle running normally
if (! spindle_on){
state = 3;
spindle_at_speed = 0;
break;
}
spindle_velocity_out = spindle_velocity_in;
spindle_at_speed = 1;
break;
case 3: // spindle ramp to zero
if (spindle_on){
state = 1;
break;
}
if (fabs(spindle_velocity_out) < spindle_maxaccel * fperiod){
spindle_velocity_out = 0;
spindle_at_speed = 1;
offset = round(spindle_revs);
state = 0;
break;
}
if (spindle_velocity_out > 0){
spindle_velocity_out -= spindle_maxaccel * fperiod;
} else {
spindle_velocity_out += spindle_maxaccel * fperiod;
}
}
}
Please Log in or Create an account to join the conversation.
Time to create page: 0.107 seconds