CAD Discussion - Revision history

Roli: /* from roleic */

2013-12-31T16:23:58Z

from roleic

← Older revision		Revision as of 16:23, 31 December 2013
Line 40:		Line 40:
	Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. a CAD and build system to efficiently turn source code into 3D-geometry 3. to easily manage many submitted changes from a large crowd.		Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. a CAD and build system to efficiently turn source code into 3D-geometry 3. to easily manage many submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool-chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Also the interaction of such a CAD with a build system to avoid rebuilding unchanged geometry is required. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. And it is high time for a dedicated open-mechanical -HW-tool-chain! How hard can it be? ;-)		As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool-chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Also the interaction of such a CAD with a build system to avoid rebuilding unchanged geometry is required. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. And it is high time for a dedicated open-mechanical -HW-tool-chain allowing large crowds to efficiently collaborate! How hard can it be? ;-)

	==Nick==		==Nick==

Roli: /* from roleic */

2013-12-31T16:22:44Z

from roleic

← Older revision		Revision as of 16:22, 31 December 2013
Line 38:		Line 38:
	Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code. This should be distributed, collected and version controlled not the geometry data. The scripting command language should be standardised rather than the 3D-geometry-data formats. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. This may take some time. So does compiling SW source code. But as in the so-called build-system of SW development you might keep the locally compiled object code (single 3D-geometry-objects) in separate files such that only the changed objects and depending ones have to be recompiled.		Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code. This should be distributed, collected and version controlled not the geometry data. The scripting command language should be standardised rather than the 3D-geometry-data formats. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. This may take some time. So does compiling SW source code. But as in the so-called build-system of SW development you might keep the locally compiled object code (single 3D-geometry-objects) in separate files such that only the changed objects and depending ones have to be recompiled.

	Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to easily manage many submitted changes from a large crowd.		Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. a CAD and build system to efficiently turn source code into 3D-geometry 3. to easily manage many submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool-chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Also the interaction of such a CAD with a build system to avoid rebuilding unchanged geometry is required. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. And it is high time for a dedicated open-mechanical -HW-tool-chain! How hard can it be? ;-)		As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool-chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Also the interaction of such a CAD with a build system to avoid rebuilding unchanged geometry is required. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. And it is high time for a dedicated open-mechanical -HW-tool-chain! How hard can it be? ;-)

Roli: /* from roleic */

2013-12-31T16:18:44Z

from roleic

← Older revision		Revision as of 16:18, 31 December 2013
Line 34:		Line 34:
	==from roleic==		==from roleic==

	It is sad to see the inspiring open-HW-movement dragging along designing 3D-geometry with inadequate tools like blender or sketchup. Discussing the features of existing CAD SW will not do. Important is what the OSE project and most other open mechanical HW projects really need. If you want more than a few people join in the development (crowd development) then you need a tailored free and open source development tool-chain which also allows easy model distribution and easy change management. This is not in existence as of now (end of 2013) and therefore also no large crowd development can be happening.		It is sad to see the inspiring open-HW-movement dragging along designing 3D-geometry with inadequate tools like blender or sketchup. Discussing the features of existing CAD SW will not do. Important is what the OSE project and most other open mechanical HW projects really need. If you want more than a few people join in the development (crowd development) then you need a tailored free and open source HW development tool-chain which also allows easy model distribution and easy change management. This is not in existence as of now (end of 2013) and therefore also no large crowd development can be happening.

	Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code. This should be distributed, collected and version controlled not the geometry data. The scripting command language should be standardised rather than the 3D-geometry-data formats. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. This may take some time. So does compiling SW source code. But as in the so-called build-system of SW development you might keep the locally compiled object code (single 3D-geometry-objects) in separate files such that only the changed objects and depending ones have to be recompiled.		Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code. This should be distributed, collected and version controlled not the geometry data. The scripting command language should be standardised rather than the 3D-geometry-data formats. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. This may take some time. So does compiling SW source code. But as in the so-called build-system of SW development you might keep the locally compiled object code (single 3D-geometry-objects) in separate files such that only the changed objects and depending ones have to be recompiled.

Roli: /* from roleic */

2013-12-31T16:16:42Z

from roleic

← Older revision		Revision as of 16:16, 31 December 2013
Line 40:		Line 40:
	Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to easily manage many submitted changes from a large crowd.		Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to easily manage many submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool-chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. How hard can it be? ;-)		As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool-chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Also the interaction of such a CAD with a build system to avoid rebuilding unchanged geometry is required. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. And it is high time for a dedicated open-mechanical -HW-tool-chain! How hard can it be? ;-)

	==Nick==		==Nick==

Roli: /* from roleic */

2013-12-31T16:12:55Z

from roleic

