How do we both encourage RepRap mutations and stay focussed?

When I set RepRap up, I wanted it to mutate as people adapted the design. And I wanted those mutations to be made available to all. That's why I used the GPL licence.

But there's a downside to having lots of ideas and lots of versions of things: the core team is dedicated, but also few in number. I want to keep it few, too, for the time being, as increasing numbers makes more administration than it supplies useful work.

So - what's the best way to square the circle of encouraging lots of variation for natural selection to work on, and actually knowing what _we're_ working on? :-)

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

You've about got a working Darwin spec. Stick with it. You're already seeing speciation with the Arduino thing. I personally think that you need to stick to the Darwin design and get in a few 10's of thousands of hours printing time on a few dozen machines before you are going to know enough about where we need to go for either speciation or towards the oft spoken of but rarely discussed lately, Mendel.

I think we need to goad people into producing novel extruder attachments, and to provide plotter-style functionality so that the RepRap could, say, etch with a Dremel tool. These mutations do not affect the basic design of the robot very much, and so would allow a lot of development to be done without affectign the core focus.

Vik :v)

Make sure that the main reprap is the cheapest... or don't worry about it for now. With experimentation comes feedback... for instance, someone printed an extender for their reprap that... the z-extender... this resulted in bow-ing which resulted in better low-prints... in short... it was an accidental improvement. The most important part is not to get everyone working with the same reprap, but to collect data... which will be used to improve repraps more quickly. (Possibly have everyone send you a standard part...)

Data is, at this juncture, more useful than a stagnant design. You're already up to v3... do what you can to maintain backwards compatibility for as long as it benefits the project to do so.

And the most useful software I want was written by a single person. 3 game engines. Basically, encourage availability and don't worry about diversity. I want a reprap myself... but am unable and unwilling to pay the currently high premium... so I will wait. Encourage the collection of data and comparison... and if necessary try to create a 'beta testers' team of people who create/test experimental repraps... then pass their notes to the core team.

Many organizational structures work... which works for you?

I think keeping the community focused and advancing while allowing hardware to evolve is going to take the same thing in fab hardware that it took in computer science.

In two words, programming languages.

If we have a language for describing objects in detail in a fabber-independent way, then our parts files can be used with different fabbers and with different fabbing technologies, the same way a computer program written in a well-defined language can be run on different hardware.

So if someone has a Mendel, or a CNC Mill, or a CNC lathe, or a hobbing machine, or an arm robot with an extruder, or whatever -- they ought to be able to load the same object description file and push a button to see if their system ("compiler") can develop a local build plan for that part. And if not (that is, if a build plan cannot be produced with reasonable expectation of the finished part being within dimensional tolerances, required rigidity/durability, and other "important" specifications for that part file), it ought to emit an error message, within a minute, rather than spending time and material trying to do something beyond its capabilities.

With programming languages, computer science essentially redefined itself as being all about the software rather than all about the hardware. And it became, in principle, possible to get almost any software running on almost any machine by recompiling. Better software drove (and enabled) the development of better hardware.

Right now, fabbing tech is in its early days. We have g-code which is hopelessly device-dependent and doesn't say much important about the thing you're trying to build, and we have stl files which record its shape and color but nothing else important about it, such as dimensional tolerances or mechanical requirements. And after that, you're down to CAD files in formats that are pretty hit-or-miss as to what they record and whether they can be imported or exported to anything. None of these are a language where you can say what qualities are important and then say what range of values (or shapes, or functions) those qualities are allowed to have for this to be a valid example of the described part. None of these are a language where you can throw a switch from "METRIC" to "SAE" or vice versa and have related measurements for dimensions, holes and threads take on different values according to macros that access that value to decide whether they use, for example, M8 bolts or 5/16 inch bolts.

So the designs we're producing now are very brittle. They don't have much allowance for different parts availability and different local fabbing tech, and generally, they can't be converted. These designs therefore will die when the fabbing tech evolves, in the same way that first generation of software was lost when revisions to machine language interfaces came out. And it's the designs, not the fabbing tech, that ought to be the core of the community.

Bear

Quote

