Re: Question about angular and linear feedrates

Hi Dan, Brian,

Your points are well taken. If multiple axis moves were checked for the
number of of pulses to be generated, and the axis with the largest
number of pulses NEEDED is used to determine (calculate for) the
feedrate, then one wouldn't get any "A axis runaway", as you describe.
Without some additional calculations the feedrate wouldn't come out
"true" for an unknown radius on the 'A', but no axis/stepper would be
overdriven. My rotary table comes out to 3.6" per revolution, so one
could divide IPM by 3.6 to get RPM of the table (I think).

I know Dave (and others) do it a little differently then the simple
implementation I've done (and I haven't really paid a lot of attention
to the actual feedrates of the material...yet), but perhaps a "mode" to
give the 'A' axis feed rate (perhaps adding a radius parm?) the control.

I'm curious to hear the solution!

Alan KM6VV
P.S. Up to this point, I've only been concerned with the "care and
feeding" of the steppers, but I can see where the material feed rate is
important, and should be the determining factor. But then, I'm just
cutting aluminum, brass and now some cast iron, not the exotic metals!


Dan Statman 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.
>
> Certainly this would not solve every problem, but can somebody give me an
> example of when this would not be better. The only problems I have
> encountered (and also heard about from others) are when the rotary axis
> spins wildly fast to keep up with a small linear move moving at the feedrate
> value.
>
> I guess I will see if Dave K. will program this type of movement for me.
> For my work the feedrate is not super critical and I could really benefit
> from this programming scheme.
>
> Thanks for all of your input on this,
>
> Dan.
>
> ----- Original Message -----
> From: "bsptrades" <bspunkar@...>
> To: <CAD_CAM_EDM_DRO@yahoogroups.com>
> Sent: Sunday, August 04, 2002 12:16 AM
> Subject: [CAD_CAM_EDM_DRO] Re: Question about angular and linear feedrates
>
> >
> > 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