I've implemented programming languages before, so when I started
getting into fabbers I was looking for a programming language
for defining Things. I didn't find any. I'm thinking I'm going
to have to build one.
What we've got now is some languages for defining tool paths,
which we inherited from CNC mills, and some slightly more
advanced languages for defining shapes as geometric solids,
optionally with colors, which we inherited from modeling and
rendering software. There's nothing wrong with these, but
they don't address the issues that a language for defining
usable Things needs to address.
The tool path languages are like assembly languages in scope;
meaningless outside of the particular device they're intended
for, and identical copies of that device. The geometric-solid
languages are sort of like a very primitive programming language
with no abstraction facilities, no standardized error behavior
or conditions, and no system libraries; You can describe an
individual part made out of a single material, and the
description, with some automatic translation to the local
machine's language, means "the same" thing subject to errors
and variations in local implementation.
But the language doesn't let you say anything about the
material the part is made of, including which qualities are
absolutely necessary to its proper function. For example,
if a latch on a box needs to be magnetic, or if a circuit
in a flashlight needs to be conductive, or that the bulb
needs to produce light when given electricity, or that a
cushion needs to be made out of something soft or that
clothes need to be made out of something flexible and
reasonably durable.
And you can't specify in that language that it's an error if
these or other constraints are not met; That hinge parts, for
example, must be manufactured to at most 0.5mm tolerances and
out of materials having at least thus-and-such tensile and
shear strength. Even if you could, there's no standard
behavior if the error condition is detected on the local
machine (if the local fabber does not, in fact, have the ability
to shape things out of an adequate material or cannot do so to
within tight enough tolerances) - so your system will
cheerfully waste time and money fabbing hinge parts that
won't freaking work if you take them and try to put them
together into a hinge.
Furthermore, there's no "system library" which would allow you
to just specify "countersunk hinge, between 1.5cm and 2.5 cm
long, between 1.5 and 1 cm wide, suitable for thus-and-such
loading" and it would select one from an inventory of off-the-
shelf available parts, countersink a cavity for it to fit
into, drill the appropriate screw holes for the selected one,
and let you install the darn hinge yourself when assembling
the device. Likewise, battery boxes, nuts, bolts, alligator
clips, wires, chips, bulbs, switches, encoders, linear
actuators, motors, etc.... These are all off-the-shelf
parts and lots of them we can't (yet) directly fab. Having
a "system library" of such available parts would help immensely
in being able to describe the things we want our fabbers to
build or help us build. And when machines come along that
can fab those parts those designs or "thing files" would
still be valid; they'd just require fewer trips to the
hardware store and fewer steps of post part-fabbing
assembly operations.
And finally, there's no abstraction facilities that would
allow you to say, formally and unambiguously, how these
parts go together in final assembly -- which we're going
to have to deal with eventually if we want to have fabbers
that produce finished items.
Anyway, these are just some rambling thoughts on a Thing
Description Language and some of the basic facilities it
would need to provide. If others have more thoughts, I'd
love to hear them.
Bear
--
You received this message because you are subscribed to the Google
Groups "Bay Area RepRap" group.
To post to this group, send email to bay-are...@googlegroups.com.
To unsubscribe from this group, send email to
bay-area-repr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/bay-area-reprap?hl=en.
--
- Bryan
http://heybryan.org/
1 512 203 0507
--
You received this message because you are subscribed to the Google Groups "Open Manufacturing" group.
To post to this group, send email to openmanu...@googlegroups.com.
To unsubscribe from this group, send email to openmanufactur...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openmanufacturing?hl=en.
The SKDB project developers are still active in this space, but you're
right, there have been no new commits (i.e., we haven't forgotten to
push new stuff). The servers are down because one of the machines was
"confiscated" (not really), and uploading all of the data is a very
time consuming task, so I've just been uploading files whenever
someone asks for something specific from
designfiles.org/adl.serveftp.org.
We're also available in #hplusroadmap on irc.freenode.net.
designfiles.org/adl.serveftp.org.
www.webchat.freenode.net is a nice start for irc. No need to download a client.
--
You received this message because you are subscribed to the Google Groups "Open Manufacturing"...
Those are two different addresses- or at least they were, but that
server isn't up any more. There are a lot of links that point over
there, such as in the email archives, so that's why I was offering to
manually retrieve files upon request.
>> We're also available in #hplusroadmap on irc.freenode.net.
>
> I've never used irc, but it's popular in several open source communities, so
> it seems like I should try it out. I'll poke around on the git site a little
> more and try to get up to speed.
I look forward to that.
It wasn't really documentation :-). Everything of value directly
related to skdb is in the git repo; the other files are miscellaneous
things, like the paper archive I kept around.
http://github.com/kanzure/skdb
http://diyhpl.us/cgit/skdb
There are a lot of links that point over
there, such as in the email archives, so that's why I was offering to
manually retrieve files upon request.