← Older revision		Revision as of 16:12, 31 December 2013
Line 34:		Line 34:
	==from roleic==		==from roleic==

	It is sad to see the inspiring open-HW-movement dragging along designing 3D-geometry with inadequate tools like blender or sketchup. Discussing the features of existing CAD SW will not do. Important is what the OSE project and most other open mechanical HW projects really need. If you want more than a few people join in the development (crowd development) then you need a tailored free and open source development tool chain which also allows easy model distribution and easy change management. This is not in existence as of now (end of 2013) and therefore also no large crowd development can be happening.		It is sad to see the inspiring open-HW-movement dragging along designing 3D-geometry with inadequate tools like blender or sketchup. Discussing the features of existing CAD SW will not do. Important is what the OSE project and most other open mechanical HW projects really need. If you want more than a few people join in the development (crowd development) then you need a tailored free and open source development tool-chain which also allows easy model distribution and easy change management. This is not in existence as of now (end of 2013) and therefore also no large crowd development can be happening.

	Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code ~~which~~ should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data.		Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code. This should be distributed, collected and version controlled not the geometry data. The scripting command language should be standardised rather than the 3D-geometry-data formats. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. This may take some time. So does compiling SW source code. But as in the so-called build-system of SW development you might keep the locally compiled object code (single 3D-geometry-objects) in separate files such that only the changed objects and depending ones have to be recompiled.

	Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.		Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to easily manage many submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. How hard can it be? ;-)		As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool-chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. How hard can it be? ;-)

	==Nick==		==Nick==

Roli: /* from roleic */

2013-12-31T15:54:34Z

from roleic

← Older revision		Revision as of 15:54, 31 December 2013
Line 34:		Line 34:
	==from roleic==		==from roleic==

	It is sad to see the inspiring open-HW-movement dragging along designing 3D-geometry with inadequate tools like blender or Discussing the features of ~~desired~~ CAD SW ~~and personal preferences alone is~~ not ~~very helpful~~. Important is what ~~serves~~ the OSE project ~~best. OSE is a~~ open ~~source hardware project. Therefore also the hardware data must be open source~~. If you want more than a few people join in the development (crowd development) then you need free and open source development ~~tools~~ which also ~~allow some sort of~~ change management. This is not in existence as of now (end of 2013) and therefore also no large crowd development can be happening. How should such a change mgmt. work? Similar to software projects. The electronic master design data should be downloadable for everybody. They should be changeable by readily available tools or tool chains. And changes from one change status to another should be detectable or even better they should be made visible. Moreover, changes from different designers should be easily merged into an updated master design data set. Only with such a process you can handle accepting (or turning down) design changes from a real crowd i.e. from more than a dozen designers.		It is sad to see the inspiring open-HW-movement dragging along designing 3D-geometry with inadequate tools like blender or sketchup. Discussing the features of existing CAD SW will not do. Important is what the OSE project and most other open mechanical HW projects really need. If you want more than a few people join in the development (crowd development) then you need a tailored free and open source development tool chain which also allows easy model distribution and easy change management. This is not in existence as of now (end of 2013) and therefore also no large crowd development can be happening.

	~~Does such a system exist? Not quite. That is why open HW projects have difficulty attracting large crowds.~~		Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data.
	Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD, ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly ~~highlight~~ the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...		Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.

			As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-geometry-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD and ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlighting the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...It is time to change that. How hard can it be? ;-)

	==Nick==		==Nick==

Roli: /* from roleic */

2013-12-31T15:41:02Z

from roleic

← Older revision		Revision as of 15:41, 31 December 2013
Line 34:		Line 34:
	==from roleic==		==from roleic==

	Discussing the features of desired CAD SW and personal preferences alone is not very helpful. Important is what serves the OSE project best. OSE is a open source hardware project. Therefore also the hardware data must be open source. If you want more than a few people join in the development (crowd development) then you need free and open source development tools which also allow some sort of change management. This is not in existence as of now (end of 2013) and therefore also no large crowd development can be happening. How should such a change mgmt. work? Similar to software projects. The electronic master design data should be downloadable for everybody. They should be changeable by readily available tools or tool chains. And changes from one change status to another should be detectable or even better they should be made visible. Moreover, changes from different designers should be easily merged into an updated master design data set. Only with such a process you can handle accepting (or turning down) design changes from a real crowd i.e. from more than a dozen designers.		It is sad to see the inspiring open-HW-movement dragging along designing 3D-geometry with inadequate tools like blender or Discussing the features of desired CAD SW and personal preferences alone is not very helpful. Important is what serves the OSE project best. OSE is a open source hardware project. Therefore also the hardware data must be open source. If you want more than a few people join in the development (crowd development) then you need free and open source development tools which also allow some sort of change management. This is not in existence as of now (end of 2013) and therefore also no large crowd development can be happening. How should such a change mgmt. work? Similar to software projects. The electronic master design data should be downloadable for everybody. They should be changeable by readily available tools or tool chains. And changes from one change status to another should be detectable or even better they should be made visible. Moreover, changes from different designers should be easily merged into an updated master design data set. Only with such a process you can handle accepting (or turning down) design changes from a real crowd i.e. from more than a dozen designers.

	Does such a system exist? Not quite. That is why open HW projects have difficulty attracting large crowds.		Does such a system exist? Not quite. That is why open HW projects have difficulty attracting large crowds.
	Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.		Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD, ImplicitCAD. If the open-mechanical-HW movement does not bother to develop a tool chain matching their needs it will not take off like the open-SW and		As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD, ImplicitCAD. If the open-mechanical-HW-movement does not bother to develop a tool chain matching their needs it will not take off like the open-SW and the open-electronic-HW-movements did by creating their own dedicated tool chains. The most important missing link in the mechanical-HW-tool-chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly highlight the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what is needed. However too many mechanical engineers seem to back away from SW development...
	the open-electronic-HW movements did by creating their own dedicated tool chains. The most important missing link in the mechanical HW tool chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly ~~high light~~ the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what ~~they need~~. However too many mechanical engineers seem to back away from SW development...

	==Nick==		==Nick==

