Rotary axis stuff

[rehenry-at-up.net]

List

I've finally been able to get near a Sherline index table and have been
doing some testing on it with the EMC.  This is a preliminary report on my
work.  It is also a request for your help.  If you have any thoughts please
reply.   I'm using a via 800 with 128 Meg RAM and BDI 2.18.

I have found that freqmod does a much better job of driving the motors with
the experimental card that I've got here.  My setup works reasonably well
as an indexer so long as you do not try coordinated motion with any linear
axis.

You can not use g0 with the rotary at all as you will get .334
degrees per second if you do.  In order to get reasonable speeds, I use g1
f2400.

As you can see from the ini variables below, I've had to set
acceleration very high in order to get the rotary to get up to speed or
stop in about 10 to 15 degrees.

The relevant variables from the ini I'm using are;

EMCMOT =		freqmod.o
PERIOD =		0.000026

; Trajectory planner section
MAX_VELOCITY = 		40
DEFAULT_ACCELERATION =	50.0
MAX_ACCELERATION =  	50.0

; First axis
MAX_VELOCITY =          0.334
P = 220.000
FF1 = 6.000
DEADBAND = 0.0007
INPUT_SCALE =			8000	0
OUTPUT_SCALE = 8000.000 0.000

; Fourth axis
TYPE =				ANGULAR
MAX_VELOCITY =			40.0
P = 220.000
FF1 = 6.000
DEADBAND = 0.007
INPUT_SCALE =			80	0
OUTPUT_SCALE = 			80 0.000
MIN_LIMIT =			-10000.0
MAX_LIMIT =			10000.0
MIN_OUTPUT =			-50
MAX_OUTPUT =			50
FERROR = 360.00
MIN_FERROR = 36.00

While I was tuning I found that the indexer hit a wall around f600.  It
stumped me for the longest time.  No matter how I set velocity, gain, or
acceleration it would fault out on following error for anything over 600
and the sound of the motor seemed the same. Finally I raised the min and
max output and could get past that limit. It seems that each additional 10
gives another f600.

I also found that if I set max and min output to exactly the speed I was
commanding, I'd get a good ramp up but it would stop dead at the end of the
move.  At speed, this would often cause a following error as well.  By
allowing higher output than required, the ramp down was as good as the ramp
up.

The machine performs well for index operations like the sample program
below. This program makes a series of grooves across the edge of a fairly
thin disk. This code assumes that the indexer is mounted on the x slide and
rotates around the x axis. The table's jaws hold the part a bit more than
two inches negitive in x from from home position. (axis centers) Y home is
centered on the index table. Z is four inches above table center.

g0 x0 y0 z0 (make certain that the machine is home)
g1 f2400 a0 (make certain that the index table is home)
m0 (msg, load part in indexer jaws and press resume)
g0 x-2 z-2
g1 f6 x-3
f600 a 2
g6 x-2
g2400 a45
f6 x-3
f600 a47
f6 x-2
<snipped>

While all of the feedrate changes are an annoyance, they work to produce
acceptable speeds during a cutting operation.  The only real downside of
this is that it screws up the sliders and values that represent or change
jog speed in tkemc.  If you forget and leave the f2400 for a linear move
you will get the 20 ipm that these are set for.  If you forget to ask for
the high speed rate you will index at .334 or less degrees per second.
Deadly slow.

I have just begun to test coordinated motion and there are a lot of
problems with it.  The first seems to be that the linear axis takes
precedence for both feedrate and acceleration.  I am able to execute a
helix using (g1 f2 x1 a360) but if you want the same rotation for x.5 you
will need to reduce feedrate to f1 or the acceleration of x will cause a to
fault.

If you start with feedrate override set to a low percentage, you can do
stuff like (g1 f1 x2 a3600) for 5tpi Acme thread.  Don't try to ramp the
override up very fast though.

It seems to me that we need to add a bit of math to the trajectory planner
that kicks in any time a program block coordinates linear and angular axi.
If we had a max acceleration and a max velocity as a part of each axis
definition, it would allow us to compute an acceptable rate for the
combination based on the lowest value.  If it took longer to get the
angular axis up to speed, it would be the limiting factor on the
acceleration of the linear.  And so forth.

It would be really nice if we could set a coordinate zero that matched
the center of rotation and use the feedrate word as a constant
surface speed for the cutter.  For an example imagine a 1" diameter round
stock and a feedrate of 3.  The index table would need to travel about 1
rpm in this case for a 0.050 deep groove.   I suspect that this will have
to wait until we have done a bit more discussion of the issues involved.

Ray