None of these are a language where you can throw a switch from "METRIC" to "SAE" or vice versa and have related measurements for dimensions, holes and threads take on different values according to macros that access that value to decide whether they use, for example, M8 bolts or 5/16 inch bolts.

The Prusa Mendel and the Huxley that Adrian is working on are both designed in Openscad. That is like a programming language and you can throw a switch to make an SAE Prusa or a metric Prusa.

---

[www.hydraraptor.blogspot.com]

Well, hooray for some progress. Seriously, that's a fundamental facility that was really needed.

Is the format stable? Will it survive revisions of their CAD software? Is there a documented semantics? Will someone be able to open these "Openscad" files in ten years, and if so will they mean the same thing they mean now? 'Cause if not, then we're just writing in the sand at low tide.

Bear

Bear Wrote:
-------------------------------------------------------
> Well, hooray for some progress. Seriously, that's
> a fundamental facility that was really needed.
>
> Is the format stable? Will it survive revisions
> of their CAD software? Is there a documented
> semantics? Will someone be able to open these
> "Openscad" files in ten years, and if so will they
> mean the same thing they mean now? 'Cause if not,
> then we're just writing in the sand at low tide.
>
> Bear

Those are all issues that exist for any CAD format. The only "format" that will survive are drawings with dimensions.

---

Help improve the RepRap wiki! Just click "Edit" in the top-right corner of the page and start typing. Anyone can edit the wiki!

it's very much like html, where the code creates the object. it's documented, and GPLed, so i think it's probably as compatible as it can be.

but it is relatively new, and just like html, people are likely going to extend and modify it in the future to improve it. it's probably the best thing you could build a model with right now, though, if you want it to be accessible in 10 years.

you will still need an interpreter for each machine, though. you'll always need something that looks at the model and determines how the specifics of the machine can make it, whether it be milling or printing.
[www.openscad.org]

Okay. I will go take a look at it.

If I think it's the kind of thing we need, or even the beginnings thereof, I will dedicate some serious effort to getting it to critical-mass - maybe by hosting a design collection or translating existing open designs into the format.

Bear

Okay, it's better than STL. It has flow-of-control, procedures, local variables, and variables with static and dynamic scope. That counts a lot; it makes a programming language, of sorts.

What it still has not, that a good format for a designed part needs, is a way to declare what materials it can be made out of and a way to declare what tolerance for error the measurements have.

And, of course, there is still no candidate language for representing things made from multiple parts, where the parts have to be made of different materials or have different properties, and have to be assembled into a functioning whole.

Bear

More years ago than I care to remember, I sort-of solved this problem. See here:

[people.bath.ac.uk]

The software is now moribund, but the idea of achieving all that you want by using OO techniques to extend a conventional language like C++ or Java to allow one to program solids in those still seems like a good one to me.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

... maybe a view into the object format of POVray will be of some interest: [povray.org]

They define many parameters of objects like material and macros (mostly relevant for displaying), what's a common methode to add future parameters to a predefined set of objects ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I think the POVRay scene modeling language has most of what we actually need. They're all about visual effects, but I can see using the texture and surface information for smoothness requirements and error allowance, and their 'materials' are named allowing the names of real materials to be used thus conveying mechanical as well as visual information.

And POVRay allows assemblies made of many different parts already, so it works as a language for full-objects as well as a language for individual parts.

One thing worth noting is that the internal representation of solids in a system is much more important than its API or interactive interface for long term. OpenSCAD is CSG (as was my SvLis system). POVRay (and most other systems) are BRep. If we want to represent, for example, objects with continuously varying internal properties like elasticity or conductivity then BRep is pretty much a non-starter. You need functional representation, and CSG moves pretty seamlessly into that.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Quote
Constructive solid geometry From Wikipedia, the free encyclopedia
One of the advantages of CSG is that it can easily assure that objects are "solid" or water-tight if all of the primitive shapes are water-tight. This can be important for some manufacturing or engineering computation applications. By comparison, when creating geometry based upon boundary representations, additional topological data is required, or consistency checks must be performed to assure that the given boundary description specifies a valid solid object.

