Followup to my "Automated CAD Design" post.

I received a lot of positive feedback on my last post, and some of the ideas posted on the sites that picked it up gave me the inspiration to write this follow up. There were some good ideas and some questions posed so I thought I'd try to make  few addenda and clarifications.

Choice of toolchain.

I chose OpenSCAD mostly as the first thing that popped into my head. The nightly version (2014.03 as I write), is fairly stable. The output it generated was well received by most of the other tools I used it with, which included Blender3D, for rendering the preview images, MeshLab for debugging the geometry when I goofed something, and LibreCAD for loading the 2D DXF files to send to my laser cutter. I even used Elmer to do some rudimentary(and probably naive) stress sanity checks.

I did lament that some the really cool features in the bleeding edge version of OpenSCAD were not available, but the generated output of the newer version had some erroneous geometry. I've read on the OpenSCAD forums there may be some versions for download that don't have those bugs.

I had worked with OpenSCAD before, so I knew what it's capabilities and limitations were. I wasn't really tied to OpenSCAD, here are some alternative tools work very similarly. Ultimately, it came down to the devil I knew, and that it supported all of the features that were critical to me: easy to setup, mature and stable, bug free STL and DXF output, and allowing me to programmatically override the skeleton designs by emitting generated design code.



I also looked at alternative renderers and raytracers too. I had a heavy bias toward Blender 3D, since I have a lot of experience with it, and have written python scripts for it before.  The combination of its file-import support, good documentation, community support, and plugable rendering framework meant the sky was the limit for what I could do with it. I tried several renderers integrated with Blender, but in the end I used the default built in renderer, it was the best trade off of speed and quality.

Speed of the process. 

There are reports of OpenSCAD getting really slow when the designs get more complicated. I have not run into that issue in this case. Since the most complex parts of my design are all in 2D, which is only "extruded" to 3D as a final step, my gut says that the Boolean geometry operations are a lot less CPU hungry. I think the worst-case I was seeing about 10 seconds to generate the 3D STL models, and about 3 seconds for the 2D laser templates. This is on a decent, but not a beast of a machine. The Blender pseudo ray-trace part of the process took much longer, 10 minutes sometimes for a 1284*1024 image. I spent a lot of time trying to get that down, that involved playing with the base Blender scene properties, and playing with materials and lighting parameters.

Capturing the intermediate model results and dimensions.

As 'ansible' on Hacker News put it:

"The main difficulty I had was that it seems to be necessary to calculate everything. As a simple example, suppose I've got a triangle-shaped part, and stick the flat side of it on a square part. What's the distance from the tip of triangle to the opposite flat side of the square? OpenSCAD knows, in some sense, because it drew it. But inside my OpenSCAD script, I don't, and I have to calculate the geometry in my code.

If there was some way to specify and capture the position of that point (or whatever), then it would be much easier to connect parts together.

This was one of my problems as well. My workaround was to try to offload that when I could to the python script side of things. Since the python script knew where certain things were supposed to be, it could incorporate that in some of the emitted scad code. that part happening in this part of my diagram from last post:

Which was then #included into the main Scad file. This largely happened in my Gerber and Excellon processing/generation , since OpenSCAD scripts can't even remotely parse arbitrary text files. (I learned something new about Gerber/Exellon file formats in the process, I had never really paid attention to their details before, I never realized how similar they are to CNC/3D printer GCode!) I pulled random publicly available open source Gerbers from OSHPark for testing. I used Python code from Gerber2PDF for slurping the Gerber files, and I wrote my own primitive Excellon file parser.

The idea of using non-pure script parametric modelers. 

I know that many Autodesk products are incredibly scriptable. I know they offer many products that have "community" editions, and good on them for that. When I can, I try to get by with open source tools, and especially when it's not something fundamental to my everyday work. If I used CAD tools all day every day, I'd seriously consider getting it. My experience with "community" editions of commercial software is that I run into one or two little features that I need that aren't available unless you upgrade to a paid version. There is also the issue that some of the community type software licenses prohibit doing any commercial work with it.

I have a big affection for FreeCAD, I think it has potential to be to engineering modeling what Blender is to digital art modeling. I just don't use it very often, but I want to. FreeCAD can already import OpenSCAD files directly, and it has a very rich API and python scripting module. It may be possible to use FreeCAD in place of OpenSCAD and get a deeper level of control and interaction with the generated Geometry, it's on my list to look into.

--P