Re: [RE: emc really needs a copyleft cad/cam package]

["Anne Ogborn" <anniepoo-at-netmagic.net>]

> Anne Ogborn wrote:
> >
> > Hmm...
> >
> >    I think before we can go very far with a features list we
> > should clarify if we're expecting this to be a CAM package that
> > takes a model from elsewhere and produces a tool path from it,
> > or an integrated CAD package and CAM package.
> >
> >   Personally I'd rather we do the former, for the very practical
> > reason that it's a more do-able size project, if nothing else.
>
> I. I was going to address this issue in my last post, but it got too
> late.
>
>   A. I would think (and I could easily be wrong), that a CAM package is
> going to have a lot of the elements necessary to build a CAD package.
>

Yes, you need some common elements. But a truly useful CAD system has so
much more functionality
than the basic things you've listed that it's probably not reasonable to
assume you can simply attach
the CAD functionality to a CAM package.
Doing the reverse might be reasonable, although I'd suggest it's probably
not the best solution.

There's a natural correspondance between functionality and data type. This
is one of the fundamentals
of object oriented programming.
The data type edited by a CAD system (technically a solid modelling system)
is a model.
The data type edited by a CAM system is a tool path.

Often the base data type being edited can have other data types applied to
it -
In a CAD system we might have commands to map pixmap data onto a surface.
In a CAM system we might have commands to map pixmap data to a set of relief
cuts
for an engraving type application.
In particular, it's common for a CAM system to import solid models.

I'd argue that a CAM system is inherently a system for creating and editing
tool paths, not
solid models. The solid models are a means to and end.

anyway, I suggest this thread move to the gnu_cad list.


>     1. You'll need a canvas upon which you can display entities in the
> drawing database, and which can be zoomed and panned.
>
>     2. You'll need object snaps.
>
>     3. You'll have to be able to pick (select) entities and snap points
> with the mouse to specify the starting and ending points for moves in
> the cnc program.
>
>     4. Having said all that, I'd be happy to start with the CAM
> functions first and import our geometry. CAD functionality could be
> added later if we adopt a modular approach to building the program so
> that it can be extended by folks who need those extensions. Examples of
> extendable programs:
>
>       a. TkEMC will automatically add items to one of its menus when you
> put new script files in a certain directory.
>
>       b. EMACS can be extended to do almost anything (and has been...).
>
>   B. We could probably do without:
>
>     1. New entity creation commands (line, circle, arc, etc.).
>
>     2. Text and dimensioning.
>
>     3. Printing (maybe).
>
> II. Direct DXF to g-code converters:
>
>   A. Work OK for extremely simple jobs where there are no ambiguities,
> but you really need lots of user input to create tool paths from complex
> geometry.
>
>   B. Usually generate code that runs the cutter centerline along the
> geometry.
>
>   C. I don't know how it decides which direction to go. If it takes its
> cue from the start and end points of lines and arcs in the DXF file,
> it's going to be pretty confused.
>
> Matt
>