A convenient property of CSG shapes is that it is easy to classify arbitrary points as being either inside or outside the shape created by CSG. The point is simply classified against all the underlying primitives and the resulting boolean expression is evaluated. This is a desirable quality for some applications such as collision detection.

Quote
Boundary representation From Wikipedia, the free encyclopedia
Compared to the constructive solid geometry (CSG) representation, which uses only primitive objects and Boolean operations to combine them, boundary representation is more flexible and has a much richer operation set. This makes boundary representation a more appropriate choice for CAD systems. CSG was used initially by several commercial systems because it was easier to implement. The advent of reliable commercial B-rep kernel systems like Parasolid and ACIS, mentioned above, has led to widespread adoption of B-rep for CAD. As well as the Boolean operations, B-rep has extrusion (or sweeping), chamfer, blending, drafting, shelling, tweaking and other operations which make use of these.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Chamfer, blending, drafting, shelling, and tweaking can all be done with FRep too. See

[hyperfun.org]

by Alexander Pasko and colleagues. But those are merely things designers want to do. As long as the underlying representation supports a rich enough geometry they will be possible somehow or other. The important thing is that that representation should allow the interior properties of things to be represented which, almost by definition, BRep cannot do.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Bob, interesting, I wonder if CoCreate is brep based. It doesn't suffer from the non-manifold problem of CSG and it allows direct editing with no retained history.

It is disappointing to find that OpenScad has similar issues to AOI with coincident faces, etc.

---

[www.hydraraptor.blogspot.com]

@Adrian: Unfortunately FRep has no program or source code to be downloaded unlike your svLis where the C++ source code can be downloaded.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Quote
nophead
It is disappointing to find that OpenScad has similar issues to AOI with coincident faces, etc.

True, but then POVRay is BRep based (based on what Adrian wrote) and has the same issue with coincident faces!

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

... in the introducion of POVray objects i can read:

Quote

2.4 Objects

Objects are the building blocks of your scene. There are a lot of different types of objects supported by POV-Ray. In the sections which follows, we describe "Finite Solid Primitives", "Finite Patch Primitives", "Infinite Solid Primitives", "Isosurface Object", "Parametric Object", and "Light Sources". These primitive shapes may be combined into complex shapes using "Constructive Solid Geometry" (also known as CSG).

The basic syntax of an object is a keyword describing its type, some floats, vectors or other parameters which further define its location and/or shape and some optional object modifiers such as texture, interior_texture, pigment, normal, finish, interior, bounding, clipping or transformations. Specifically the syntax is:

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

There's a difference between "objects supported by System-X" and the underlying representation used by System X. Every CAD system allows CSG operations to be done on objects, whatever the underlying representation. My point is that - for additive manufacturing - it would be really useful if the underlying representation was FRep/CSG.

I just pointed to Pasko's work to show that complex geometry can be done that way.

I would not recommend re-vivifying my SvLis system. If even I wanted to use it, I think I would write it again from scratch...

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Hi Adrian,

... hmm, so more something like XML with a wrapping syntax around embedded containers for various object formats

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Certainly an XML wrapping is how you would store the files. But that's not the important thing. The important thing is the data structure inside the geometric modeller that it creates that represents the 3D solids when it reads one of those files in, or when you use it to edit the geometry of an object. That would almost certainly be a tree holding a Boolean/Algebraic expression. That expression (which you would record in reverse polish in the XML) is a function: F(x, y, z). Everywhere in space that that function evaluates negative (by convention - see below) is inside your solid object. Everywhere it's 0 you are on the surface. And everywhere it's positive you are in air.

You can then have other associated functions. For example you might have a vector field, V(x, y, z) that defined a fiber orientation everywhere in space. You then build those fibres at some resolution inside your solid, and so on.

[The reason for the negative = solid convention is that then ∇ F gives you outward-pointing surface normals.]

... is there a common format for storing object data for mechanical/physical FEM-analysis?

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

The closest thing to universality is STEP, I think:

[en.wikipedia.org]

but this is not an area where I am up to date...

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Yes, Povray is immensely hackable. You can even develop a fill algorithm and have Povray automatically 3D-fill the space for you. I used a hacked version of Povray to design molecular components in Al2O3 at one point.

