Re: [CAD_CAM_EDM_DRO] Re: Question about angular and linear feedrates

Fred,

Of course you are absolutely correct when taking into account true 4-axis
3-D work. But given the fact that low end controllers are not handling the
mixing of linear and rotary axes very well by using the linear axis feedrate
exclusively and then spinning the rotary axis at a value to keep the move
synchronous, which may be far in excess of a reasonable value, don't you
think it would make sense to limit the speed to the SLOWER of the rotary
feedrate or the linear feedrate.

This obviously assumes that the feedrates are selected with knowledge of the
radius of the rotating part. By selecting the feedrates with this
knowledge, I then do not have to have the control program know the radius.
and the only downside is that sometimes the part moves slower than I
intended. This is not nearly as detrimental as moving faster than I
expected. If it moves slower then the part takes longer, if it moves faster
the cutter breaks and the part is potentially ruined.

Dan.

----- Original Message -----
From: "imserv1" <imserv@...>
To: <CAD_CAM_EDM_DRO@yahoogroups.com>
Sent: Sunday, August 04, 2002 9:10 AM
Subject: [CAD_CAM_EDM_DRO] 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
>
>
>
> Addresses:
> FAQ: http://www.ktmarketing.com/faq.html
> FILES: http://groups.yahoo.com/group/CAD_CAM_EDM_DRO/files/
>
> OFF Topic POSTS: General Machining
> If you wish to post on unlimited OT subjects goto:
aol://5863:126/rec.crafts.metalworking or go thru Google.com to reach it if
you have trouble.
> http://www.metalworking.com/news_servers.html
>
> http://groups.yahoo.com/group/jobshophomeshop I consider this as a
sister site to the CCED group, as many of the same members are there, for OT
subjects, that are not allowed on the CCED list.
>
> NOTICE: ALL POSTINGS TO THIS GROUP BECOME PUBLIC DOMAIN BY POSTING THEM.
DON'T POST IF YOU CAN NOT ACCEPT THIS.....NO EXCEPTIONS........
>
> Post messages: CAD_CAM_EDM_DRO@yahoogroups.com
> Subscribe: CAD_CAM_EDM_DRO-subscribe@yahoogroups.com
> Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@yahoogroups.com
> List owner: CAD_CAM_EDM_DRO-owner@yahoogroups.com, wanliker@...
> Moderator: jmelson@... timg@... [Moderator]
> URL to this group: http://groups.yahoo.com/group/CAD_CAM_EDM_DRO
> bill,
> List Mom
> List Owner
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>