Talk:CAD-CAM Problem Statement - Revision history

ChuckH: /* Challenges */

2012-11-28T07:00:05Z

Challenges

← Older revision		Revision as of 07:00, 28 November 2012
Line 24:		Line 24:
	=== Challenges ===		=== Challenges ===
	* Non-graphical design editing		* Non-graphical design editing
	** Mechanical CAD - Interactive graphical input is the core of almost any CAD package. In contrast, we need to do a lot of automated parametric building. Can the primary CAD design files be text-based (e.g. OpenSCAD, implicitCAD, APT) so they are compatible with existing diff/mergetool and computer program build tools?		** Mechanical CAD - Interactive graphical input is the core of almost any CAD package. In contrast, we need to do a lot of automated parametric building. Can the primary CAD design files be text-based (e.g. OpenSCAD, implicitCAD, APT) so they are compatible with existing diff/mergetool and computer program build tools? How are geometric constraints (especially between different components of an assembly) represented?
	** Electrical CAD - Similar situation to above with schematic diagrams. Speculation: digital logic design has largely moved from graphical design to VHDL, verilog, etc. Could this work with electrical schematics, i.e. a user-friendly "netlist" format?		** Electrical CAD - Similar situation to above with schematic diagrams. Speculation: digital logic design has largely moved from graphical design to VHDL, verilog, etc. Could this work with electrical schematics, i.e. a user-friendly "netlist" format?
	** Circuit board layout - Big challenge, IMHO		** Circuit board layout - Big challenge, IMHO

ChuckH: /* Full project build tools */

2012-11-18T23:06:35Z

Full project build tools