Also there are a fair few GUI tools that will output Povray (though watch it because some just spew out a triangle mesh).

I've used it for decades, and would love to see a Povray-based RepRap driver.

Vik :v)

I would like to suggest that we start to think in terms of modules rather than models.

Currently there is a tendency for us to have models e.g. Prusa which refer to specific whole reprap machine configurations.

The alternative notion of modules offers a more flexible structure which would improve the opportunities for mutations.

For example
We have multiple solutions for the design of extruder heads and there are calls for additional heads for alternative purposes. A Modular design approach would incorporate a module we could call "Carriage" which could be designed to comply with a minimum modular standard for Carriages.
e.g.
(a) Data-in connection socket
(b) Data-out connection socket
(c) Head connection bolt hole configuration

This illustrates the need for specifying upstream , downstream and parrallel module interfaces for connections, logic and mechanical devices. This approach is successfully used in the software industry and could, with substantial benefit, be applied in our own field. USB is a clssic illustration of the concept. We have a mechanical device standard, a logic standard & a connection standard which enables multiple devices to be used on computers incorporately vastly different design standards.

This approach would by way of example offer the designers of extruder devices to be able to offer a design which they know would be usable by any rerapper who has a system built in accordance with common modularity standards. Such an approach would encourage designers to offer adapters to facilititate the connection of any current design to modules. This gives us a structure which would, in theory, enable any module to dynamically ascertain the Mechanical, Logical and Connection [MLC Data] for all other modules in the system.

There is of course a major challenge for design and implementation but if we can do it the long term benefits for design, build, configuration and operation are outstanding for an open source system.

I believe this would be most easily achieved by an incremental method which slices and dices Reprap into large scale modules. Each module irrespective of type, could have a usb connector which would lay the groundwork for configuration master system which could then recognise the modules used to build any particular reprap machine. This would mean the MLC Data could be used to assist rapid configuration and testing of the whole system.

I could go on but I feel this is a good place to stop and seek out reactions.

David

This is a very good idea. I particularly like the idea of combining the specification of standard mechanical and electrical interfaces. Of course, we'd have to try to make those as future-proof as possible, without making them over-complicated. For example, one could imagine an extruder with about five controls and as many sensors, all requiring electrical signals. But it would be a bad idea to specify a big multi-way extruder connector as standard, as that would hamper simple small designs. Clearly local intelligence would always allow a three or four wire connection to anything, but might again be inhibiting to small simple designs that just need a motor and a way to turn it on and off.

I think it would be most interesting and useful if people started wiki pages with draft specifications for these, which could then be discussed here or on the reprap-dev mailing list.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Adrian Bowyer Wrote:
-------------------------------------------------------
> This is a very good idea. I particularly like the
> idea of combining the specification of standard
> mechanical and electrical interfaces. Of course,
> we'd have to try to make those as future-proof as
> possible, without making them over-complicated.
> For example, one could imagine an extruder with
> about five controls and as many sensors, all
> requiring electrical signals. But it would be a
> bad idea to specify a big multi-way extruder
> connector as standard, as that would hamper simple
> small designs. Clearly local intelligence would
> always allow a three or four wire connection to
> anything, but might again be inhibiting to small
> simple designs that just need a motor and a way to
> turn it on and off.
>
> I think it would be most interesting and useful if
> people started wiki pages with draft
> specifications for these, which could then be
> discussed here or on the reprap-dev mailing list.

IMHO we should start by designing a standard communications interface.This is the most significant module around which a viable system would be built. IMHO this would be best achieved using usb3. So every connector is the same and all intermodule connectors are the same. The high speed of USB combined with ease of sourcing, economy and availability of chipsets makes this a natural. I know it may need a few more wires for very simple devices (but wires can be available in standardised lengths) the economy of implementation and the benefits of the discipline and off the shelf standardisation are very strong arguments in its favour.

Do we have a USB "guru" willing and able to offer comments & support? I can see us needing a USB design group!

On another tack I would see a board dedicated to collecting, processing and distributing MLC data and possibly handling system configuration.

David Southwell
.

Edited 3 time(s). Last edit at 04/17/2011 10:40AM by vizion.