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

["Ian Wright" <Ian-at-iw63.freeserve.co.uk>]

Hi,

A linux CAM package has been top of my wish list for some time and, while I
am not in a position to contribute anything really useful, I wish you every
success in working together on this.  There are a number of people on the
lists who keep expressing a desire for more than 3 axes - myself included,
and I wonder whether this could be considered in the design of the software.
I have ideas about the possibilities of generating some of the complex gear
forms I need by operating all three linear axes together with a dividing
head and possible tilting the 'Z' axis all at the same time - so, the utopia
of 6-axis capability would be extremely desireable.

Ian
--
Ian W. Wright
Sheffield  UK
www.iw63.freeserve.co.uk
----- Original Message -----
From: "Matt Shaver" <mshaver-at-erols.com>
To: "Multiple recipients of list" <emc-at-nist.gov>
Sent: 19 November 2000 05:47
Subject: Re: [RE: emc really needs a copyleft cad/cam package]


>
> 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
>
>
>