caxis.comp status

  • spumco
  • Away
  • Platinum Member
  • Platinum Member
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.

  • spumco
  • Away
  • Platinum Member
  • Platinum Member
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.

  • spumco
  • Away
  • Platinum Member
  • Platinum Member
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.

  • spumco
  • Away
  • Platinum Member
  • Platinum Member
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.

  • spumco
  • Away
  • Platinum Member
  • Platinum Member
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.

  • tommylight
  • tommylight's Avatar
  • Away
  • Moderator
  • Moderator
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.

  • spumco
  • Away
  • Platinum Member
  • Platinum Member
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.300 seconds
Powered by Kunena Forum