Re: Is this a silly idea

--- In CAD_CAM_EDM_DRO@yahoogroups.com, Jon Elson <elson@p...> wrote:

> No, we were talking about a physical machine with one rotary axis
> and one (or two) linear. If the programmer runs a straight line

right

> over the (0,0,0) point, the rotary axis doesn't have any defined

position

> to be in. I have no idea what EMC's reverse kinematics will do in
> that case. NaN problems seem quite likely, but it might behave
> fine, too. I don't know. But, it could be a serious problem.
> This type of machine (Rho-Theta) has another problem. When far
> from the center of the rotary axis, extremely small movements of
> the rotary axis cause very large movements of the workpiece.

Jon, having personally used this system for special projects over the
past several years I concur that gimbal lock isn't an issue since it
involves two rotational axes pointing in the same direction and the
case in point is about a single rotational axis (the C-axis) along
with the X and Z linear axes. And while the 0-0 crossing does have to
be treated as a special case, it is but one of many. For example any
time that X = 0, then that block has to be treated separately. The
conversion [angle = arc tan (Y/X)] will result in a divide by zero
error otherwise. The 0-0 crossing just requires stopping the
movement, looking ahead to the next block that results in a linear
move, rotating the rotary table and then continuing the cut. This is
probably the worse case since it might cause a divot in the process.
Crossing the 0/360 deg also must be dealt with, and there are others.
In the real world, the feed rate is perhaps the trickiest. Near the
origin the calculated angular rate can get astronomical. Take the 0-0
crossing. A smooth continuous cut would require moving to the rotary
center, doing a 180 and reversing the X instantaneously. Not
possible. Moves even near the 0-0 have the same problem. And the feed
rate must be expressed in the proper units. In my case (CNCPro)
either in/min or deg/min. Numerically they are about an order of
magnitude different so this requires careful handling.
I took the simplest approach that I could think of. That is to draw
the part in the usual rectangular coordinates, develop the gcode
(using Vector CAM), and then write an app in VB6 to convert the gcode
block by block to polar coordinates. The kinematics is
straightforward, although it did get interesting when I added the
option to offset the rotary in the Y to allow larger parts on the
Sherline.
As suggested by the original poster, there are cases where this is
actually the preferred method. (small fly wheels, gears, etc.) And
other cases where it is the ONLY way to cut a part, i.e. my example
of cutting a 10-inch clock dial on a machine with a 3-½ inch throat.
Al Lenz
P.S. I will gladly share the VB6 source code with anyone with a
common interest. Contact me off list. The usual caveats, I only wrote
it for my own use but maybe it will give you a leg up.
al