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

[Matt Shaver <mshaver-at-erols.com>]

I. My Wishlist:

  A. "Must haves":

    1. AutoCAD command line compatibility:

      a. This means that when I type "line" it should come back with
"Start of line:" or "From point:", depending on what version you decide
to emulate.

      b. I know a lot of folks think AutoCAD's user interface is really
lousy, but it's what I (and most other cad users) know how to use and
I'm not really keen on learning how to draw in cad all over again.

      c. I'm certainly not opposed to a push button/dialog box style
interface as well, it's just that I don't presently use them in AutoCAD.
For me, it's faster to type "line 0,0 1,1" than to fill out the fields
in a dialog box. This is of course, predicated on the fact that I know
the command syntax.

      d. I think I could extend the AutoCAD style of interface with
commands that initiate machine operations. Perhaps it could be a mode
similar to dimension mode in AutoCAD, except it would be "machining
mode".

      e. Just to reiterate the point I made in item "c" above, I don't
expect the program will have ONLY a command line interface.

    2. DXF file computability:

      a. This is to ensure connectability to the outside world. People
with existing cad files can get that geometry into our system to use in
making g-code programs.

      b. DXF doesn't have to be the native format for the drawing
database (as it is in qcad), I just need DXFIN and DXFOUT filters.

    3. Multiplatform capability:

      a. A while back, on another list, in a different thread, Terry
said (quoting Linus' law) that getting feedback from more users of
Linux, rtlinux, and the EMC would increase their reliability.

      b. If we could make this program run on both Linux and Windows,
we'd be able to spread it around to a wider audience.

      c. This is tied in to a later discussion of what graphical toolkit
to use.

    4. GPL - Terry had this as a requirement in his original post and I
agree completely.

    5. Object Snaps and Print Scaling:

      a. In an earlier post in this thread, Terry remarked that he
preferred xfig to qcad. I looked at xfig, and I like the looks of the
program, but it seems to lack two features that differentiate true cad
programs from vector based drawing programs:

        i. Object snap is a feature that allows new drawing entities
(among other things) to be created in an exact relationship with
existing entities without having to calculate the coordinates of the
desired point. For example, if you want to draw a new line, and one end
of the line is to be at the center of an existing circle, you would type
(in AutoCAD the quotes aren't actually typed, I'm just using them to
show user input):

Command: "line" Start point: "cen" (this is where you tell AutoCAD that
you want to snap to the center of a circle or arc)

of (at this point you pick the circle or arc by clicking on it with the
mouse)

Typical object snaps are CENter, END, MIDdle, TANgent, INTersection,
PERpendicular, etc.

        ii. The print scaling feature means that you draw things at
their actual size, whether they're atoms or galaxies, and the print is
scaled to fit the paper. Most drawing programs (and qcad for that
matter) show you the outline of the paper size you select, and you are
expected to fit the drawing to the paper.

  B. "Nice to haves":

    1. Machining time calculation.

    2. Speed & Feed calculation.

II. General Notes (in no particular order):

  A. 2D vs. 3D:

    1. I've never made a 3D drawing!

    2. The CAM system I currently use gives you a "through the spindle"
view of the milling table.

    3. Depth of cut is a parameter you enter in a menu. In a pocketing
segment you tell it the finished depth of the pocket floor, and the
distance to step down for each pass through the pocket. For example, if
you have a depth of .500", and a step distance of .249", the program
will generate a section of g-code that goes through the pocket twice for
roughing (at Z-.249", and Z-.498"), and once more to finish the bottom
of the pocket at Z-.500".

    4. I could easily live with this type of interface if it was easier
(and faster) to code than a 3D type interface. We could also use the 3D
technology in the backplotter to give us a good simulation function.

  B. Possible Toolkits:

    1. QT:

      a. Pros:

        i. It's popular, and used as the basis of the KDE.

        ii. The X11 version is GPL'ed.

      b. Cons:

        i. The Windows version is commercial software which means we
could only supply pre-compiled binaries for Windows.

    2. GTK:

      a. Pros:

        i. It's popular, and used as the basis of Gnome.

        ii. It's GPL'ed.

      b. Cons:

        i. There is no Windows version (Announcing "GTK for Windows"
would be a great April Fool's joke).

    3. TK:

      a. Pros:

        i. It's popular, and used as the basis of tkEMC and the
backplotter (we have existing talent on our "staff").

        ii. Both the X11 and Windows versions have completely
non-restrictive licensing (good enough for Debian, good enough for me).

        iii. Can be used with TCL, C, PERL, Python, SCHEME, and probably
others I don't know of.

      b. Cons:

        i. It's not GPL'ed, but that probably won't be a problem for us.

        ii. ?

This is meant to be a list of stuff to promote discussion, not a carved
in stone decree so please comment early and often. I'll try to write
something about my view of the block diagram of the system later today
(it's my birthday!).

Matt