2. Block Diagrams

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.

• The Input block does not indicate where the input data is coming from.

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

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

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.

• The File Input block indicates that input may come from files. There is no indication as to the type of files. Are the files:

  • Human Readable Files

  • Binary Files

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

  • Menu Driven Input

  • Command Line Input

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

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

  • Human Readable Files

  • Binary Files

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

  • Generic G-Code, that which is common to all controllers?

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

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.

• The File Input block has not changed from previous detail block diagrams.

  • The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process.

• The Human Input block indicates that input may come from a human. The human input may be through:

  • Command Line Input

  • Menu Driven Input

  • Script Language Input

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

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

  • Human Readable Files

  • Binary Files

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

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

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

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.

• The File Input block has not changed from previous detail block diagrams.

  • The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process.

• The Human Input block indicates that input may come from a human. The human input may be through:

  • Command Line Input

  • Menu Driven Input

  • Script Language Input

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

  • CAD -- Computer Aided Drafting/Design

  • CAM -- Computer Aided Machining/Manufacturing

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

  • Human Readable Files

  • Binary Files

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

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

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

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.

• The File Input block has not changed from previous detail block diagrams.

  • The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process.

• The Human Input block indicates that input may come from a human. The human input may be through:

  • Command Line Input

  • Menu Driven Input

  • Script Language Input

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

  • The Object Manipulation Routines block indicates that both the CAD and CAM blocks share the need for these routines.

    • CAD -- Computer Aided Drafting/Design

    • CAM -- Computer Aided Machining/Manufacturing The new block inside the CAM block indicates that the toolpath routines are particular to CAM.

  • Graphic Routines Given the nature of the project it is natural to have these routines.

    • 2D graphic routines What type of graphics routines are these:

      • Rastor?

      • Vector?

    • 3D graphic routines What type of graphics routines are these:

      • 3D Wireframe?

      • 3D Surfaces?

      • 3D Solids?

      • 3D Constructive Solid Geometry (CGS)?

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

  • Human Readable Files

  • Binary Files

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

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

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

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.

• The File Input block has not changed from previous detail block diagrams.

  • The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process.

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

• The Human Input block indicates that input may come from a human. The human input may be through:

  • Command Line Input

  • Menu Driven Input

  • Script Language Input

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

  • The Object Manipulation Routines block indicates that both the CAD and CAM blocks share the need for these routines.

    • CAD -- Computer Aided Drafting/Design

    • CAM -- Computer Aided Machining/Manufacturing The new block inside the CAM block indicates that the toolpath routines are particular to CAM.

  • Graphic Routines Given the nature of the project it is natural to have these routines.

    • 2D graphic routines What type of graphics routines are these:

      • Rastor?

      • Vector?

    • 3D graphic routines What type of graphics routines are these:

      • 3D Wireframe?

      • 3D Surfaces?

      • 3D Solids?

      • 3D Constructive Solid Geometry (CGS)?

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

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

  • Human Readable Files

  • Binary Files

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

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

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

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

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.

• The File Input block has not changed from previous detail block diagrams.

  • The File Input Translator block indicates that file input will be translated to an internal format to be used by the Process.

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

• The Help block indicates that there is help available.

  • The Process Block may activate the Help Block to:

    • Inform the user of potential probelms caused by exceeding the Maximum Feed Rates for the material selected.

    • Warn the user of cutting tool shank interference.

    • Warn the user that the toolpath needs to be edited to provide proper lead-in and lead-out.

  • Human activated help. The Human may activate the Help Block to:

    • Determine how to do something.

    • What G-Codes are available for the supported G-Code Controllers.

    • What Cutting Tools are available.

  • Library Block indicates that additional permanent information is necessary for the project. This additional information may be:

    • Material Physical Characteristics.

      • Maximum Feed Rates.

      • Material Safety Data Sheets.

      • Coolant Recommendations.

    • Canned G-Code Programs.

    • Common Cutting Tools.

• The Human Input block indicates that input may come from a human. The human input may be through:

  • Command Line Input

  • Menu Driven Input

  • Script Language Input

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

  • The Object Manipulation Routines block indicates that both the CAD and CAM blocks share the need for these routines.

    • CAD -- Computer Aided Drafting/Design

    • CAM -- Computer Aided Machining/Manufacturing The new block inside the CAM block indicates that the toolpath routines are particular to CAM.

  • Graphic Routines Given the nature of the project it is natural to have these routines.

    • 2D graphic routines What type of graphics routines are these:

      • Rastor?

      • Vector?

    • 3D graphic routines What type of graphics routines are these:

      • 3D Wireframe?

      • 3D Surfaces?

      • 3D Solids?

      • 3D Constructive Solid Geometry (CGS)?

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

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

  • Human Readable Files

  • Binary Files

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

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

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

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

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.