First, I should get something off my chest, the title is probably a little misleading. "Heavily parameterized 3D case design" might have been a more accurate, but dull title.
I recently kicked off laser cutting services on Anibit, and I plan to augment that service with a lot of specific product designs that I create. I'm a nut for automation and flexibility, and I'm deficient in intrinsic artistic talent. I determined that, as much as possible, I would design the physical aspects of my mechatronics creations in a way that I could easily make changes large and small, and not have to re-do much work.
My first area of focus was an
|Automatically rendered preview image.|
translate([10, 0, 0]) square([5, 10]);
draws a circle.... I'm kidding! It draws a rectangle.... I was serious that time.
The language supported by OpenSCAD is a C-style language with a functional programming slant. All variables are constant, sort of. You have all the usual suspect core features for a programming language, variables, loops, conditionals, functions, expressions, etc. It supports 2D and 3D modeling, and exports to DXF(2D) and STL(3D) file formats. The geometry creation essentially comes down to emitting the parts of your drawing via 2D and 3D primitives. You can build and re-use complex geometry as "modules". In addition, it supports a C-like feature of importing other files for use as shape and/or function libraries.
Where a programmatic approach like OpenSCAD has advantages over traditional graphical modeling tools are:
- Fully parameterized, with variables: you can define your design in terms of them, then only update the variable value definition, to automatically update all parts of the drawing that are dependent on that variable.
- it is very easy to write software that generates OpenSCAD input files.
- it is very easy to break your design into distinct files that can be pulled together into one design by the OpenSCAD compiler.
- it's very easy to have geometry created very differently based on the results of conditional expressions.
- Like software source code, the CAD files merge and play well with source control, even pure ASCII traditional CAD files are virtually unmergeable.
The main disadvantages are:
- It's not directly understood by the majority of other modeler software. FreeCAD can directly import and understand Scad files, but this is the exception, not the norm. You must export to other traditional CAD file formats, where many of the advantages of the parametric modeling are lost.
- There's the learning curve, might be higher for non-engineers of if math is not your thing.
- Certain drawing constructs require more work than in a graphical UI based CAD system. Fillets are Chamfers (rounded concave and convex corners, respectively) are an example of this. They are doable, they just require some clever math and layered boolean geometry operations.
- The latest stable version is missing a lot of features form the nightly build versions, that I _really want_, The nightly build version had some bugs that made it a deal killer for me.
I developed a set of Python scripts that take in configuration parameters, optionally parse PCB design files, and generate 2D drawings for using in laser cutting, and 3D drawings for using in visualization. I then used Blender3D to create some pseudo-raytraced photoreal rendering previews of a project case.
The workflow for the process is roughly:
|You don't have to squint to read this, click for a better view|
This is actually a lot simpler than it looks. And really, I don't have a lot of code to show, because most of the special sauce is really the architecture. This setup could be repeated for just about anything. My configuration input to my Python script is a JSON configuration file that outlines the parameter active for a given design build:
"name" : "Arduino with 20x4 LCD",
"do_render" : true,
"do_thick_part_fab" : false,
"do_thin_part_fab" : true,
"statements" : [
"hinged_top = 1;",
"footers_enabled = 1;",
"include_back = 1;",
"std_thin_acrylic_thickness = 2.30;",
"feat_lcd_mount = \"AF_20x4\";",
"feat_input_mount = \"NONE\";",
"feat_back_access = \"GENERIC_ARDUINO\";",
"feat_platform = \"ARD_UNO_R3\";",
"explode_offset = 0.1;"
The "do_render", "do_thick_part_fab", and "do_thin_part_fab" all determine which "passes" or operating modes to run the open scad design in. My box design is parameterized on material thicknesses, so I can for example make the bottom of the box thicker than the rest of the walls, and the design adjust accordingly. I make two separate laser templates, one for each thickness. The script also calls OpenSCAD to build an assembled 3D model of the whole design. If the "do_render" operation is active, the script will then launch Blender3D with a rendering script that runs inside Blender that imports the STL, and renders a photoreal scene to bitmapped images. This "operating mode" concept was borrowed from "example017.scad" that ships with OpenSCAD.
The "statements" block contains a list of OpenSCAD statements that get directly copied into the generated part of the OpenSCAD file.
All in all, I'm quite pleased with how it turned out. It's in the "proof of concept" phase right now, so it's full of hacks and hard-coded stuff, and It has some Windows-specific code in it too, though the entire set of tool dependencies are available on Linux and Mac, so there's no reason I couldn't make it to work on all platforms.
Here's a sample build though I used clear acrylic, instead of the orange transparent in the rendered version.
Background image in render used from:
Philippe "Philo" Hurbain (http://www.philohome.com/index.htm)
Coin model used in render from:
Oliver Wolfson (http://oliverwolfson.com/us-coin-3d-models/)