Re: A question of size managenent.

Marcus,

I think we're suffering some from semantics here. Lines and arcs ARE
mathematically different, of course. But MANY CAM packages
WILL "translate" the arcs drawn into "line segments of arcs". I think
you understand this (looking at your post).

A lot depends on what the CAM is working from: DXF (or a "dxf like"
text file) or an integrated internal format used for both the cad and
the cam. If we're reading the dxf file and it says ARC, we will
prob'ly output a G02/G03 to the file we're writing... If it says
polyline, we'll prob'ly approximate with line segments. Some pkg's
just use line segments for everything, regardless of the input!

(More snips/inserts below)

>As far as I know, LINES versus ARCS are completely different
>entities in a CAD system.They are handled differently mathematically.
>There is no such thing as "line segments of arcs" (correct me,
>anyone , if I'm wrong here!)
>
>When the CAM portion of a CAD-CAM system recognizes an entity that
>is an arc, it will apply a G02 or G03 move to it, even if it is a
>bunch of little tiny arcs strung together.

If it is a "bunch" of same radii arcs of different angular length,
the "best" most programs can do is to "write" an "arc"(g2/3) command
to the file for each one. Many will just spit out line segs.

>I'm not sure, without a picture, what you were trying to cut.

Think of the outside of a cast metal beveled letter "U". Or the
inside, that's the part I'M not sure of :-)

>The CAM system does not know or care (I'm anthropomorphizing here)
>what the original constructor was, and does not recognize the
>sequential line segments as approximating an ARC.

<snip>

>I agree, it would be nice if a means existed to take line segments
>that approximate an essentially circular surface or spline and
>convert them into arcs; Mastercam can do this, but only to a very
>limited extent.

There ARE some programs (some are inexpensive "shareware type") out
there which do this. I think they will be found in the realm of
raster/vector conversion, and Gcode optimising.

I have links, if I ever get back to my "base" computer! Help?

>The problem is recognizing when the deviation from circularity
>represents the approximation, and when it represents the beginning
>of a direction change in the spline or surface.
>The CAM system will never know for sure just where the start and end
>points of the arc really are, and exactly what the radius is. This
>is true even if you constructed the surface or spline from arcs
>originally.
>Marcus

Yes, again depending on WHAT (or where) the CAM system is getting its
info. An integrated CAM "should" have more access to the
original "intent". It's these conversions on top of conversions that
get us...

>>would benefit from having a short conversion program that would
>>convert line segments of arcs into arc commands. I don't imagine I
>>am alone with this problem. I would expect that thousands of guys
>>are living with it as we speak.
>>Bill Darby

I suspect you are right. But we should know by now that "good enough"
usually beats "right" in the marketplace every time.

And good enough in this case is making controllers which don't choke
on large files, rather than right, which IMO, is creating shorter
files in the first place.

Hope this helps.

Ballendo