caxis.comp - problems

I think that's a result of the conditions I needed to capture anything.

First case I started with spindle at C0, then did an M3 S500, then an M5.  So the caxis component didn't change the position command - it was always C0.  The duration of the move will always change as the M5 doesn't stop at a particular orientation.

Second case was a short C0-C9-C0 program, so the pos-cmd changed at each line.

What's bugging me is that the accel and velocity of the two moves are so different.  And why I can't speed up (and smooth) the C-axis moves without getting really weird oscillation and crazy overshoot... yet the M5 move can be snappy and clean.

I'm wondering if the caxis.comp is using the spindle PID values for the automatic moves and regular c-axis moves are done using the c0.pid.

Or something along those lines.

Bit of an update, and my dumb is showing itself again.

Turns out the motor encoder ppr was wrong.  I thought I'd set it to 4096ppr (it's programmable), but I remembered when setting and tuning the servo drive it reported the motor as an 8-pole.  Seems odd at the time, but I just ignored it and plowed on.

I got to thinking there was something wrong while fidding with this c-axis comp and decided to check everything from the basics.

Using the drive software to read the counts, it turns out the motor encoder is set to 2048 lines (8192ppr).

SO... after some re-tuning in the drive (now it's a 4-pole, joy) I've re-set my stepgen scale and things seem to be settling down a bit more.  The c-axis moves are still pretty slow, but it's not doing the strange creep-way-past-target-and-reverse thing.  G0 moves are smooth, as are the automatic return at M5.  Both at the same speed (slow).

What's got me confused is that after the changes spindle mode RPM is about half what it should be.

Just in case somone wants to check my math...

• Motor encoder = 8192 counts/motor rev (verified via drive software)
• Spindle encoder = 2400 counts/spindle rev (verified using encoder count in LCNC)
• Motor encoder rotates 12110 counts per spindle rotation (turned by hand from 0-2400 spindle encoder counts in halshow)
• so belt drive is 1.478:1 (DIY poly-v, diameters were 'ish')

So my step scale should be 12110... right?

So why is the spindle rotating at 270rpm when I command S500?  And about 530rpm at 1000rpm commanded?  Both speeds verified with photo tach just to be safe.

The step scale and encoder scale don't change between c-axis and spindle modes... so wth?

Finally getting somewhere.

I think there is an error in the LCNC manual.

Under INI [AXIS] and [JOINT], the following:[/code][/code]


So naturally I set my MAX_VELOCITY appropriately: 720 degrees per second (for 2 revs/sec).  Same for the [TRAJ] and [DISPLAY] sections.

After pulling my hair out for a couple days trying to figure out why the C-axis was moving so slowly... I took a gamble tonight and bumped all the values way up.

It appears that LCNC is calculating angular axes based on machine units per MINUTE, not second.  MAX_VELOCITY = 7200 started working as expected.

Same issue with homing speed - LCNC is calculating on units per minute, not second for angular axes.

Adjusted MAX_ACCEL appropriately, and now it's whipping around like a champ and I can get to PID tuning.

Moving forward...it's got quite a bit of overshoot and undershoot, and I'm not sure where to go from here.  Not seriously unstable... just springy.

Based on these settings:
P = 0.04
I = 0
D = 0
FF0 = 0
FF1 = 0.015
FF2 = 0.015
FF3 = 0.005
maxoutput = 0
deadband = 0.2

Raising P causes it to go unstable.

I've got a scope that looks like below.  Any suggestions on how to tighten it up?
[/code]

[not going to try to edit that again.  screen cap below]

 

Now I'm less certain there's an error in the LCNC manual, and am suspecting there's an error between the manual and my keyboard.

For those of you silently following along it just occurred to me that I may have made a really dumb mistake.

The spindle/c-axis stepgen position-scale is 12110, and that's set in the INI [SPINDLE] section.  Feedback is 2400 pulses per rev (soon to be 40k after the new encoder is wired up).

But that's 12110 pulses per revolution.  And the C-axis units are in degrees.

So I'm flipping back and forth between two PID loops...Both use the same input (2400), but the outputs need to be calculated for two different units.

But LCNC isn't doing that, because I haven't told it to scale the C-axis output for degrees.  No wonder it's reacting wonky.

I feel like the IT Helpdesk person has just asked me to check if the computer is plugged in... And I stifle my sense of outrage and look down to see it's unplugged.

To be continued...

I've been editing hal while attempting to change the controls scheme from a position-mode stepgen to velocity-mode using PWM.  I'm trying to eliminate the (possible) problems with managing a spindle/axis having two units (revs vs. degrees) but only one stepgen scale.

Sadly, I've managed to confuse myself, possibly beyond redemption.

I think my main problem is that there are so many pins available between spindle, encoder, joints, and PID's I'm getting saturated - and most of them aren't needed as they're scaled duplicates.
Like so:
spindle.0.speed-out
spindle.0.speed-out-abs
spindle.0.speed-out-rps
spindle.0.speed-out-rps-abs


What's throwing me for a loop:  it appears that despite NoJo's (and my earlier) config having two PIDs, only one is being used.  There's a whole 'pid.s' section with settings and pin connections... but pid.s.output signal is not connected to anything.

So in axis mode it's closed loop, but in spindle mode it's open-loop.

It looks like the basic scheme is this:

• Spindle OFF
  • pid.c.output (position) is fed in to caxis.comp
  • caxis.comp outputs velocity command to the stepgen
• Spindle ON
  • caxis.comp disables pid.c
  • takes spindle speed command in (without passing through any PID)
  • caxis.comp outputs velocity command to the stepgen
• Transition from ON to OFF
  • caxis.comp fiddles with the position feedback so there isn't a massive following error
  • caxis.comp re-enables pid.c
  • pid.c causes the axis to return to the last position prior to spindle-on

I think what I need will look like this:

spindle command -> pid.s.input -> pid.s.output -> caxis.0.spindle-velocity-in

And pid.s is disabled when the spindle is commanded off, so it's not continually sending a velocity correction signal to caxis.comp while in axis mode.

Here goes nothing...

We're in business.

After some fits & starts with the encoder and various scaling boo-boos I've got the system working via PWM command.

Spindle mode works exceptionally well once I figured out the caxis.comp parameter (caxis.0.spindle-maxaccel) was clamping spindle accel/decel values.  Until I set that way higher than the standard '50' in the comp the spindle was acting very lazy.  Unfortunately there's no description in the comp as to what units are used - don't know if it's degrees/sec/sec, rps, rpm, or some other mystery unit.

Now it's a matter of tuning up axis mode.

It's working OK-ish now, but I think it could be much better.

I seem to recall some recent discussions of velocity-mode servo control using FF1 and P but that presumes you know what FF1 should be first.

MAX_VEL = 720
MAX_ACCELERATION = 7200
P = 35
I = 0
D = 0
FF0 = 0
FF1 = 0.15
FF2 = 0.015
FF3 = 0
maxoutput = 200
deadband = 0.05

Results in lazy behavior.  It reaches target position and doesn't vibrate much or overshoot, but it takes forever to finally settle down that last little bit.  Doesn't move very quickly and I know this thing is capable of extremely fast moves.

Does anyone know if there's a way to calculate FF1 based on encoder count and max output? Or some other variables?

 

If it helps, the move above is a G0C360 -> G4P0.25 -> G0C0 repeat loop.

hello, I check regularly to see your progress, I'd like to help you, but unfortunately I don't have your linux skills, I admire your work.

jpg wrote:

hello, I check regularly to see your progress, I'd like to help you, but unfortunately I don't have your linux skills, I admire your work.

Kind of you, but the reality is that I have no linux skills.  I substitute bloody-minded persistence for actual knowledge.

On a happy note... there was a breakthrough late last night and everything seems to be working rather nicely.  I'll post some details later.