caxis.comp - problems

More
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:
  • 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
Remaining issues:
  • 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.
Anyone know how to edit a comp to permit multiple instances?

Latest halscope below during a G0 C0, G0 C360 tuning program.
 
Attachments:

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

More
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
The following user(s) said Thank You: COFHAL

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

More
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.

More
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.

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

More
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:
  • 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
  • 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.

More
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:
  • 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?
  • 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.

More
21 Jan 2024 18:46 #291269 by Aciera
Replied by Aciera on topic caxis.comp - problems
Have you tried:
loadrt caxis count=2

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

More
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.

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

More
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.

More
21 Jan 2024 20:11 #291280 by spumco
Replied by spumco on topic caxis.comp - problems
Thanks all.

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
Everything fails at 'addf' at startup if there's more than one instance in the loadrt line.

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!

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

Time to create page: 0.290 seconds
Powered by Kunena Forum