Talk:CAD-CAM Problem Statement

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