How do we both encourage RepRap mutations and stay focussed?

As I say - personally I am against a standard that will require all devices in the machine to have their own electronics. Before you know where you are, you start requiring every axis endstop to have a microcontroller attached :-)

The other thing to think about on the electronics side is current. Heated beds need about 100 W. That has to be accommodated by any standard.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Unless we can print this interface, it's going to be an extra set of parts, costs, and complexity - particularly for people on a budget who only want one print head to get going with. So I'd suggest we make sure there is a "manual" option.

The connector I now use is simply a couple of lengths of terminal strip joined by short lengths of thick wire or trimmed nails. Undo all the screws on one side, and pull the other strip out with all the nails attached. It is very robust, simple, cheap and available.

Vik :v)

VikOlliver Wrote:
-------------------------------------------------------
> Unless we can print this interface, it's going to
> be an extra set of parts, costs, and complexity -
> particularly for people on a budget who only want
> one print head to get going with. So I'd suggest
> we make sure there is a "manual" option.
> Vik :v)

I agree with Vik, 80%+ of the people I help get started in RepRap are in full price minimalization mode. That's why most RepRap folk have effectively Zero interest in the Ultimaker Ramps or Gen4. They want Ultimachine RAMPS or Sanguinololu.

No matter what's "best" for the community, RepRap is evolving like all things to a form which is more replication friendly. Anything that adds even a small about of cost to the machine at this point is likely going to be ignored by the majority of the community.

---

repraplogphase.blogspot.com

I agree about cost - it's the second most important aspect of the machine. The most important is how easy it is to copy, which more-or-less equates to how easy it is to put together and make work. That we can improve...

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Adrian Bowyer Wrote:
-------------------------------------------------------
> As I say - personally I am against a standard that
> will require all devices in the machine to have
> their own electronics. Before you know where you
> are, you start requiring every axis endstop to
> have a microcontroller attached :-)
>
> The other thing to think about on the electronics
> side is current. Heated beds need about 100 W.
> That has to be accommodated by any standard.

OK -- I think I may have not been careful enough in my description to make sure everyone understands the concept of modularity with which I am familar. I am going to make a brief response because I have a busy day coming up but see a reply is needed before everyone runs away the notion that I am describing an authoritarian system from hell!!

Effective standards do not imply a requirement for a total system to adopt them. Think about personal computers, laptops, cell phones & kindles. All of them use the USB standard as a module to improve the functionality of the device. There is a whole host of other standards dealing with all sorts of modules which are incorporated within aany one particular system configuration. There is nothing that says any module is "required". Each time a "Standard" is adopted by the designer of a device as a module it has only been included because the designer sees there is value in doing so. Each inclusion happens on merit.

