Re: Question about angular and linear feedrates

--- In CAD_CAM_EDM_DRO@y..., "Dan Statman" <dan.statman@r...> wrote:

> The points you state are obviously correct in that the controller

has no way

> of knowing the radius of the spinning part to determine a linear

feedrate

> based on the rotation feedrate. My contention is this, wouldn't it

always

> be a better compromise if when the feedrate is set to 1.0 then the

linear

> axis should never move faster than 1.0 ipm and the rotary axis

should never

> move faster than 1.0 degrees per second, and the non-limiting axis

would be

> adjusted so that the move is synchronized.
>

Think in 3D rather than cylindrical surface only. Ther is no reason
that the controller cannot be aware of radius.

Assume you have a rotary axis parallel to the X. This would be
termed an A axis. You can vary the Z, and A simultaneously. Don't
change the X at all for this example.

You command a series of Z-A movements (Z=0 at centerline of A axis).

Z1 A90
Z0 A180
Z1 A270
Z2 A360
Z1 A90

This forms a 1/2 roundish kind of part. You might of course want the
inner area to even be concave and the Z=0 at 180 might actually go
negative. If you apply a single feedrate in degrees per minute, or
degrees per second, you will find that this contour in very difficult
to cut, with slow cutting near the center and fast rotation near the
outer diameter of the part.

If you now add in some X movements as well, the problem is further
compounded, but you finally see the whole picture.

The solution for rotary 4th axis contouring is for the controller
software to evaluate each movement as a series of linear
approximations and apply the programmed movement in inches per
minute, with a limit of the actual maximum feed rate possible on any
of the 3 axes, including the effects of the radius, as defined by the
Z height. While it's true that there is also a Y component available,
there is no supported software that will actually utilize that
component in a low cost product(yet). Therefore if the 3 axes were
processed in the controllers (X-Z-A), it would result in a very
usable solution for the hobbyist

Things to watch out for:

1) Some controllers cannot make a straight X or Z movement when in
rotary mode as there are no degrees defined in the move block, and
they do not maintain a linear and a rotary feed rate.

2) Some controllers will only program the radius at one size. Any
significant Z movement off that predefined cylinder will create
wildly fluctuating real feed rates at the cut.

3) Some controllers will pick the slowest axis no matter what. and
then do not compensate for Z variation if the rotary is the slowest.

4) Some controllers cannot differentiate between linear and rotary
movement at all and require the user to scale his axis and feed
rates, and even though the rotary is a function of the Z height,
apply all feed rates linearly.

I wrote a program that post processed 3D linear G-code into 3D rotary
axis with proper feed rates in Degrees per minute(360.999) for the
entire envelope I have defined. The theoretical movements and speeds
were correct, but none of the low end controllers were capable of
actually processing the data. (lack of 4th axis coordination, poor or
no continuous contouring, etc) This was before EMC and it may now be
possible to process the data correctly, particularly since EMC pre-
processes the entire file, and with a quadrupling of processor speed
since I wrote the program 4 years ago.

Best Regards, Fred Smith- IMService

Listserve Special discounts and offers are at:
http://www.imsrv.com/2002group.html