Close

The Source

A project log for SLS 3D Printer

3D printing, with lasers!

bfozbfoz 11/18/2014 at 06:000 Comments

At long last, I've finally posted the source code for Ester. This isn't actually the repository that I've been developing in. That one was called 'sintertest', and as you might expect, was only supposed to be a quick test. As with most such 'quick' projects, it grew. And grew, and grew, until it turned into an unwieldy mess. I wanted to give Ester a fresh start, so I created a new project and copied over the files from the latest prototype. I also wanted to take the time to write up some proper instructions for getting a development environment set up. That turned out to be harder than expected.

You see, I have this problem. I tend to do things the hard way. Especially if the hard way is also a new way. I know, it's a disease, but I just can't help it. Consequently, Ester's design is not the collection of CAD files that you might expect. No, it's all code. Ruby, to be exact.

If you've used OpenSCAD, then you understand the idea of code as CAD. If not, then think of it as writing a program that generates the CAD files so that you don't have to. It's the "Computer Aided" part of CAD, taken to the next level. Traditional CAD design is a lot of tedious work, and oftentimes it's a lot of tedious rework. If you've used the traditional CAD tools, you know that they're mostly a glorified version of the pencil and paper drawings of old. We've traded the drafting table for a monitor, but that's about as far as it's gone. With the rise of modern programming languages, we can now automate a lot of tedium inherent in the old ways. On top of that, all of the tools developed for managing software projects become useable for hardware projects too.

These ideas all seemed like a no-brainer to me. But then, I'm a programmer, so what would you expect? I looked at the other nascent solutions for "scripted CAD" and decided that there was much to contribute to this new idea. So, I set myself to creating the tools to do what I wanted. Ruby seemed like a natural choice because it has a history of being friendly to Domain Specific Languages, and that's exactly what I wanted. I wanted something that could be bent to the needs of the hardware developer, but had the power of a modern language as its foundation. And Ruby is all about being bent in weird ways.

Around the time I was starting that particular adventure, I found myself playing with lasers and burning holes in things. It didn't take much to put the two projects together. So, for the last 3 years, I've been developing a laser sintering printer while writing a Ruby-based CAD system on the side. Both projects have driven development of the other. In hindsight, that's probably not the best way of doing things. But it sure was fun.

Discussions