OpenSCAD tips for RepRap developers

From RepRap
Revision as of 15:39, 9 May 2015 by Zeograd (talk | contribs) (removed incorrect use of "vitamins")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

I was motivated to write this page by reading the OpenSCAD source for dozens of printed parts used in various 3D printers. If you are a developer, please take note of the following tips and guidelines for writing OpenSCAD code when designing your new 3D printer, extruder or any other part.

Use OpenSCAD!

OK, this may seem trivial, but there are many CAD experts that would rather use the latest version of some proprietary (and expen$$$ive) CAD package which they have probably been using for many years. Well, to these experts, I say: don't! If you are a RepRap developer, please use OpenSCAD. There is a learning curve for sure, but it takes at most a couple of days to learn the basics of OpenSCAD, and the advantages of using it will quickly become clear. Basically it makes collaborative work on Open Source hardware much, much easier.

If you still can't fall in love with OpenSCAD, there's also [Blender] for more artistic work and FreeCAD with usage patterns similar to many of the commercial, technical CAD applications. Note that while it is easy to export any design from OpenSCAD and import it into Blender or FreeCAD or any other Open Source or proprietary CAD program, there is no automated way to import an existing design into OpenSCAD (you'll have to manually reverse-engineer it).

Read the OpenSCAD source of your predecessors

Best way to learn how to design things properly!

Choose an Open Source license and stick to it

I prefer GPLV3, for various reasons.

Include a standard header with the name of the part, your name, date of publishing, license, etc

There is a minimum of documentation that is required for collaborative work to take place.

(add example of good header)

Use indentation

It makes the code easier to read and understand.

(add examples of none, bad and good indentation)

Use comments

It makes the code easier to understand and maintain/modify. Also, preferably, write your comments in English.

(add examples)

Use modules

It makes the code shorter and easier to read.

Use parameters

It makes the code easier to read and maintain/modify. Also, it goes without saying, use proper names for your parameters.

Use costly functions wisely

Minkowski comes to mind.

Some links

  • Open-Source Hardware FAQ
  • Check the Licenses category right here in this wiki (a search for licenses will take you there).