← Older revision		Revision as of 23:06, 18 November 2012
Line 20:		Line 20:
	* '''automated build'''. Little or no human intervention in the toolchain (e.g. interactive graphical editing) to complete the task		* '''automated build'''. Little or no human intervention in the toolchain (e.g. interactive graphical editing) to complete the task
	* '''diff''' and '''mergetool''' functions for all engineering file types. You can't maintain a dynamic project without being able to inspect differences between versions.		* '''diff''' and '''mergetool''' functions for all engineering file types. You can't maintain a dynamic project without being able to inspect differences between versions.
			* '''testing'''. Programmers' "unit tests" and "regression tests" carry over into more general engineering analyses that can be automatically performed on every build (e.g. test for mechanical movement interferences, check stress levels with FEA, SPICE performance verification of electrical circuits).

	=== Challenges ===		=== Challenges ===

ChuckH: /* Full project build tools */

2012-11-18T22:29:21Z

Full project build tools

← Older revision		Revision as of 22:29, 18 November 2012
Line 13:		Line 13:

	=== Key features ===		=== Key features ===
	* flexible and powerful '''transitive dependency management'''. This captures within-module and between-module dependencies; it keeps track of how ~~changes effect~~ other parts of the product.		* flexible and powerful '''transitive dependency management'''. This captures within-module and between-module dependencies; it keeps track of how one change affects other parts of the product.
	* '''incremental build'''. If a feature change (e.g. plow attachment ~~point~~) does not affect others (e.g. hydraulic system components) then the un-changed components are not regenerated.		* '''incremental build'''. If a feature change (e.g. plow attachment location) does not affect others (e.g. hydraulic system components) then the un-changed components are not regenerated.
	** big savings of computational time on large projects		** big savings of computational time on large projects
	** very important for good design management: visibility of change impacts		** very important for good design management: visibility of change impacts

ChuckH: /* Full project build tools */

2012-11-18T22:26:25Z

Full project build tools

← Older revision		Revision as of 22:26, 18 November 2012
Line 33:		Line 33:
	* Apache Ivy, Ant		* Apache Ivy, Ant
	* OSGi		* OSGi
			http://en.wikipedia.org/wiki/List_of_build_automation_software

ChuckH at 22:15, 18 November 2012

2012-11-18T22:15:52Z

← Older revision		Revision as of 22:15, 18 November 2012
Line 19:		Line 19:
	** supports continued use of hand-generated documents (e.g. instructionals, narrative descriptions) as long as their underlying components are unchanged, and flagging for editing if components have changed.		** supports continued use of hand-generated documents (e.g. instructionals, narrative descriptions) as long as their underlying components are unchanged, and flagging for editing if components have changed.
	* '''automated build'''. Little or no human intervention in the toolchain (e.g. interactive graphical editing) to complete the task		* '''automated build'''. Little or no human intervention in the toolchain (e.g. interactive graphical editing) to complete the task
	* '''diff''' and '''mergetool''' functions for all engineering file types.		* '''diff''' and '''mergetool''' functions for all engineering file types. You can't maintain a dynamic project without being able to inspect differences between versions.

	=== Challenges ===		=== Challenges ===

ChuckH: /* Full project build tools */

2012-11-18T22:13:07Z

Full project build tools

← Older revision		Revision as of 22:13, 18 November 2012
Line 10:		Line 10:
	== Full project build tools ==		== Full project build tools ==

	(Ambitious speculation) There is a need to adopt the "build tool" concept from software development into CAD-CAM. Loosely speaking, you should be able to change a dimension or a few features of a full product (e.g. LifeTrak) design, type "make", and have a full set of production drawings, bill of materials, cut lists, g-code files, etc. for the revised version. (Sorry, we can't auto-generate the build videos.) AFAIK this is a long ways from anything currently available either open source or proprietary.		(Ambitious speculation) There is a need to adopt the "build tool" concept from software development into CAD-CAM. Loosely speaking, you should be able to change a dimension or a few features of a full product (e.g. LifeTrak) design, type "make", and have a full set of production drawings, bill of materials, cut lists, g-code files, etc. for the revised version. (Sorry, we can't auto-generate the build videos.) AFAIK this is a long ways from anything currently available either open source or proprietary. [[User:ChuckH\|ChuckH]] 23:13, 18 November 2012 (CET)

	=== Key features ===		=== Key features ===

ChuckH: /* Full project build tools */

2012-11-18T22:12:13Z

Full project build tools

← Older revision		Revision as of 22:12, 18 November 2012
Line 10:		Line 10:
	== Full project build tools ==		== Full project build tools ==

	(Ambitious speculation) There is a need to adopt the "build tool" concept from software development into CAD-CAM. Loosely speaking, you should be able to change a few features of a full product (e.g. LifeTrak) design, type "make", and have a full set of production drawings, bill of materials, cut lists, g-code files, etc. for ~~that~~ version. (Sorry, we can't auto-generate the build videos.) AFAIK this is a long ways from anything currently available either open source or proprietary.		(Ambitious speculation) There is a need to adopt the "build tool" concept from software development into CAD-CAM. Loosely speaking, you should be able to change a dimension or a few features of a full product (e.g. LifeTrak) design, type "make", and have a full set of production drawings, bill of materials, cut lists, g-code files, etc. for the revised version. (Sorry, we can't auto-generate the build videos.) AFAIK this is a long ways from anything currently available either open source or proprietary.

	=== Key features ===		=== Key features ===
	* flexible and powerful '''transitive dependency management'''. This captures within-module and between-module dependencies; it keeps track of how changes effect other parts of the product.		* flexible and powerful '''transitive dependency management'''. This captures within-module and between-module dependencies; it keeps track of how changes effect other parts of the product.
	* '''incremental build'''. If a feature change (e.g. plow attachment point) does not affect others (e.g. hydraulic system components) then the un-changed components are not regenerated.		* '''incremental build'''. If a feature change (e.g. plow attachment point) does not affect others (e.g. hydraulic system components) then the un-changed components are not regenerated.
	** ~~huge~~ savings of computational time on large projects		** big savings of computational time on large projects
	** very important for good design visibility of change impacts		** very important for good design management: visibility of change impacts
	** supports continued use of hand-generated documents (e.g. instructionals, narrative descriptions) as long as their underlying components are unchanged, and flagging for editing if components have changed.		** supports continued use of hand-generated documents (e.g. instructionals, narrative descriptions) as long as their underlying components are unchanged, and flagging for editing if components have changed.
	* '''automated build'''. Little or no human intervention in the toolchain (e.g. interactive graphical editing) to complete the task		* '''automated build'''. Little or no human intervention in the toolchain (e.g. interactive graphical editing) to complete the task

ChuckH at 22:10, 18 November 2012

2012-11-18T22:10:06Z

← Older revision		Revision as of 22:10, 18 November 2012
Line 1:		Line 1:
			== FreeCAD extensibility ==
	Concerning FreeCAD, it is an open software package that can be extended. There are provisions in the user interface to load and execute Python packages that have full access to the FreeCAD functionality and currently open data. This mechanism could be used to extend the existing functionality to include CAM file export. [[User:Mjn\|Mjn]] 13:57, 1 August 2011 (CEST)		Concerning FreeCAD, it is an open software package that can be extended. There are provisions in the user interface to load and execute Python packages that have full access to the FreeCAD functionality and currently open data. This mechanism could be used to extend the existing functionality to include CAM file export. [[User:Mjn\|Mjn]] 13:57, 1 August 2011 (CEST)

Line 6:		Line 7:

	"One of the recent discussions was about the need for more open tools (and helping folks use them). Historically the open-source hardware movement has been tool agnostic, as long as you release your design files in the tools you made them with, along with documentation, schematics, etc – you’re set. However, the goal is to ultimately have an open export format as well as open tools." [[User:Hosh\|Hosh]] 2011-09-10 0131 EST		"One of the recent discussions was about the need for more open tools (and helping folks use them). Historically the open-source hardware movement has been tool agnostic, as long as you release your design files in the tools you made them with, along with documentation, schematics, etc – you’re set. However, the goal is to ultimately have an open export format as well as open tools." [[User:Hosh\|Hosh]] 2011-09-10 0131 EST

			== Full project build tools ==

			(Ambitious speculation) There is a need to adopt the "build tool" concept from software development into CAD-CAM. Loosely speaking, you should be able to change a few features of a full product (e.g. LifeTrak) design, type "make", and have a full set of production drawings, bill of materials, cut lists, g-code files, etc. for that version. (Sorry, we can't auto-generate the build videos.) AFAIK this is a long ways from anything currently available either open source or proprietary.

			=== Key features ===
			* flexible and powerful '''transitive dependency management'''. This captures within-module and between-module dependencies; it keeps track of how changes effect other parts of the product.
			* '''incremental build'''. If a feature change (e.g. plow attachment point) does not affect others (e.g. hydraulic system components) then the un-changed components are not regenerated.
			** huge savings of computational time on large projects
			** very important for good design visibility of change impacts
			** supports continued use of hand-generated documents (e.g. instructionals, narrative descriptions) as long as their underlying components are unchanged, and flagging for editing if components have changed.
			* '''automated build'''. Little or no human intervention in the toolchain (e.g. interactive graphical editing) to complete the task
			* '''diff''' and '''mergetool''' functions for all engineering file types.

			=== Challenges ===
			* Non-graphical design editing
			** Mechanical CAD - Interactive graphical input is the core of almost any CAD package. In contrast, we need to do a lot of automated parametric building. Can the primary CAD design files be text-based (e.g. OpenSCAD, implicitCAD, APT) so they are compatible with existing diff/mergetool and computer program build tools?
			** Electrical CAD - Similar situation to above with schematic diagrams. Speculation: digital logic design has largely moved from graphical design to VHDL, verilog, etc. Could this work with electrical schematics, i.e. a user-friendly "netlist" format?
			** Circuit board layout - Big challenge, IMHO
			* Dependency analysis - Even within the programming world, automated dependency analysis is sometimes problematic. For general physical product designs this approaches a serious AI task! Automated support with manual dependency definitions seems more practical.

			=== Existing tools ===
			Computer programming build tools, especially in the Java environment, seem to be migrating toward higher and more generic functionality. Many have a "plug-in" architecture which could theoretically support non-programming task types, but not much seems to have been done with this.
			* Gradle
			* Apache Ivy, Ant
			* OSGi

Hosh at 05:31, 10 September 2011

2011-09-10T05:31:43Z

← Older revision		Revision as of 05:31, 10 September 2011
Line 5:		Line 5:
	This just dropped into my radar today: http://blog.makezine.com/archive/2011/09/what-is-geda.html		This just dropped into my radar today: http://blog.makezine.com/archive/2011/09/what-is-geda.html

	"One of the recent discussions was about the need for more open tools (and helping folks use them). Historically the open-source hardware movement has been tool agnostic, as long as you release your design files in the tools you made them with, along with documentation, schematics, etc – you’re set. However, the goal is to ultimately have an open export format as well as open tools."		"One of the recent discussions was about the need for more open tools (and helping folks use them). Historically the open-source hardware movement has been tool agnostic, as long as you release your design files in the tools you made them with, along with documentation, schematics, etc – you’re set. However, the goal is to ultimately have an open export format as well as open tools." [[User:Hosh\|Hosh]] 2011-09-10 0131 EST

Hosh: /* gEDA Initiative */ new section

2011-09-10T05:29:45Z

gEDA Initiative: new section

← Older revision		Revision as of 05:29, 10 September 2011
Line 1:		Line 1:
	Concerning FreeCAD, it is an open software package that can be extended. There are provisions in the user interface to load and execute Python packages that have full access to the FreeCAD functionality and currently open data. This mechanism could be used to extend the existing functionality to include CAM file export. [[User:Mjn\|Mjn]] 13:57, 1 August 2011 (CEST)		Concerning FreeCAD, it is an open software package that can be extended. There are provisions in the user interface to load and execute Python packages that have full access to the FreeCAD functionality and currently open data. This mechanism could be used to extend the existing functionality to include CAM file export. [[User:Mjn\|Mjn]] 13:57, 1 August 2011 (CEST)

			== gEDA Initiative ==

			This just dropped into my radar today: http://blog.makezine.com/archive/2011/09/what-is-geda.html

			"One of the recent discussions was about the need for more open tools (and helping folks use them). Historically the open-source hardware movement has been tool agnostic, as long as you release your design files in the tools you made them with, along with documentation, schematics, etc – you’re set. However, the goal is to ultimately have an open export format as well as open tools."