Laptops use USB because users can easily connect their mobile computers to devices (e.g a device on someone's desk), cell phones use them so they can connect to speakers or be recharged etc etc. There is no obligation on the manufacturers of such devices to offer USB but who would want to buy devices of this type that do not comply with USB standards? Standard compatible moduiles are incorporated in systems where their inclusion adds value.

IMHO the challenge Adrian gave us by starting this thread is very real. The growth and success of the PC and related systems offers us a model for managing RepRap mutations. Imagine the computer world without standards which can be adopted by any designer. Imagine in ten years time a world with ten thousand RepRap designs without interchangeable modules and no standards! That is where I believe we are heading unless we pay immediate attention to the creation of standards which facilitate modular development and interchangeability of modules. In other words we start to think of reprap machines as systems built up from interchangeable modules.

My original posting envisages the [MLC Data] "Standard" as a model for defining the kind of standards we need for a RepRap world. A modular system (and accompanying standards) has to earn its spurs not be imposed. When it is seen to be appropriate a designer can apply a relevant standard to assist the design process. That is exactly what happened with usb. Modularity also leads to a reduction in design and build costs due to any need to meet arbitrary differences in MLC configurations. These occur when mutations are whimsical and have no modular standard references. Imagine what would happen if there were no standards for a PC mouse! Standards are therefore adopted to the extent designers/builders & users appreciate their added value.

I propose a modular standards approach because my experience leads me to conclude it is the most logical way to answer Adrian's question "How do we encourage RepRap Mutations and stay focussed". The adoption of modularity can, if the standards are well designed, facilitate that process. Designers/Builders & Users will only add MLC modules where there is a clear benefit in doing so and where the cost:benefit ratio is attractive. On the other hand Designers/Builders who, for commercial or other reasons, do not favour an open system (where modules made by anyone can compete on equal terms for adoption within any Reprap system configuration) are most likely to object.

The systems benefits of modularity and open standards accord with the RepRap open system goals.

For example carriages will only adopt a mechanical design standard if there is benefit in so doing. Such a benefit might be the ability to attach alternative heads with a mechanical connection that accords with the M (Mechanical) portion of the relevant MLC standard. It would also be able to offer a signalling connection if the carriage meets the C (connection) portion of the relevant MLC Standard. The head would be able to take advantage of the C portion if the head also meets the C portion of the relevant standard. The same comments apply to the L (Logic) portions of the relevant standards. Standards do not have to be inflexible e.g. think of the different connectors used for USB. They all comply with the standards and modules (adapters) are made which make it possible to match all differing connector variants.

Turning to power. IMHO the MLC standards could be designed to assist designers/builder/users determine the power requirements for each module and determine whether a subsidiary power unit would be required to meet the power requirements in the event that the sum of the powers required by all modules exceeds the power from a central power unit. This implies offering standards for power modules and power distribution which designers/builders could match. A power module could interface with MLC modules to gather information about the system power requirements. This does imply separating standards for for "signal" power from "drive" power. The practical advantage of implementing this division is a reduction in chip frying opportunities!

In effect I am proposing we think of creating MLC standards on an incremental basis starting with key RepRap Building blocks and include in our standards development provision for sub-modules or even sub-sub-modules. Signal Power and Drive power are examples of building blocks. The possibility of modules offer combined functionality has to be considered e.g both signal power and drive power. A particular Drive power design might offer the facility for attaching/communicating with a sub-module to monitor drive power sub-units.A Standard for such functionality might be included in an MLC standard for Drive Power Modules.

I see designers/builders offering the MLC as an optional extra modules for include in builds. This satisfies the need for minimal cost along with simultaneous provision of upgrade paths. The problem with our current total system design approach is the implicit lack of interchangeability without redesign or re-engineering. This leads to a waste of design skills and wheel reinventions. The modular approach means that each element which has a MLC system is a module available to any mutation originally built to MLC Standards or for which an MLC adapter or upgrade is available.

What modularity does is to encourage designers to focus on making improvements to the modules they are designing/building/improving with the knowledge that modularity will make it much easier for diversely designed systems to make use of those modules. It also means that the scope of design requirements is reduced to the barest minimum especially when that module can be supported by functions fulfilled by other modules with which it can interface.

That is how the PC world met the challenges which came from massive growth and developmental mutations. The demand for upgrade paths (either adapters or replacement modules) is also easily met in a similar way to the PC. This means the combination of modularity and standards facilitates organic growth path to meet the mutational challenge Adrian identified.

Standards are not prescriptions to be enforced but voluntarily adoptable tools to facilitate design, build & operation for diverse and mutated systems. This will, in turn, lead to lower costs, easier configuration, cheaper systems, greater competitiveness, simpler adoption procedures and facilitate standardised documentation for users.

My two pennorth

Cheers

David Southwell

Edited 25 time(s). Last edit at 04/18/2011 01:16PM by vizion.

I agree that standardizing interfaces is the way to go.. and I think PCs are a perfect example of what we want to do. Not because PCs have standards that never change, but preceisely because they DO change -- they slowly morph over time to meet the new needs of users. As new standards get supported, there's almost always a transition period where systems support both old and new stardards at the same time.

I think this is a perfect model for reprap. Break the overall system into pieces that fit together with standardized, documented, version-numbered interfaces to foster interchangeable components, and have transitionary periods were multiple interfaces are simultaneously supported. I see some of this, but without the version numbering, its hard to determine what plays with what.

patbob Wrote:
-------------------------------------------------------
> I agree that standardizing interfaces is the way
> to go.. and I think PCs are a perfect example of
> what we want to do. Not because PCs have
> standards that never change, but preceisely
> because they DO change -- they slowly morph over
> time to meet the new needs of users. As new
> standards get supported, there's almost always a
> transition period where systems support both old
> and new stardards at the same time.
>
> I think this is a perfect model for reprap. Break
> the overall system into pieces that fit together
> with standardized, documented, version-numbered
> interfaces to foster interchangeable components,
> and have transitionary periods were multiple
> interfaces are simultaneously supported. I see
> some of this, but without the version numbering,
> its hard to determine what plays with what.
I entirely agree with your comments. This is the way to go.

Some wiki pages are being drafted and the intention is to initiate the process over the next few months. I am willing to act as a Standards Development Co-ordinator with the primary role of encouraging as many people as possible to contribute to an open standards development process. Will potential contributors please identify themselves by PM?

I am planning to allocate time for this starting from mid-may onwards (pretty heftily committed until then). I am looking to see how much we could model on the PC standards system so I suggest anyone who is interested in this might want to familiarise themselves with the way in which that has grown and see what we have to learn from that process.

David

I think that this would be a really useful contribution. Thanks David. Also, I fully take your point about standards not being a rigid constraint on innovation.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Wiki page currently at [www.reprap.org] summarises an argument in favour of Standards

I think the easiest method is to have the core team dedicate themselves to "pinching" ideas from the masses, to improve and streamline the basic machine.

Then focusing on the wiki to make it as clear and clean as possible for the non-techie audience to participate. Including many "what if" scenarios to help people troubleshoot and calibrate their own machine.

The wider the audience, the faster the evolution.

Hi

I have a couple of thoughts on standards I would like to chuck in the ring.

RepRaps are gonna get bigger......... and smaller.
RepRaps will be hacked and developed along the way in the shed.

I know both these things are obvious but they relate to the following :-

1. There could be 2 hardware standards.
A standard for larger machines and a standard for the smaller robots.

This would relate to say, the carriage/hotend interface, both electrical and physical. A larger, more robust physical interface with more current available for the Large scale spec. Carriage weight limited on the smaller unit spec.

2. Standard software tool chain.
This would include standard uProccessor dev set up, 3D modelling tools. Reprap driver software. Everything you need to design, build and use a Reprap. (All free and open source if possible). Standard file formats across all files from electronic schematics to RepRap part cad files.

As a side note to this. Is anyone here on an open source cad project ?
Would any OS cad project be interested in RepRap and develop their software along side reprap......?

As for the the standards I would like to vote for 0.1 headers for data lines. Easy for homebrew hacking.
Possibly I2C for module communication. Huge support in the semiconductor market.
For the carriage, a flat vertical plate with 4 or 6 holes to attach the hotend (mounted to a similar plate may be).


Just a couple of thoughts. Not sure as to their value though

Rob Last

Hi all,

I'm new to the forum and reprap, but have been around various homebrew and software scenes for decades. Hopefully you won't mind me rambling here.

Comparing RepRap to the PC scene is rather skipping a few generations. It appears closer to the home micro scene of the 70's - where standards emerged as groups found consensus on the 'better' technologies to use. Before the PC established itself, there were dozens of operating systems, processors, bus standards and so on. Without exploring and discarding hundreds of options, any early attempt at standardisation is a guessing game. For all we know the basic concepts of reprap could be made obsolete overnight by low cost optical/resin systems.

The thing that helps standards to emerge is a healthy developer scene. Lots of people experimenting with 3D printing equates to lots of people thinking about how to improve things. It also increases the chance of new discoveries, and a healthy scene also supports entrepreneurs to invest time and money in improving technology and driving down costs. Lots of shared information allows people to decide which are better choices - and that reduces fragmentation.

If there's any criticism I would make of the scene at present, is that it's still quite hard to 'get started'. You can buy an off the shelf reprap or equivalent, but that is a big single investment and doesn't encourage so much experimentation. If you want to build your own, you have to do quite a bit of research to find a complete set of components, electronics, software and instructions that are all compatible and current. The wiki is helpful, but sometimes perhaps a little too careful not to show bias. It is also quite difficult to understand the current state of various projects and options. It might help to take a cue from various open source repositories that show start date, most recent update, participants, activity and release status for each project (I know the wiki has the last of these) - so that visitors can more easily gauge what is actively being used and worked on, and what is experimental, outdated or purely conceptual.

I guess in short I'm saying the Wiki probably makes a lot more sense to people who know what they're doing and who actively participate in the forums, than newcomers.

I'm also quite surprised there's not more crossover with home-built CNC machines, which seem to share a great deal in common with 3d-printers. The repstrap concept seems particularly to overlap and to be a source of much experimentation.

My current impression is that, while developing some form of "standards" might be forecoming (but historically most of them are de facto arrangements around some already established dominant practice) we still have huge needs of "filling in the blanks" for example around the physics and characteristics of our machines.

The design is too much of a moving target, what we're still much into is hacking, and for that a more comprehensive knowledge base always helps (example: the pages on modding power supplies come really handy). Improved multidimensional knowledge of the many constraints we face could could better guide/inform design & evolution of parts, and in the end, "standards".

An example I was looking up today: what is the optimal belt tension compromise, given frame and construction features? No forecoming answers (or I missed some corner of the wiki)... googled into a gates document, but it is still way too generic to be useful.

I think there are a few hardware standards that could benefit designers in the short term. First, a good standard for hot end compatibility with extruder designs. Not every designer has the money to try all popular hot ends on their new extruder design, and not all hot end designers want to print out all the current carriage and extruder designs to test their hot ends on. A couple of dimensions and design guidelines might make everyone's life a bit easier.

X smooth rod spacing seems to have been settled since both the original mendel and Prusa designs have the same spacing. Something similar would benefit the designers of variants with x smooth rods spaced vertically rather than horizontally. I've made that a separate post here [forums.reprap.org]

@brianandaimee:

BTW there is ongoing smooth rod spacing discussion going on around a vertical X axis in another thread.

IMHO the real questions are upstream: ideally, we should sit down, start from what is realist and possible with heated, extruded plastic, and seek some form of consensus on key characteristics of our machines, what do we really want: in terms of frame stiffness, maximal accceptable deflexion of an axis, backlash, accuracy, etc. When designing, are we aiming to get printed stuff tolerances at around plus or minus 1mm, 0.1 mm or 0.05 mm? We could have several compromises, for different budgets (and hopefully an upgrade path). In that the ppl with a solid background in mechanics can help a lot.

In search for references, I tried looking similar data for commercial (stratasys, hp) 3d printers at the "low" (still 15k+ USD) end, but (maybe I didn't look in the right places) there is very, very little data on their documents, barely print volume and layer height. Sigh. At least with laser printers we had the DPI. So this kind of data must be sensible, important stuff

If you start collecting such data, the concensus will form it's self. Difficult thing, though, as this depends a lot on build quality and even firmware settings (acceleration).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Way to go.
Started collecting links about backlash, belt theory, stiffness in my wiki home page, in due time could be transferred to separate pages.

But that is all theory. We need data on the actual build quality people are achieving, and its variability. A survey.
Maybe we should design a couple of simple, unobtrusive tests plus a short questionnaire, validate them, them post 'em here in the forums.

With sufficient participation, we should be able to draw nice curves - and have a better idea of where people actually get, with commercial stuff, repstraps and self builds.

Need help on that: what variables should we ask them to measure? what simple tests should we propose?

...

My take is that once people start accelerating (thanks to improved firmware and maybe in the near future, faster processors), they will "discover" mechanics and stiffness have to follow up. And maybe the 8 mm bars that were fully appropriate at 15mm/s or less on a Darwin won't quite cut it at 60 mm/s swinging masses in the 0.5 to 1Kg range.

Hello.

I've been following reprap development for about two or three years now, lurking on the forums and the wiki.
Since I've got a lot of different things to say, I'll structure this post with some captions...

On standards:
I'd like to speak out for standardisation in general, mainly because standardised parts will lead to cheaper repraps over time. Also, having a common denominator for communication tends to advance development - it's easier to express new ideas in an understandable way when everyone has a common base to start from.

Then again, standards impose certain limitations on a project, and due to this have to be thought about carefully. I think in the current state, standardisation would mostly benefit the project, but care has to be taken to make the standards meaningfull, usable and practicable.

(and... you can still standardise new parts after hacking them together)

On bus communication:
Using USB for the communicaion between a PC and a RepRap is ok, but for internal communication you'd probably want to use something more lightweight, e.g. like 1 Wire [en.wikipedia.org] or I2C [en.wikipedia.org].

On model formats:
Engineering concerns are top priority, it's easier to get good looking models from a format focused on making the parts represented than it is manufacturing parts from a format that is optimised for good looks.
If you're going for a html based representation, may I suggest xml [en.wikipedia.org] ? It has the advantages of being designed to store arbitrary data, is quite easy to parse, is readable for humans and can be extended relatively easy.

On documentation:
The documentation of the project is like most other foss projects: outstanding in many parts, but lacking in others.
It would probably be good to review each article and mark articles with tags specifying the work needed, e.g. stub, lacking sources, needs more diagrams/images/pylons/whatever, in development, e.t.c.... like 'the other wiki' does.
Some articles are hard to find by wiki walking (e.g. allmost all in [reprap.org]) and there is a general lack in overview.

On Eiffel:
I have mixed feelings about Eiffel. Although the goals are worthwhile, there's not enough info available yet.
It would be nice if there was a split between Eiffel and [post mendel], the first being the project going for innovative, while the later would strife for cheapness.


Yours sincerely,

SarahMiller


PS: Seeing how the English language is not my mother tongue and I have a tendency to critizise odds and ends, I hope my post doesn't come across as too harsh.

Quote

On bus communication:
Using USB for the communicaion between a PC and a RepRap is ok, but for internal communication you'd probably want to use something more lightweight, e.g. like 1 Wire [en.wikipedia.org] or I2C [en.wikipedia.org].

Hello, Sarah-with-the-nice-tongue,

isn't internal communication a thing of the past already? None of the current RepRap electronics does internal communications these days, Gen3 is considered to be deprecated.

Quote

On model formats:
Engineering concerns are top priority, it's easier to get good looking models from a format focused on making the parts represented than it is manufacturing parts from a format that is optimised for good looks.
If you're going for a html based representation, may I suggest xml [en.wikipedia.org] ? It has the advantages of being designed to store arbitrary data, is quite easy to parse, is readable for humans and can be extended relatively easy.

A few months ago, a successor of the STL format was born, AMF. AMF not only allows to use curved surfaces, it also allows for coloured models. And yes, AMF is a XML-based format.

Quote

On documentation:
The documentation of the project is like most other foss projects: outstanding in many parts, but lacking in others.
It would probably be good to review each article and mark articles with tags specifying the work needed, e.g. stub, lacking sources, needs more diagrams/images/pylons/whatever, in development, e.t.c.... like 'the other wiki' does.
Some articles are hard to find by wiki walking (e.g. allmost all in [reprap.org]) and there is a general lack in overview.

Yes, please go ahead and do it. Everybody can edit the wiki, except for this single front page.

Quote

On Eiffel:
I have mixed feelings about Eiffel. Although the goals are worthwhile, there's not enough info available yet.
It would be nice if there was a split between Eiffel and [post mendel], the first being the project going for innovative, while the later would strife for cheapness.

What's Eiffel?

If Eiffel is a synonym for post-mendels, then I see new post-mendels emerging outside the wiki, on dedicated web pages. The mendelmax is an example. Not a good thing, IMHO.

Perhaps the wiki isn't as nice looking as it could be, but other than that I see nothing wrong with it. We should identify what people holds back from using the wiki, and how we can address these concerns.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I ASS-U-ME she means the Eiffel page in the RepRap wiki.

Quote

Eiffel is a proposal for a post-Mendel RepRap, which will function as a 3D printer, and as a CNC_Router.

---

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

Personally I think most RepRaps these days are headed in the wrong direction. There are too many oif the old mechanical paradigms hanging around.

Why so many nuts and bolts, for example? Why has nobody else even just replaced them with cheap woodscrews?

While using minimal plastic to make kits cheaply has its benefits, the cost is then pushed on to the buyer in other ways. The buyer then has to purchase more vitamin parts to connect the sparse plastic parts together. Plastic is cheap, folks; try to eliminate the fiddly bits.

All we can do is encourage things in the right direction. We must not get stuck in the mindset where we view a RepRap as a desktop-sized thing that runs GenX and squirts plastic. People want a range of products, from little machines working miraculously in metal to big ones squirting concrete. We need to publish a "Good Design Guide" to preserve the collective wisdom rather than nail down one or two machines as being gospel.

Vik :v)

Quote
VikOlliver
Why so many nuts and bolts, for example? Why has nobody else even just replaced them with cheap woodscrews?

Because nuts and bolts are more reliable than wood screws for one.

Quote
VikOlliver
While using minimal plastic to make kits cheaply has its benefits, the cost is then pushed on to the buyer in other ways. The buyer then has to purchase more vitamin parts to connect the sparse plastic parts together. Plastic is cheap, folks; try to eliminate the fiddly bits.

I thought that was exactly what the Prusa design does. Reduces plastic and the majority of nuts and bolts.
Isn't this the right direction?

---

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

Quote

Why so many nuts and bolts, for example? Why has nobody else even just replaced them with cheap woodscrews?

While using minimal plastic to make kits cheaply has its benefits, the cost is then pushed on to the buyer in other ways. The buyer then has to purchase more vitamin parts to connect the sparse plastic parts together. Plastic is cheap, folks; try to eliminate the fiddly bits.

All we can do is encourage things in the right direction. We must not get stuck in the mindset where we view a RepRap as a desktop-sized thing that runs GenX and squirts plastic. People want a range of products, from little machines working miraculously in metal to big ones squirting concrete. We need to publish a "Good Design Guide" to preserve the collective wisdom rather than nail down one or two machines as being gospel.

Exactly. Glad to see you in the forums, Vik.

A little bonmot: your video about how to use an afghan lathe is one of the reasons I'm now at RepRap. Because it convinced me here are the right minded people.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------

> Hello, Sarah-with-the-nice-tongue,

Hint : in French tongue and language are the same word ("langue").

Internal communication: will step/dir/enable interface live forever? maybe someday we could use something else to command the steppers, which might open new doors to motors control and optimization. Some of the existing interfaces can program digitally most or all stepping parameters, aspect that is currently locked away. Which might bring things like acceleration to a different level. I think hardware wise it could be done right now, but firmware wise it may be a long way till somebody would even consider it.

Except things like cost and feasability and related, are there other practical aspects of these alternatives that i dont see - like good reasons for why it hasnt been done or attempted already?

Thanks Traumflug! I still use the Afghan Lathe to produce extruder barrels and nozzles, though I now have a cheap but sturdy Chinese drill press to hold the drill in. This is mostly because my workshop is on the second floor of the house and if the girls are inside I have to do the noisy work outside. The drill press is more portable.

Vik :v)

