Linux/GNU CAD CAM Design Document ********************************* Terry L. Ridder +++++++++++++++ terrylr@blauedonau.com Revision History Revision v0.01 22 Nov 2000 Revised by: tlr Initial Release This is the initial release of the Linux/GNU CAD CAM project design document. Table of Contents 1. Introduction 1.1. Copyright Information 1.2. Disclaimer 1.3. New Versions 1.4. Credits 1.5. Feedback 1.6. Translations 2. Block Diagrams 2.1. Top Level Block Diagram 2.2. Level One Detail Block Diagram 2.3. Level Two Detail Block Diagram 2.4. Level Three Detail Block Diagram 2.5. Level Four Detail Block Diagram 2.6. Level Five Detail Block Diagram 2.7. Level Six Detail Block Diagram 2.8. Project Timeline 3. Structure 3.1. Logical structure 3.2. Document structure 3.3. Suggested Reading 4. Technologies 5. Implementation 6. Maintenance 7. Advanced Issues 8. Further Information 8.1. News groups 8.2. Mailing Lists 8.3. HOWTO 8.4. Local Resources 8.5. Web Sites 9. Getting Help 10. Concluding Remarks 11. Frequently Asked Questions 12. Bits and Pieces 13. Examples A. GNU Free Documentation License A.1. 0. PREAMBLE A.2. 1. APPLICABILITY AND DEFINITIONS A.3. 2. VERBATIM COPYING A.4. 3. COPYING IN QUANTITY A.5. 4. MODIFICATIONS A.6. 5. COMBINING DOCUMENTS A.7. 6. COLLECTIONS OF DOCUMENTS A.8. 7. AGGREGATION WITH INDEPENDENT WORKS A.9. 8. TRANSLATION A.10. 9. TERMINATION A.11. 10. FUTURE REVISIONS OF THIS LICENSE A.12. Addendum 1. Introduction *************** The Linux/GNU CAD CAM project is in response to a void in the available CAD/CAM software packages available for the Linux/GNU operating system. While both commercial machine shops and home shop machinists are able to use the The Enhanced Machine Controller written by Fred Proctor & William Shackleford III of the National Institute of Standards and Technology. There are no opensource software programs or packages available for the CAD/CAM work. The Linux/GNU CAD CAM Project is currently in design stage. There are many different schools of thought concerning design methodology, with each school of thought having strengths and weaknesses. There are basically two extremes in software projects. o Writing code begins with no design documents to reference and/or to use for guidance. o No line of code shall be allowed to be written till the weight of the design documents equals the combined weight of all developers. This project is going to extend the ideas put forth in The Cathedral and the Bazaar : Analysis of how and why the Linux development model works! to the design stage as well. The goal is to stay in the middle between the two extremes mentioned above. I would suggest that everyone take the time to read The Cathedral and the Bazaar. I will refer to it throughout the project. There are two important "Laws" to remember in any opensource project. The original "Linus' Law" and a modified form of "Linus' Law" are given below. o RememberLinus'Law: "Givenenougheyeballs,allbugsareshallow." --Eric S. Raymond o RememberModifiedLinus'Law: "Givenenougheyeballs,alldesignflawsareshallow." --Eric S. Raymond First of all we need a bit of legalese. Recent development shows it is quite important. 1.1. Copyright Information ========================== This document is copyrighted (c) 2000 Terry L. Ridder. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found in Appendix A. Many of the names used by companies to distinguish their products and services are claimed as trademarks. Where those names appear in any Linux/GNU CAD CAM documentation, and those trademarks are made aware to the members of the Linux/GNU CAD CAM Project, the names have been printed in caps or initial caps. Unless otherwise stated, Linux/GNU CAD CAM documents are copyrighted by their respective authors. Linux/GNU CAD CAM documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author(s) would like to be notified of any such distributions. All translations, derivative works, or aggregate works incorporating any Linux/GNU CAD CAM documents must be covered under this copyright notice. That is, you may not produce a derivative work from a Linux/GNU CAD CAM document and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux/GNU CAD CAM documentation coordinator at the address given below. In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the Linux/GNU CAD CAM documents, and would like to be notified of any plans to redistribute the design documents. If you have any questions, please contact < terrylr@blauedonau.com> 1.2. Disclaimer =============== No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies, that may of course be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility for that. All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements. 1.3. New Versions ================= This is the initial release of the Linux/GNU CAD CAM Project Design Document. The newest release can always be found at Linux/GNU CAD CAM Project homepage. The newest version of this Linux/GNU CAD CAM design document will always be made available on the project website, in a variety of formats: o HTML. o plain text. o compressed postscript (US letter format). o SGML source. 1.4. Credits ============ I would like to thank the following organizations and people for their help and input in writing this document. A thank you goes to sourceforge.net for hosting the project cvs depository and web site. Visit sourceforge.net at http://www.sourceforge.net/. Both of my daughters for their time in proofreading and format suggestions. The machine shop operators are acknowledged for spending time with me discussing their needs and requirements for CAD/CAM software. The emc, cad_cam_edm_dro, & gnu_cad_cam e-mail list members for their input and discussing their needs and requirements for CAD/CAM software. 1.5. Feedback ============= Feedback is most certainly welcome for this document. Without your submissions and input, this document will not progress. Please send your additions, comments and criticisms to the following email address : < terrylr@blauedonau.com>. 1.6. Translations ================= As soon as possible there well be Esperanto, French, German, and Spanish translations of the Linux/GNU CAD CAM documents. o Esperanto Translation The Esperanto translation is a work-in-progress. If you would be interested in helping with this translation please send an e-mail detailing your interest to the following e-mail address : < terrylr@blauedonau.com>. o French Translation The French translation is a work-in-progress. If you would be interested in helping with this translation please send an e-mail detailing your interest to the following e-mail address : < terrylr@blauedonau.com>. o German Translation The German translation is a work-in-progress. If you would be interested in helping with this translation please send an e-mail detailing your interest to the following e-mail address : < terrylr@blauedonau.com>. o Spanish Translation The Spanish translation is a work-in-progress. If you would be interested in helping with this translation please send an e-mail detailing your interest to the following e-mail address : < terrylr@blauedonau.com>. 2. Block Diagrams ***************** Given the excellent makeup of both end-users and programmers as members of the gnu_cad_cam e-mailing list it is necessary to begin the design document with high level block diagrams. As the design progresses the high level block diagrams increase in detail and information provided. I do realize that the beginning Top Level Block Diagrams will be boring to both potential end-users and programmers alike. I include them to illustrate how the design process is intended to progress. It is my belief that by the time a person has read to Level Six Detail Block Diagram that they will have a firm concept of: o What the Linux/GNU CAD CAM Project is all about and where it is heading. o Where they will be able to contribute either presently with the design stage, in the future during writing the final draft of the design document, during the coding stage, or testing stage. 2.1. Top Level Block Diagram ============================ This section explains the Top Level Block Diagram of the Linux/GNU CAD CAM project. The design process begins independent of the hardware architecture or the operating system. I would like to emphasize that there are very few assumptions made at this level of design. The Top Level Block Diagram does not look very interesting. There are only three blocks in the diagram and data flow is from left to right. o The Input block does not indicate where the input data is coming from. o The Process block only indicates that some processing is taking place on the input data but again there is no indication as to what processing is taking place. o The Output block does not indicate where the output data is going. It is clear that more detail needs to be added to the Top Level Block Diagram. It would be extremely difficult to begin writing any code for the project at the level of design. Figure 1. Top Level Block Diagram Top Level Block Diagram 2.2. Level One Detail Block Diagram =================================== This section explains the Level One Block Diagram of the Linux/GNU CAD CAM project. The first level of detail should add additional detail but not so much as to cause people to scratch their heads wondering what is going on. The Level One Block Diagram does not look very interesting either. There are only five blocks in the diagram and data flow is from left to right. o The File Input block indicates that input may come from files. There is no indication as to the type of files. Are the files: o Human Readable Files o Binary Files o The Human Input block indicates that input may come from a human. There is no indication as to how the human would interact with the Process block. Is the human input limited to: o Menu Driven Input o Command Line Input o The Process block still only indicates that some processing is taking place on the input data but again there is no indication as to what processing is taking place. o The File Output block does indicate that output may go to a file. There is no indication as to the type of files. Are the files: o Human Readable Files o Binary Files o The G-Code Output block does indicate that g-code programs may be output. There is no indication as to the which dialects of g-code may be output. Is the G-Code that is output: o Generic G-Code, that which is common to all controllers? o Specific to a particular yet unknown controller? It is clear that more detail needs to be added to the Level One Block Diagram. It would still be extremely difficult to begin writing any code for the project at the level of design. Figure 2. Level One Detail Block Diagram Level One Detail Block Diagram 2.3. Level Two Detail Block Diagram =================================== This section explains the Level Two Block Diagram of the Linux/GNU CAD CAM project. Each additional level of detail should add only enough detail so that it does not "swamp" people and thereby stifle a discussion of the design. The Level Two Block Diagram is now beginning to look interesting. There are now eleven blocks in the diagram and data flow is from left to right. o The File Input block has not changed from previous detail block diagrams. o The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process. o The Human Input block indicates that input may come from a human. The human input may be through: o Command Line Input o Menu Driven Input o Script Language Input o The Process block still only indicates that some processing is taking place on the input data. There is now implied that the process block is working with an internal representation of the input date, but again there is no indication as to what processing is taking place. o The File Output Translation block indicates that data will be converted from the internal representation to other representations and go to a file. There is still no indication as to the type of files. Are the files: o Human Readable Files o Binary Files o The Controller Specific Translation block indicates that g-code programs will be output and the dialect of g-code will depend on the specific controller selected, or generic g-code will be output. o The G-Code Output block indicate that g-code programs may be output. The dialect of g-code which is output depends on which controller specific translation was selected. o Generic G-Code, that which is common to all controllers. Still more detail needs to be added to the Level Two Block Diagram. It would still be difficult to begin writing any code for the project at the level of design. Figure 3. Level Two Detail Block Diagram Level Two Detail Block Diagram 2.4. Level Three Detail Block Diagram ===================================== This section explains the Level Three Block Diagram of the Linux/GNU CAD CAM project. Each additional level of detail should add only enough detail so that it does not "swamp" people and thereby stifle a discussion of the design. The Level Three Block Diagram is now beginning to look more interesting. There are now thirteen blocks in the diagram and data flow is from left to right. o The File Input block has not changed from previous detail block diagrams. o The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process. o The Human Input block indicates that input may come from a human. The human input may be through: o Command Line Input o Menu Driven Input o Script Language Input o The Process block indicates that there are at least two types of processing taking place on the input data. There is now implied that the process block is working with an internal representation of the input date. The two new blocks inside the Process block now indicate the crux of the project, i.e. CAD & CAM. o CAD -- Computer Aided Drafting/Design o CAM -- Computer Aided Machining/Manufacturing o The File Output Translation block indicates that data will be converted from the internal representation to other representations and go to a file. There is still no indication as to the type of files. Are the files: o Human Readable Files o Binary Files o The Controller Specific Translation block indicates that g-code programs will be output and the dialect of g-code will depend on the specific controller selected, or generic g-code will be output. o The G-Code Output block indicate that g-code programs may be output. The dialect of g-code which is output depends on which controller specific translation was selected. o Generic G-Code, that which is common to all controllers. Still more detail needs to be added to the Level Three Block Diagram. It would still be difficult to begin writing any code for the project at the level of design. Figure 4. Level Three Detail Block Diagram Level Three Detail Block Diagram 2.5. Level Four Detail Block Diagram ==================================== This section explains the Level Four Block Diagram of the Linux/GNU CAD CAM project. Each additional level of detail should add only enough detail so that it does not "swamp" people and thereby stifle a discussion of the design. The Level Four Block Diagram is now beginning to look more interesting. There are now eighteen blocks in the diagram and data flow is from left to right. o The File Input block has not changed from previous detail block diagrams. o The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process. o The Human Input block indicates that input may come from a human. The human input may be through: o Command Line Input o Menu Driven Input o Script Language Input o The Process block indicates that there are at least three types of processing taking place on the input data. There is now implied that the process block is working with an internal representation of the input date. The new blocks inside the Process block expand on the details specific to CAD, CAM, and Graphic routines. o The Object Manipulation Routines block indicates that both the CAD and CAM blocks share the need for these routines. o CAD -- Computer Aided Drafting/Design o CAM -- Computer Aided Machining/Manufacturing The new block inside the CAM block indicates that the toolpath routines are particular to CAM. o Graphic Routines Given the nature of the project it is natural to have these routines. o 2D graphic routines What type of graphics routines are these: o Rastor? o Vector? o 3D graphic routines What type of graphics routines are these: o 3D Wireframe? o 3D Surfaces? o 3D Solids? o 3D Constructive Solid Geometry (CGS)? o The File Output Translation block indicates that data will be converted from the internal representation to other representations and go to a file. There is still no indication as to the type of files. Are the files: o Human Readable Files o Binary Files o The Controller Specific Translation block indicates that g-code programs will be output and the dialect of g-code will depend on the specific controller selected, or generic g-code will be output. o The G-Code Output block indicate that g-code programs may be output. The dialect of g-code which is output depends on which controller specific translation was selected. o Generic G-Code, that which is common to all controllers. Still more detail needs to be added to the Level Four Block Diagram. It would still be difficult to begin writing any code for the project at the level of design. Figure 5. Level Four Detail Block Diagram Level Four Detail Block Diagram 2.6. Level Five Detail Block Diagram ==================================== This section explains the Level Five Block Diagram of the Linux/GNU CAD CAM project. Each additional level of detail should add only enough detail so that it does not "swamp" people and thereby stifle a discussion of the design. The Level Five Block Diagram is now beginning to look more interesting. There are now twenty-one blocks in the diagram and data flow is from left to right. o The File Input block has not changed from previous detail block diagrams. o The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process. o The Plugin Interface. Plugin/Modules technology is nothing new it is just becoming more common. If a new file format is required to be imported instead of rewriting the entire program, write a plugin for the file format. o The Human Input block indicates that input may come from a human. The human input may be through: o Command Line Input o Menu Driven Input o Script Language Input o The Process block indicates that there are at least three types of processing taking place on the input data. There is now implied that the process block is working with an internal representation of the input date. The new blocks inside the Process block expand on the details specific to CAD, CAM, and Graphic routines. o The Object Manipulation Routines block indicates that both the CAD and CAM blocks share the need for these routines. o CAD -- Computer Aided Drafting/Design o CAM -- Computer Aided Machining/Manufacturing The new block inside the CAM block indicates that the toolpath routines are particular to CAM. o Graphic Routines Given the nature of the project it is natural to have these routines. o 2D graphic routines What type of graphics routines are these: o Rastor? o Vector? o 3D graphic routines What type of graphics routines are these: o 3D Wireframe? o 3D Surfaces? o 3D Solids? o 3D Constructive Solid Geometry (CGS)? o The File Output Translation block indicates that data will be converted from the internal representation to other representations and go to a file. There is still no indication as to the type of files. Are the files: o The Plugin Interface. Plugin/Modules technology is nothing new it is just becoming more common. If a new file format is required to be exported instead of rewriting the entire program, write a plugin for the file format. o Human Readable Files o Binary Files o The Controller Specific Translation block indicates that g-code programs will be output and the dialect of g-code will depend on the specific controller selected, or generic g-code will be output. o The Plugin Interface. Plugin/Modules technology is nothing new it is just becoming more common. If a new controller is required to be supported instead of rewriting the entire program, write a plugin to support the new controller. o The G-Code Output block indicate that g-code programs may be output. The dialect of g-code which is output depends on which controller specific translation was selected. o Generic G-Code, that which is common to all controllers. Still more detail needs to be added to the Level Five Block Diagram. It would still be difficult to begin writing any code for the project at the level of design. Figure 6. Level Five Detail Block Diagram Level Five Detail Block Diagram 2.7. Level Six Detail Block Diagram =================================== This section explains the Level Six Block Diagram of the Linux/GNU CAD CAM project. Each additional level of detail should add only enough detail so that it does not "swamp" people and thereby stifle a discussion of the design. The Level Six Block Diagram is now beginning to look more interesting. There are now twenty-three blocks in the diagram and data flow is from left to right. o The File Input block has not changed from previous detail block diagrams. o The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process. o The Plugin Interface. Plugin/Modules technology is nothing new it is just becoming more common. If a new file format is required to be imported instead of rewriting the entire program, write a plugin for the file format. o The Help block indicates that there is help available. o The Process Block may activate the Help Block to: o Inform the user of potential probelms caused by exceeding the Maximum Feed Rates for the material selected. o Warn the user of cutting tool shank interference. o Warn the user that the toolpath needs to be edited to provide proper lead-in and lead-out. o Human activated help. The Human may activate the Help Block to: o Determine how to do something. o What G-Codes are available for the supported G-Code Controllers. o What Cutting Tools are available. o Library Block indicates that additional permanent information is necessary for the project. This additional information may be: o Material Physical Characteristics. o Maximum Feed Rates. o Material Safety Data Sheets. o Coolant Recommendations. o Canned G-Code Programs. o Common Cutting Tools. o The Human Input block indicates that input may come from a human. The human input may be through: o Command Line Input o Menu Driven Input o Script Language Input o The Process block indicates that there are at least three types of processing taking place on the input data. There is now implied that the process block is working with an internal representation of the input date. The new blocks inside the Process block expand on the details specific to CAD, CAM, and Graphic routines. o The Object Manipulation Routines block indicates that both the CAD and CAM blocks share the need for these routines. o CAD -- Computer Aided Drafting/Design o CAM -- Computer Aided Machining/Manufacturing The new block inside the CAM block indicates that the toolpath routines are particular to CAM. o Graphic Routines Given the nature of the project it is natural to have these routines. o 2D graphic routines What type of graphics routines are these: o Rastor? o Vector? o 3D graphic routines What type of graphics routines are these: o 3D Wireframe? o 3D Surfaces? o 3D Solids? o 3D Constructive Solid Geometry (CGS)? o The File Output Translation block indicates that data will be converted from the internal representation to other representations and go to a file. There is still no indication as to the type of files. Are the files: o The Plugin Interface. Plugin/Modules technology is nothing new it is just becoming more common. If a new file format is required to be exported instead of rewriting the entire program, write a plugin for the file format. o Human Readable Files o Binary Files o The Controller Specific Translation block indicates that g-code programs will be output and the dialect of g-code will depend on the specific controller selected, or generic g-code will be output. o The Plugin Interface. Plugin/Modules technology is nothing new it is just becoming more common. If a new controller is required to be supported instead of rewriting the entire program, write a plugin to support the new controller. o The G-Code Output block indicate that g-code programs may be output. The dialect of g-code which is output depends on which controller specific translation was selected. o Generic G-Code, that which is common to all controllers. Still more detail needs to be added to the Level Six Block Diagram. It would still be difficult to begin writing any code for the project at the level of design. Figure 7. Level Six Detail Block Diagram Level Six Detail Block Diagram 2.8. Project Timeline ===================== The below Project Timeline figure is a suggested timeline. This timeline is not written in stone or concrete. I would like to hear feedback concerning the timeline. Suggestions, comments, flames, criticisms, etc. Table 1. Project Timeline 3. Structure ************ A quick overview on how all parts fit together in the overall structure. As this type of design document is supposed to be as much for learning as a technical reference document I have arranged the structure to this end. For the designer of a system it is more useful to have the information presented in terms of the goals of this exercise than from the point of view of the logical layer structure of the devices themselves. Nevertheless this document would not be complete without such a layer structure the computer field is so full of, so I will include it here as an introduction to how it works. 3.1. Logical structure ====================== ___________________________________________________________ |__ User Interface __| |__ CAD CAM __| |__ Object Manipulation Routines __| |__ 2D 3D __| |__ Graphic Libraries __| |__ Math Libraries __| |__ Operating System (Linux, BSD, etc) __| ----------------------------------------------------------- 3.2. Document structure ======================= The basic document structure will be divided into three top level sections each with muliple sub-sections: o Input o File Input o Human Input o Library Input o Process o Object Manipulation Routines o CAD o CAM o Graphic Routines o 2D Graphic Routines o 3D Graphic Routines o 3D Wireframe Routines o 3D Surface Routines o 3D Solid Routines o 3D Constructive Solid Geometry Routines o Font Rendering Routines o LaTeX Font Rendering Routines o Unicode Font Rendering Routines o Truetype Rendering Routines o PostScript Rendering Routines o Output o File Output o G-Code Output o Printer Output 3.3. Suggested Reading ====================== Suggested Reading Bibliography ++++++++++++++++++++++++++++++ Books ***** 1994, Edited by Paul S. Heckbert, 0-12-336155-9, Academic Press, Inc., Graphics Gems IV. The Graphic Gems Series: A Collection of Partical Techniques for the Computer Graphics Programmer, Edited by Andrew Glassner, Academic Press, Inc.. 1995, Edited by Alan W. Paeth, 0-12-543455-3, Academic Press, Inc., Graphics Gems V. The Graphic Gems Series: A Collection of Partical Techniques for the Computer Graphics Programmer, Edited by Andrew Glassner, Academic Press, Inc.. Richard Stevens Burlington, 1973, 0-07-009015-7, McGraw-Hill Book Company, Handbook Of Mathematical Tables And Formulas. Frederick E. Giesecke, Alva Mitchell, Henry Cecil Spencer, and Ivan Leroy Hill, 1974, 0-02-342700-0, Macmillan Publishing Co., Inc., Technical Drawing: Sixth Edition. Les Piegl and Wayne Tiller, 1995, 3-540-55069-0, Springer-Verlag Berlin Heidelberg, The NURBS Book: Sixth Edition. 4. Technologies *************** Introduction of technology for the newbie with a few references to detailed works. 5. Implementation ***************** This section will be completed when the design stage is completed. 6. Maintenance ************** This section will be completed when first release of software is completed. 7. Advanced Issues ****************** One issue that needs to be considered at the very beginning is the issue of internationalization. I would argue that it is a wiser decision to design from the very beginning for the use of unicode and for internationalization. XML requires unicode which means that if the Help system were to be XML based unicode support is a given requirement. I would also argue that the Help system should be either html or xml based. 8. Further Information ********************** The Linux/GNU CAD CAM design document cannot describe everything; sometimes the user has to venture out on the net to get more information or just updates. There is wealth of information one should go through when setting up a CNC system. 8.1. News groups ================ Some of the most interesting news groups are: o Metalworking. o CNC machines. o Linux setup. Most newsgroups have their own FAQ that are designed to answer most of your questions, as the name Frequently Asked Questions indicate. Fresh versions should be posted regularly to the relevant newsgroups. If you cannot find it in your news spool you could go directly to the FAQ main archive FTP site. The WWW versions can be browsed at the FAQ main archive WWW site. 8.2. Mailing Lists ================== These are several e-mail lists which discuss CAD, CAD, EDM, DRO, hobbyist casting, hobbyist pattern making, blacksmithing, etc. Some relevant lists are: o Mailing List: gnu_cad_cam Purpose: To provide a forum to hold open discussions concerning the design of the Linux/GNU CAD CAM software. You do need to be a subscriber to send mail to this list. To subscribe, send mail to with the following in the body of the message: subscribe gnu_cad_cam To unsubscribe, send mail to with the following in the body of the message: unsubscribe gnu_cad_cam o Mailing List: emc Purpose: To provide support to questions and feedback from emc end-users. Purpose: To provide a forum to hold open discussions concerning the design of the Linux/GNU CAD CAM software. You do not need to be a subscriber to send mail to this list, although you do need to subscribe to receive mail from this list. To subscribe, send mail to with the following in the body of the message: subscribe emc To unsubscribe, send mail to with the following in the body of the message: unsubscribe emc o Mailing List: cad_cam_edm_dro You do need to be a subscriber to send mail to this listc. To subscribe, send mail to To unsubscribe, send mail to < cad_cam_edm_dro-unsubscribe@egroups.com> o Mailing List: kunstschmiede You do need to be a subscriber to send mail to this list. To subscribe, send mail to with the following in the body of the message: subscribe kunstschmiede To unsubscribe, send mail to with the following in the body of the message: unsubscribe kunstschmiede o Mailing List: theforge You do not need to be a subscriber to send mail to this list, although you do need to subscribe to receive mail from this list. To subscribe, send mail to with the following in the body of the message: subscribe theforge To unsubscribe, send mail to with the following in the body of the message: unsubscribe theforge 8.3. HOWTO ========== These are intended as the primary starting points to get the background information as well as show you how to solve a specific problem. Some relevant HOWTOs are EMC Handbook, Installation, EMC archives. The main site for these is the Linux CNC Project. 8.4. Local Resources ==================== To be filled in at a later date. 8.5. Web Sites ============== There are a huge number of informative web sites available. By their very nature they change quickly so do not be surprised if these links become quickly outdated. A good starting point is of course the Linux CNC Project home page, an information central for documentation, project pages and much more. o The Cathedral and the Bazaar : Analysis of how and why the Linux development model works! o Homesteading the Noosphere : A followup to The Cathedral and the Bazaar: the property and ownership customs of the open-source culture. o The Magic Cauldron : The third paper in the series analyzes the evolving economic substrate of the open-source. o What is Unicode? : An excellent description of unicode and why it is important to include unicode support in any project. o : The Enhanced Machine ControllerExcellent starting place for information about the emc software. o Basic Stepper Motor Concepts o Jones on Stepping Motors o Working With Stepper Motors o G Codes : G and M Codes for Milling and Turning o The NIST RS274NGC Interpreter - Version 3 o Gecko Drives o Servo To Go, Inc. o Bay-Com : Online catalog featuring products for the home machinist o The Home Shop Machinist : The Home Shop Machinist magazine is the very first publication to emerge for the individual whose principal passion is the shaping of metal into valuable items and visually beautiful objects. o Lindsay Publications : Unusual technical books, past & present. o Machinist's Workshop : Sister publication of The Home Shop Machinist o Sherline Products : Online catalog for machinists and hobbyists o Taig Tools : Manufacturer of quality machining tools Please let me know if you have any other leads that can be of interest. 9. Getting Help *************** In the end you might find yourself unable to solve your problems and need help from someone else. The most efficient way is either to ask someone local or in your nearest Linux user group, search the web for the nearest one or on one of the referenced e-mailing lists. Another possibility is to ask on Usenet News in one of the many, many newsgroups available. The problem is that these have such a high volume and noise (called low signal-to-noise ratio) that your question can easily fall through unanswered. No matter where you ask it is important to ask well or you will not be taken seriously. Saying just my stepper motors do not work is not going to help you and instead the noise level is increased even further and if you are lucky someone will ask you to clarify. Instead describe your problems in some detail that will enable people to help you. The problem could lie somewhere you did not expect. Therefore you are advised to list the following information about your system: CNC Hardware o Stepper/Servo Motors o Manufacturer of Stepper/Servo Motors o Model Numbers off the name plate of the Stepper/Servo Motors o Stepper/Servo Drivers o Manufacturer of the Stepper/Servo Drivers being used. CAD/CAM Software o Program(s) being used. o Software that shows the error (with version number or date) o Operating System, with version and patch/service pack level. o If running linux; Linux kernel version as well as possibles modifications and patches o Again if running linux; Kernel parameters, if any Computer Hardware o Processor o Chip set (LX, BX etc) o Bus (ISA, VESA, PCI etc) o Expansion cards used (Disk controllers, video, IO etc.) Bios/Operating System Software o BIOS (On motherboard and possibly SCSI host adapters) o LILO, if used o Linux kernel version as well as possible modifications and patches o Kernel parameters, if any o Software that shows the error (with version number or date) Peripherals o Type of disk drives with manufacturer name, version and type o Other relevant peripherals 10. Concluding Remarks ********************** The Linux/GNU CAD CAM project is large there is no doubt about that. It is my firm belief that the project is on the correct track and that by spending time up front drawing block diagrams, brainstorming, writing prototype code, which maay very well be tossed on the recycle heap, is the best way to proceed. Once there is a final draft of the design document project members will need to review it and determine if what has been designed will meet their needs and the needs of machine shop owner and/or operators. While it is hard to resist the temptation to jump right in there and start coding, it is necessary to resist that temptation. Once the final draft is finished there will be plenty of time to write code. Feedback is definitely needed to flesh out several more levels of detailed block diagrams. When project members and potential users agree upon the final draft of the block diagram design documents, further detailed information can be written to add further guidance to the project developers. 11. Frequently Asked Questions ****************************** This is just a collection of what I believe are the most common questions people might have. Give me more feedback and I will turn this section into a proper FAQ. 1. General Information Q: Why GNU General Public License and not a different opensource license? Q: What programming language will be used? 2. Project Specific Questions Q: What other operating systems will be supported Q: Why write both a CAD package and a CAM package? Q: OK, so why not split the project into two separate projects? Q: Why not find an opensource CAD project and team up with them? 1. General Information ++++++++++++++++++++++ Frequenctly Asked Questions of a general nature. Q: Why GNU General Public License and not a different opensource license? A: The GNU General Public License is the oldest and most recognized of the opensource licenses. From the Linux/GNU CAD CAM Project it is the easiest to understand. Q: What programming language will be used? A: The programming language has not been decided on at this point in the design. Making a decision concerning which programming langauage/langauges to use would limit the survey of what libraries and reusable source code are available. Once the final draft of the design is complete then programming langauges will be looked at. 2. Project Specific Questions +++++++++++++++++++++++++++++ Q: What other operating systems will be supported A: There is no answer to this question at this time since the project is in the design stages. Q: Why write both a CAD package and a CAM package? A: A survey was conducted of both CAD & CAM software currently available particularly for Linux. Several machine shop operators, hobbyist machnists, hobbyist blacksmiths, a model railroad hobbyist, professional patternmakers, hobbyist patternmakers, and a sheet metal shop operator expressed interest in having a combined package that is GNU gpled. Q: OK, so why not split the project into two separate projects? A: Again the project is in the design stage and no decision has been made one way or the other. The decision as to whether the project should be split into two separate projects under a common umbrella or keep them together as an integrated project will not be made until the design stage has been finished. Q: Why not find an opensource CAD project and team up with them? A: The best answer is that project has a different end-goal then the goal of the Linux/GNU CAD CAM project. They probably want to draw technical diagrams where we want to be able to make "chips". It would also require the other project team members to have a basic understanding of machine control and CNC machines. Depending on how big this FAQ gets, perhaps it would be worthwhile to have, say, the 5 most FAQs, and put the rest into an external FAQ. Comments? 12. Bits and Pieces ******************* This is basically a section where I am will be placing all the bits and pieces I have not yet decided where they should go, yet that I feel is worth knowing about. It is a kind of transient area. 13. Examples ************ Example stepper & servo driver designs and sample configuration files for The Enhanced Machine Controller and other relevant details will be placed here. A. GNU Free Documentation License ********************************* A.1. 0. PREAMBLE **************** The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. A.2. 1. APPLICABILITY AND ************************* DEFINITIONS *********** This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A.3. 2. VERBATIM COPYING ************************ You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. A.4. 3. COPYING IN QUANTITY *************************** If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. A.5. 4. MODIFICATIONS ********************* You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: o A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. o B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five). o C. State on the Title Page the name of the publisher of the Modified Version, as the publisher. o D. Preserve all the copyright notices of the Document. o E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. o F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. o G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. o H. Include an unaltered copy of this License. o I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. o J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. o K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. o L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. o M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version. o N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version . A.6. 5. COMBINING DOCUMENTS *************************** You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements." A.7. 6. COLLECTIONS OF ********************** DOCUMENTS ********* You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and dispbibute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. A.8. 7. AGGREGATION WITH ************************ INDEPENDENT WORKS ***************** A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document , on account of their being thus compiled, if they are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate. A.9. 8. TRANSLATION ******************* Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail. A.10. 9. TERMINATION ******************** You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. A.11. 10. FUTURE REVISIONS OF THIS ********************************** LICENSE ******* The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. A.12. Addendum ************** To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright © YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License". If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for Back-Cover Texts. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.