Re: Question about angular and linear feedrates

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

> I would like to know how most (all) control programs will handle the
> feedrate for the following moves:
>
> A-axis is angular with feedrate expressed in degrees/sec
> X-axis is linear with feedrate expressed in inches/min
>
> Assume that I am always starting at X0 and A0 for these moves.
>
> If I command: G01 A180 F1.0 it should take 180 seconds to make the

move.

> If I command: G01 X0.5 F1.0 it should take 30 seconds to make the

move.

>
> My question is how long should the following move take starting at

A0 X0:

>
> G01 A180 X0.5 F1.0
>
> Does it take 30 seconds or 180 seconds?
>
> Thank youf or your help.
>
> Daniel J. Statman, Statman Designs
> www.statmandesigns.com

Dan the example you show brings up what seems to be a common dilemma
when dealing with combined linear and rotary axis motion. The basic
problem is there is not enough information provided the control to
determine the effective surface rate for the angular move. The
control would need to know the kinematics of the setup to make these
decisions on the fly. A robot for example knows where it is, 4,5 or
more axis coordination is then easy enough.

The simple interpreter such as TCNC has no idea where the rotary
axis is located. Lacking the plane and origin of the rotary axis you
can only make a guess at what the feed rate should mean. In your
examples one case is a rotary only move so it would assume the rate
is in that axis units. The same holds true for the linear only moves.

The problem is now if I mix rotary and linear moves what are the
Feed rate units? You would like them to relate to surface rate but
since you don't have the rotary geometry it makes the assumption
you
mean linear. This has been the behavior I see most often.

The key here is if the control does not have an axis setup to allow
definition of the rotary axis parameters it can only guess so it will
be wrong some of the time. You can only fix this by changing the
control or adapting to it's assumptions.

As I see it you either.
1. Have a way to define the rotary axis center of rotation
vector, then the control can interpolate to effective surface rate.
2. You have a means of defining the current work radius on the
command line or via machine setup command.
3. Or, you have to know the "assumptions" the control makes
and
set the feeds in the CAM process to accommodate these assumptions.
For TCNC you should check with Dave or Jerry what the
exact "assumptions" the parser makes are and adjust your code
generator. Otherwise perhaps they can fix it to allow a means to
define the radius or location of the rotary so it can better
comprehend feed vs. cutter surface rate.

Brian
BSP