Roli: /* from roleic */

2013-12-31T15:29:22Z

from roleic

← Older revision		Revision as of 15:29, 31 December 2013
Line 39:		Line 39:
	Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.		Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing ~~the~~ geometry ~~next to each other~~. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD, ImplicitCAD. If the open-mechanical-HW movement does not bother to develop a tool chain matching their needs it will not take off like the open-SW and		As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing source code and geometry side by side. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD, ImplicitCAD. If the open-mechanical-HW movement does not bother to develop a tool chain matching their needs it will not take off like the open-SW and
	the open-electronic-HW movements did by creating their own dedicated tool chains. The most important missing link in the mechanical HW tool chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly high light the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what they need. However too many mechanical engineers seem to back away from SW development...		the open-electronic-HW movements did by creating their own dedicated tool chains. The most important missing link in the mechanical HW tool chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly high light the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what they need. However too many mechanical engineers seem to back away from SW development...

Roli: /* from roleic */

2013-12-31T15:28:01Z

from roleic

← Older revision		Revision as of 15:28, 31 December 2013
Line 37:		Line 37:

	Does such a system exist? Not quite. That is why open HW projects have difficulty attracting large crowds.		Does such a system exist? Not quite. That is why open HW projects have difficulty attracting large crowds.
	Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The 3D-geometry-data ~~can be rebuilt locally from the source~~. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes ~~can~~ be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a ~~system~~ not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.		Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The actual CAD tool would act like a compiler or interpreter by locally turning the source code into 3D-geometry-data. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes could be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. Only the files which have changed would need to be distributed. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a tool not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing the geometry next to each other. FreeCad and ~~Open~~ are candidates. With more limitations also Salomé,		As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing the geometry next to each other. FreeCad and PythonOCC are candidates. With more limitations also Salomé, OpenSCAD, ImplicitCAD. If the open-mechanical-HW movement does not bother to develop a tool chain matching their needs it will not take off like the open-SW and
			the open-electronic-HW movements did by creating their own dedicated tool chains. The most important missing link in the mechanical HW tool chain is a open CAD tool working with text source code files and directories, visualizing changes of two designs and possibly high light the relevant source code if a part of a 3D-geometry is selected in the graphical window. Such a tool chain will have to be developed by mechanical engineers because only they know what they need. However too many mechanical engineers seem to back away from SW development...

	==Nick==		==Nick==

Roli: /* from roleic */

2013-12-31T15:07:39Z

from roleic

← Older revision		Revision as of 15:07, 31 December 2013
Line 39:		Line 39:
	Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The 3D-geometry-data can be rebuilt locally from the source. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes can be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a system not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.		Current CAD files save the 3D-geometry-data. And the most often used transfer formats like STEP and IGES also contain 3D-geometry-data. These files are bulky, difficult to share over the internet and contain only dumb 3D data without parametrization etc. In terms of SW development 3D-geometry-data corresponds to compiled executables. However in open SW projects they manage source code and its changes not executables for good reasons. In 3D-CAD the source code corresponds to the sequence of commands that created the 3D-geometry-data. Some CAD-systems are scriptable. The scripts creating the 3D-geometry-data are the source code which should be distributed, collected and version controlled. The scripting command language should be standardised rather than the 3D-geometry-data. The 3D-geometry-data can be rebuilt locally from the source. Since these CAD scripts are text they can be managed like software source code e.g. with existing distributed version control software like git or mercurial. Changes can be diff'ed and merged. In the best case sub-assemblies could be filled in different source files and sub-directories just like in open SW development. This process has been proven even in very large open SW projects like the Linux Kernel. If this can be implemented then you would have much better change mgmt than all commercial PDM systems provide for big money! Why does such a system not yet exist in the commercial world? Because the commercial CAD vendors don't want standardized script languages because their customers would no longer be locked into their product and could easily change CAD tools. But for open source HW projects this is essential. 1. to be able to distribute compact source code over the internet and 2. to manage submitted changes from a large crowd.

	As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing the geometry next to each other.		As a starting point existing open source CAD systems with a scripting language could be used. Ideally they have a source code window and a graphical 3D-window showing the geometry next to each other. FreeCad and Open are candidates. With more limitations also Salomé,

	==Nick==		==Nick==