Things, for purposes of this blog post, means whatever people want to manufacture. IE, I’m using it in the sense of Thingiverse, rather than in the more usual sense where it’s barely more than a pronoun. So I’m going to use it with a capital T, just as a reminder.
One of the projects I think about from time to time, but have not really started on, is right at the confluence of two of my biggest interests, programming language implementation and making cool stuff. It is a programming language for describing Things, in sufficient detail for automatic fabrication. Right now the reprap community is primarily using STL files, which describe shapes. But there’s a heck of a lot more to fabbers than just extruding plastic and there’s a heck of a lot more to making Things than just making them the right shape.
My idea is that this formal description language should have enough power to specify a working template for an object, and that there should be a “fab compiler” to which you feed a file written in the description language. The fab compiler would be configured with knowledge of your fabber – that is, your fabrication capabilities and what parts you have in stock. It should then produce the information you need to build that Thing with as high a degree of automation (and at as low a cost) as possible.
If both your fabber and the fab compiler are absolutely beyond the current state of the art, and you don’t care much about saving money, then you’re Tony Stark and the fab compiler is Jarvis, and it knows how to use your fabber to do everything from milling mechanical parts to burning firmware into microcontrollers to doing electronic and mechanical assembly. Flying around in the suit saving people is trivial compared to building the system that builds the suits.
If your fabber is more humble and the fab compiler is not yet as developed – say, you having a reprap printer and the Thing Description Language is somewhere in its first ten years of revisions, it might mean it produces a program that loads STL files into slicer to make G-code for your printer, loads the G-code, asks you to make sure you have a spool of plastic loaded, and starts the build. Then it should print a Bill Of Materials for the many components your fabber cannot make, and hand assembly instructions and patterns for you to follow where you need to resort to hand tools like soldering irons, hammers, and wrenches.
At present the Reprap community, while they’re doing some awesome work, have not risen above the level of G-code and getting the slicer software to write G-code for generating the same tool paths (relative to the build) on machines having different geometry.
That’s important, but it’s only the very beginning of what needs to be done. Also, it’s kind of the wrong level of abstraction to be doing that with, but that’s kind of a trivial nitpick, I guess – treating STL files as source rather than output is to be expected at this stage of the development of fabbers.
A language for precisely describing Things would have to say a lot more than just shapes. First, it would have to specify margins of error for those shapes, because if the local fabber cannot even possibly produce tolerances tight enough to make something work, it’s a waste of time and materials to attempt it.
A language for describing Things would have to provide ways to specify important material properties, including but not limited to electrical and heat conductivity, modulus of elasticity, transparency, tensile and compressive strength, mass density, magnetism, and, you know, every material property that is sometimes important when you’re building Things.
Many Things are made from more than one material, and the differences between these materials are important. In a flashlight for example, the electrical conductors, the electrical insulators, the battery terminals, the body, and the lens all have different sets of important properties.
But, in many cases these properties are not mutually exclusive. For example, it might turn out that the body, the lens, and the electrical insulators can all be made out of exactly the same transparent plastic. A different subset of the material properties is important for each of those applications, and the Thing Description Language should limit its description of each material to the properties important to making that part. If the fab compiler notices that it can create all these parts out of the same plastic, that optimizes the build plan and it’s a good solution.
But it’s not the problem. Here’s what I mean when I talk about working at the wrong level of abstraction. The Thing is what the Thing Description Language describes. That’s the same for everybody, and it can be expressed in a portable language that everybody shares. That’s the problem to solve. How to build it? That depends on your local fabber, it’s different at every installation, and it’s what the fab compiler ought to be working out. And that’s the solution to the problem.
That’s the way it’s done in other computer languages. A program should describe a computation. Ideally, the program gives no information that isn’t necessary to the description of the problem. Then it’s up to the compiler, with its libraries, to work out exactly how to do that computation given the semantics of the language, the program, the local CPU, and the local attached hardware.
That is, the programmer should, as much as possible, be saying what to do, and the compiler should, as much as possible, be tasked with working out exactly how to do it.
In practice, solutions are always (over)specified by programs because it’s not really possible to come up with the infinitely smart compiler that can work out the “how” for any “what.” But we are making progress. “Sort” for example is now a language primitive or a library call, which means that people now generally don’t make a program stupid by coding a bad way to sort. Sorting, at least, is something that the compiler with its libraries can figure out how to do, so the programmer is better off just saying “what” rather than “how.”
Anyway, back to our Thing Description Language. The STL format is good for describing shapes, and that’s a good start. But sometimes there’s a part whose shape you shouldn’t specify because you can overspecify and create a bad shape accidentally, the way a programmer can overspecify and code a bad sort. Overspecifying a shape can make your build harder, slower, or more expensive.
Sometimes exact shape isn’t really important. For example, in the flashlight does the exact routing of the wires inside the case really matter? The only shape criteria the wire really has to meet are where the endpoints are soldered and what electrical connectivity exists between those endpoints. So, in the interest of specifying the problem rather than the solution and leaving the fab compiler free to find the solution that’s easiest for it to build, we’d like to find a way to describe the wire’s shape only in terms of what’s important about the shape.
Where the shape is important, STL has no way to specify what margins for error in producing exactly that shape are important, and a good Thing Description Language needs to have that. Second, it has to describe multiple shapes, each made out of a material some of whose physical properties are important. Third, between these shapes, we have surface interfaces, and we have to describe important properties about interfaces such as whether they are physically bonded and if so with what strength, whether slippage is desirable and if so with what degree of friction or wear, and how smooth and flat a surface needs to be.
Treatments such as electroplating, bluing, and galvanizing, which are technically very thin shapes made of additional materials, probably ought to be described instead as some kind of surface interface. Also, where at least one of the materials is specified as transparent, the surface between them may need to be described additionally in terms of color, reflectivity, and light diffusion.
Although the exact routing of the wire doesn’t matter, we still have to specify that it doesn’t cross the space where we want to put in batteries or through the space between the reflector and the lens. That’s fairly easy; we can just specify the battery, and the space between the reflector and lens, as parts made of air so that nothing else can be in the same location.
And, although the exact routing of the wire doesn’t matter, the insulator has to surround it at all non-endpoints, in whatever location it winds up. And that’s less easy. Again we’d like to have a way to describe the properties of a shape that are important, leaving the fab compiler room to find an easy, fast, cheap way to fulfill the properties, rather than describing a particular shape that could turn out to be slower, harder, or more expensive to build.
And then we need libraries. The libraries would be specifications for pre-fabricated parts that can be purchased, and those prefabricated parts are everything from TTL logic chips to arduinos, PCB boards, electrical switches and buttons, to nuts and bolts and washers and bearings and linear motion rails.
The Thing Description Language needs ways to specify or select a subassembly from the library. And it needs a way to leave substitutions possible whereever they are acceptable and result in an easier, cheaper, or faster build plan.
For example, if you live in Europe, an M8 nut and bolt are likely to be cheaper than a 3/8 inch nut and bolt, but if you live in the US, the almost-equivalent 3/8 inch nut and bolt are likely to be cheaper. So ideally, when told to optimize cost, and told further that parts interchangeability with a standard version isn’t important, the compiler should create a build plan using whichever kind of nut and bolt is cheaper in your own area.
But this substitution involves small adjustments in shape to other parts, so we need to know that those other parts can be changed in shape to at least that degree, and still have the properties they need to have.
So, you think that’s a good overview of what’s needed in a language to describe Things? I think it’s a pale beginning, and let me tell you a few reasons why. A good language for describing Things should to be able to describe clothes, and other things made out of completely flexible parts. It should be able to describe mercury switches, which have parts made out of liquid. And a bunch of other things with parts that for one reason or another, don’t even have particular shapes.
A good language for describing Things should be able to describe tolerances for error relative to nearby parts, which are likely to be much much tighter in large Things than tolerances for location error relative to far away parts. For example, if your Thing is a 30-foot boat, it doesn’t much matter if the inboard end of the jib is a quarter-inch nearer or further from your rudder, but it matters a heck of a lot if it’s a quarter-inch nearer or further from the bow, deck, and railing that it has to attach to directly. Describing Things in terms of absolute coordinates, with absolute margins for error, is overspecifying the requirements, and can result in extremely high costs or even in an inability to find a solution.
So that’s the basic problem of a Thing Description Language. Describe what’s important about the shapes. Describe what’s important about the materials those shapes are made of. Describe what’s important about the surfaces that interface between the shapes. Describe what’s important about any additional parts you need to build or assemble the Thing. And put it all together in a format sufficiently formal that a Fab Compiler can read it and figure out a build plan for different fabbers having different stocks of parts and different manufacturing capabilities.
Yeeeaah, good luck with that.
Anyway, to start on this project? My fabber is a small CNC mill. I have downloaded from Thingiverse a few STL files and milled them out of wood and bronze, and that’s actually pretty darn cool. I ought to write a fab compiler that eats at least enough of a Thing Description File to be useful in specifying CNC mill output, and produces Bills of materials and G-code tool paths for the mill. I ought to start putting together libraries of mechanical descriptions for commercial parts like nuts and bolts.
After that, I really ought to put together a reprap plastic extruder with the standard reprap electronics and repeat the process for that platform. And on a continuing basis, it would be a process of extending the fabber with new capabilities, then extending the language to utilize and formulate build plans using those capabilities.