Quote

Hint : in French tongue and language are the same word ("langue").

Actually, I meant the "language" meaning. I tried to be kind.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Hello, Sarah-with-the-nice-tongue,
>
> isn't internal communication a thing of the past
> already? None of the current RepRap electronics
> does internal communications these days, Gen3 is
> considered to be deprecated.

Yup. I read up on generation 7 electronics. Quite the admirable design.

> A few months ago, a successor of the STL format
> was born, AMF. AMF not only allows to use curved
> surfaces, it also allows for coloured models. And
> yes, AMF is a XML-based format.

Good to know. Now, excuse me while I read up on the spec...
(btw: AMF on wikipedia: [en.wikipedia.org] ; AMF specification: [www.astm.org])

> Yes, please go ahead and do it. Everybody can edit
> the wiki, except for this single front page.

I will, as soon as I found the time to read through the AMF specs and familiarise myself with the wiki policy.

> On Eiffel...

Yes, I meant [reprap.org].
Is Eiffel not the semi-official successor of Mendel?

Quote

Is Eiffel not the semi-official successor of Mendel?

Well, the last edit on the Eiffel wiki page was december 2010, so this design is probably abandoned. To be honest, I currently see the lack of anything "official" at the moment, there are not even "official" next targets. Most active RepRappers currently work towards being even cheaper, like replacing reprapped parts with industrial ones or like opening up more webshops.

That said, I have my own take on the next generation RepRap. As you can see, it's still covered and it likely replaces a frame made of metal rods by wood. Everything made of wood can be printed as well, that's the idea.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY