RepRap near future

Hi guys,

This should really go in the development forum I think, but I don't have permission to post there.

I'll keep this short and simple:

I think that the RepRap design should become more standardized. for a newcomer there is no single set of files he can download and almost no indication on what to use.
In software terms: we are like the SourceForge projects that only provide source code without the binaries.

This is annoying for the end-user.

As a project we need to get ourselves together and focus on a single set of plans. development branches can occur but the trunk must be maintained and the branches can later be assimilated into the trunk.
I think that if we want to see the project growing we need to make it much easier for people to understand what they are building.
Currently the procedure involves a lot of frustration.

I feel lost in the sea of websites, wikis and lists.
there are too many websites and lists and instructions.
too many things are not up-to-date and the information is all over the place.

take for example the Ubuntu project.
it is an enormously complex project to build an operating system, but for the end-user that just wants ubuntu that is of no concern. the process is easy.

go to www.ubuntu.com and see for yourself.

as a project I think we should strive to merge the whole project into a more coherent structure for end-users.

I think we could manage with very little effort to consolidate the website into a single source of information (with a back section for builders and developers) and with a little organization we could reach a point where the instructions for the end users are:

1)Get these parts.
2)build this.
3)Install this.
4)start printing.


As I have said many times, I volunteer to help.

-Leav

Edited 1 time(s). Last edit at 10/06/2008 04:08AM by Leav.

I agree. Due to an injury I am unable to do a lot of the work needed to assemble a RepRap (the main reason I haven't got one yet). Although I have the knowledge (and used to ahve the skills), I am unable to build one.

I understand, however, that there are people with the opposite need of my problem. Specifically, that they have the physical capability for basic assembly, but don't have the knowledge or skills to do so.

As such, I share their frustration in being excluded from this because of the situation.

If there was a sub project with the aim of making the RepRap user friendly, this would be a great boost for the project as more people (me included) would be capable of gaining access through the results of this subproject.

The fact is, the RepRap itself would aid people like me in general quality of life. Often people with disabilities (like me) need small tools that are not mass produceable because it is economically infeasible, so that when we need these thing made, they are extremely expensive. For instance, a handle for a tap (or door) that has been designed for a person's disabilities can cost many times the cost of a stock tap fixture.

A RepRap would be very useful in aiding people in situations like mine. However, as I still ahve some ability to construct things, I could still build (with help) a RepRap if it was a bit simpler (a simple thing would be having the electronics pre soldered). Even if this meant that the cost of this version was higher, I would pay as it would allow me entry into the development (compared to the price of custom made objects that become necessary just to get what others take for granted, this would be a bargain).


I think this is one area that a RepRap could get a lot of publicity and support. If you could make the design so that a carer could assemble one so as to be able to produce components to help them help their charge, this would be a huge boost to the uptake of the RepRap.

@Edtharan

I hadn't thought of the persons with disabilities angle on this yet. There is a HUGE market--I use the word "market" loosely without the specific connotation for money making ability--for exactely the kind of custom parts you talked about. That's a great use for this machine.

@Leav

I think you've been here awhile so you have probably seen the many other threads relating to exactly what you have been talking about. I'm kinda curious myself what the state of the project is and where the development team is headed. I think they are doing a fantastic job but would like a little insight into where they are headed and what their take on this issue is.

There has been an explosion of electronics versions and switches. I'm not really sure myself what is still supported, what will still have firmware written for it, what will be dropped shortly, etc. These are things the community and people wanting to start a reprap need to know about. In pursuit of this I think what Leav suggests--a standardization of the project into a producible item suitable for a newcomer to make--is exactely what reprap might need now.

I realize we have talked about this before and it was pretty much stated that now was not the time as we were just trying to get reprap to replicate. Well...it has replicated. Isn't it time to do some house cleaning and tidying up? Most of the development that is occuring now is geared to making the extruder better and more reliable...meaning that it currently works but we would like it to work better.

I say that the development team should take a serious look at taking a bit of time to prepare a nice version 1.0 release of Darwin. There are many hands willing to put in a little time to cleaning things up around the documentation--myself too!--so the lack of workers shouldn't be an issue.

Just my two cents.

Demented

Pardon me , but my understanding is that the mechanicals of the Darwin are solid and available in a number of formats (bits and bytes sells kits and several description files are available for those who want to make various pieces by various methods). While the extruder is in heavy development, B & B sells parts kits and directions for making a standard mark 2 extruder are on this site. I know, I followed them. It works. There is a stable software release for Linux on a bootable CD. The only area where the flux seems bothersomely high is in the electronics, where there are at least 3 versions in development and some doubt as to which will be maintained "permanently". But again the directions are here for a working PIC based set of Darwin electronics and boards or kits for same can be ordered. If you need help with the soldering, contact your nearest RUG or Dorkbot chapter and offer to buy 2 sets of parts in exchange for one turnkey set.

Aside from one click shopping for a free, assembled RepRap delivered to your door (the ubuntu model), what are you looking for? Can you provide a little more detail about what you would like the web page to look like? What sort of balance did you have in mind between ease of use and customizability? How much of your difficulties are in essence supply chain problems caused by the fact that this is a young business mapping new terrain with modest resources? How much assembly do you want done for you (0%(current), 50%(electronics and extruder), 100%?)? What are you willing to pay? Single source or multiple vendors? Are you volunteering to clean up the Wiki or do you want to change the whole model? Just trying to clarify.

You know, it would be probably be very useful to newcomers for there to be a number of pages outlining what goes with what to create a successful Darwin. Obviously, there are several paths.

Something like this.

If you buy these boards, you use this firmware release and you run them with this PC-side software release.

Here are the parameters you set for running your software and firmware with this version (Bits and Bytes or Pocono) of Darwin with THOSE stepper motors.

It seems like 75% of the queries I hear coming to the forums stem from newbies not having a clear description of what goes with what to make a successfully running Darwin. From what I see there are a number of successful ways of creating a successful Darwin, but nobody has mapped them out unequivocally so that it can be done by the less patient and forbearing.

As well, extensive and painstaking tutorials put together on how to use things like Skeinforge and AoI need to be in there, too.

Finally, somebody needs to make a stable build of the PC side bumpf that can just be loaded and goes. All this demanding that people get way, way into the esoterica of putting together a Linux configuration that will actually work with the Reprap software is, to my eye at least, the major obstacle to getting more people online.


Just my two cents worth.

Quote

I hadn't thought of the persons with disabilities angle on this yet.

When you haven't had direct experience with something, it doesn't always come to mind. But that is one of the advantages of the internet, you are likely to find people with those direct experiences.

Quote

There is a HUGE market--I use the word "market" loosely without the specific connotation for money making ability--for exactely the kind of custom parts you talked about

As someone who is interested in "markets" and economics (although not as a job), I understand this about Market not necessarily relating to money. It is, in fact, a difficult concept to get across to people.

Markets are about "Value" and value is not only to do with money, wealth or possessions. You can value something because it has sentimental value.

Trade is about the exchange of Value. eg: you might value my rice because you don't have a lot, and I might value your sheep because I don't have a lot. We can then come to an exchange where by you get an value of my rice and I get a value of your sheep.

But it can be applied to other things. You might give me a complement and because I value your opinion, I give you thanks for that compliment. It is a trade, and it is a trade of values.

(but back on topic )

Quote

I realize we have talked about this before and it was pretty much stated that now was not the time as we were just trying to get reprap to replicate. Well...it has replicated. Isn't it time to do some house cleaning and tidying up? Most of the development that is occuring now is geared to making the extruder better and more reliable...meaning that it currently works but we would like it to work better.

Yes, I see the current development of the RepRap as a prototype for the end product. One danger of prototyping is that you keep refining the product without end.

There is a common saying: Projects are never completed, they are abandoned.

Now the advantage of the RepRap and the direction it is going with the Evolutionary development path is that it is quick to develop new prototypes and that many people will develop new additions.

This is why I think we need to have some level of separation between the development of the RepRap's functionality and its Release.

Currently in Opensource projects they have development versions and release versions of the product (software). We need a similar thing for RepRap, however, even using the same model as the Opensource software, there are a few problems that can crop up.

Mainly, development versions don't necessarily take into account usability and user friendliness. Some projects do, but it is not because of this methodology, but because there is someone on the team that thought about it.

Now, a lot of the people working on Opensource projects are highly technically competent, and so their concept of usability and user friendliness is different than those who would like to use the product, but are not technically competent. This creates the problem where by the technically competent developers get frustrated that their wonderful creation fails and the non technically competent users get frustrated because the product they want to use is clunky and difficult to use.

There is also a level of hostility between the developers and the users because of this frustration (I have had direct experience of this ).

Quote

You know, it would be probably be very useful to newcomers for there to be a number of pages outlining what goes with what to create a successful Darwin.

I think it needs to go a bit further, but this is a good start.

RepRap is a complex piece of machinery and software. There are many competing versions (and that is a good thing because of the goals of the RepRap project), but for non technical users, it is difficult for them to be certain of what to do. Should they Get version 2.0 of the extruder, or version 2.1? Which is better? Which works and which doesn't with the other components (will version 2.0 extruder work with version 1.1 of the electronics)?

For end users, this information has to be the first thing they encounter when looking to acquire a RepRap.

Another thing to note is that people, due to the way our brains function, have a working memory of around 7 (+/- 2) items. The result is that if a person is presented with a list in excess of this, they will get confused.

There is a trick to handle this, and that is chunking. It is where you mentally group information together. But to do this you need a lot of experience with the subject matter.

This is why technically competent people find it easy to deal with these lists, and non technically competent people get confused. The technically competent people have had the experience that enables them to chunk the data.

What we need to do is to explain the process of getting a RepRap in 7 steps or less.

But doing all that is just a first step in the process of making the RepRap an end user product.

What we need to do is to simply the processes of building a Darwin so that no technical experience is necessary. That if you can wield a screwdriver, you can build a RepRap from ordered parts.

The Ikea of RepRaps .

This means things like pre-soldering the electronics, clearly marking the plugs (colour coding?) and having the structural pieces clearly marked as well. I would even go so far as having RepRaps completely assembled so that all an end user has to do is open the package, install the software and plug it into their computer.

This will mean Windows and Mac versions of the software, not just Linux (even if it is on a bootable CD).

It also means a clear and simple method of obtaining updates. This is not the same as having updates listed on some revision list and someone knowing their version and checking that version against the latest build version. There needs to be a tool that is included with their software that does that for them and tells them there is an update available and give them a dialogue button that they click that will automatically download the update and install it for them.

This should also be available with the hardware too. If there is a new update for a piece of the RepRap (say a new extruder barrel), then they should be notified and allowed to wither download and print it, or go to an online shop (or contact a nearby RepRaper that will be able to install it for them).

Actually this is also a potential business opportunity for the RepRap community to get into: Technical Support.

@Edtharan
The "market" you describe seems like it could really use a RepRap. and I really think that the simplification of the project is crucial for it's widespread success.
Right now i'm pushing for the simplification of the "meta-physical RepRap", that is software, web pages, wikis, instructions et cetera.
I think that the major mechanical simplifications should wait for mendel.
In the mean time you can contact me for soldering the electronics (no charge, ofcourse), i'd do the mechnichal part too, but I live in Israel so that's not really practical.
my email is leavoa*gmail.com.

@Demented Chihuahua
we are totally on the same page, so what can I say? I hope I see you on the clean-up team

@BDolge
While Edtharan was taking about simplifying the design, i'm more geared towards cleaning up the documentation at the moment. (see reply to Edtharan)

@Forrest
I agree, and the way I see it, it looks like that is only the tip of the iceberg.
Double and triple wikis, no up to date parts lists, confusing instructions (for me at least).... there is much to be done (IMO...), but since the work is mostly restructuring at this point - it should not take much time at all.

>>Finally, somebody needs to make a stable build of the PC side bumpf that can
>>just be loaded and goes. All this demanding that people get way, way into the
>>esoterica of putting together a Linux configuration that will actually work
>>with the Reprap software is, to my eye at least, the major obstacle to getting
>>more people online.

what is bumpf?
and shouldn't the liveCD cure that problem?




======================================================================
======================================================================
======================================================================

so for the big question: How can we make this happen?

======================================================================
======================================================================
======================================================================








-Leav

I very definitely agree that we need to sort out documentation for new users. At the moment it's written for our reference (this is clearly needed too) rather than for someone coming to the project for the first time.

That's why we've started up the Builder's Wiki at

[objects.reprap.org]

It was the intention of that (among other things) to allow us all to create precisely what is being requested here. So we should all get typing and linking...

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

I think I see what Adrian had intended for the Wiki...Seems to be a bunch of case studies of successful builds so that people can learn by example and then try on their own. Am I right?

I guess that is a sort of good stop-gap measure but I still stand by what I wrote before, I stable release is needed and the documentation needs revision.

Demented

Might I suggest that the model most successfully used in open source software be followed. That is the Linux kernel project, because it has worked for 17 years. There are thousands of developers that write code for the kernel. The core group of developers for the kernel evaluate and test the provided code. When the core group believe that they have a consistent structure/subsystem then the group sends it to Linus. At that time then Linus grabs TUX the penguin and squeezes out the penguin pee and the software release is blessed as a specific release level.

How this applies to reprap is as follows:
1. Those that have built a working reprap can supply that information to the core reprap members.
2. If there is information or a project lack then the core group can make that information know on the forums and find someone to fill the need ( notice that the core group is not responsible to solve the problem but to identify it ).
3. Once the core group is satisfied that there appears to be a cohesive structure of hardware and software then:
4. Dr. Bowyer can grab the closest extruder with an oven mitt and bless the information as a release.

Please note that this system minimizes the time required of each individual to the smallest amount to complete this very critical task.

Bob Teeter

---

Bob Teeter
"What Box?"

It's not too easy to follow all the different pages and sites.
Everything is linked crosslinked and linked back again,
so most of the time trying to follow the "make your own" [reprap.org] instructions your about to click a link and then another one and then back again.

it requires six clicks to get to here [reprap.org] for example.

I know you cannot add every sublink to the main menu, and I am aware of the fact that you can neither put everything on one page.
But what you CAN do is put every link for every little detail onto one page
and link that page onto the first site mentioned.
That way one would find every information within two or three clicks
(golden rule of webdesign #3: no more than threee clicks to important informations)

'sid

Zach suggested a format somewhat like this...

[replicat.org]

Looks good to me.

Adrian Bowyer Wrote:
-------------------------------------------------------
> I very definitely agree that we need to sort out
> documentation for new users. At the moment it's
> written for our reference (this is clearly needed
> too) rather than for someone coming to the project
> for the first time.
>
> That's why we've started up the Builder's Wiki at
>
> [objects.reprap.org]
>
> It was the intention of that (among other things)
> to allow us all to create precisely what is being
> requested here. So we should all get typing and
> linking...

OK, I've started the ball rolling by setting up the skeleton of a build guide here:
[objects.reprap.org]

Feel free to fill in, modify, trash as needed. A lot of the "meat" of the guides can be pulled from here: [reprap.org] and modified as needed.

The hard part is going to be filling it in in a coherent fashion. It'd be best if the instructions didn't contain a lot of "if you've got this, then do this". Need to figure out how to do several different step-by-step build guides, depending on which choices you've made. For example: Say I've chosen lasercut parts, RepRap host on Linux and Arduino electronics. I'd want a guide that shows me everything I need to do and nothing I don't need to do. "Start here and follow these steps" sort of thing.

Any suggestions on how to do that? Looks like we're limited in what we can do in the wiki environment. There's no javascript, html forms or file includes. I suppose each possible build guide could be a page of links, one for each step, allowing each step to be reused for different guides. The disadvantage is that you'd need to backtrack to the guide page after each step. Not the most optimal solution.

well not exactly

split electronics from mechanics (just like in the current how2)
then create a simple mask.

just as simple as you did with the gcode php
case "sanguino": $tron = "sanguino.php"; break;
case "arduino": $tron = "arduino.php"; break;
and so forth
the same with the mechanics
case "printed or moulded darwin": $mech = "darwin.php"; break;
case "lasercut bitsfrombytes": $mech = "bfb.php"; break;
case "lasercut ponoko": $mech = "ponoko.php"; break;

you can have as many checkboxes as you want and just fill an array with all the necessary informations,
what electronics, what motors, wich extruder subversion and so on and so forth...

Then just call the array to be read item per item (in the order of build instructions)
Also you can then use that (all php based) to print a complete handbook including an index or download that as a single pdf.
You can however view all the pages online and depending on the options you chose
have all related sites linked on each and every page you view for fast access skip and backflip

'sid

No offense to anyone...

The suggested build guide you posted, Steve, suffers from the same problem as the front page of RepRap...namely, you branch off into oblivion...which reprap do I want to make? Pic or Arduino? What bot type? Laser cut or McWire or Darwin? The newbie doesn't have the information to make these decisions and there are so many of them it is staggering.

I think we need a standard release. The documentation is fine if you know what path down it to travel. I'm saying we need to get rid of the choices--only on the main site--so that newbies have a clear path to follow to the standard reprap Darwin. Supported electronics, supported firmware, supported host software. Diversification is good to a point but the newbies need a way to get started coherently lest they drown in data and possibility.

If others want to follow a different development path, they can do so. It's how linux works so RepRap can work that way too. The main site does not have to maintain data on all the variations of the RepRap that could or do exist. It only needs to maintain the Official release and maybe provide space for other development by the community if it sees fit to do so. The Builders wiki strikes me as that space.

Can we get some more developer voices in here to address these concerns and ideas? Are we way off? Are there other considerations to be assessed? What is the current thoughts of most of the developers?

Demented

Oh I forgot... thanks Demented

...
default: $tron = "arduino.php";
$mech ="darwin.php";
....
break;

done

'sid

Demented Chihuahua Wrote:
-------------------------------------------------------
> No offense to anyone...
>
It's a hoot how you use "Linux"and "standard release" practically in the same breath. I want some of whatever you're smoking.

Quote

In the mean time you can contact me for soldering the electronics (no charge, ofcourse)

Thanks, when I get the money (and If I can't find someone closer - I live in Australia) I might take you up on that.

Quote

While Edtharan was taking about simplifying the design, i'm more geared towards cleaning up the documentation at the moment. (see reply to Edtharan)

Not so much the "Design", but simplifying what the end user has to do to get their RepRap up and running after ordering it. The most obvious way is to simplify the design, but pre-building the more complex parts is another.

The term used in Marketing circles is "Streamlining" the user experience.

Quote

I think we need a standard release. The documentation is fine if you know what path down it to travel. I'm saying we need to get rid of the choices--only on the main site--so that newbies have a clear path to follow to the standard reprap Darwin. Supported electronics, supported firmware, supported host software. Diversification is good to a point but the newbies need a way to get started coherently lest they drown in data and possibility.

This is what I was talking about. The site is good for those that are technically knowledgeable about the RepRap already.

To make the decisions with the choices presented, you need technical knowledge. Now, most people currently working on the RepRap has this technical knowledge and so this, to them, is a really great resource. But if I don't have technical knowledge and just want to get a RepRap to use as a 3D printer (and to make copies of it to give to friends), then this kinds of resource doesn't help much.

Think about Bubble jet printers. The vast majority of people have absolutely no idea how that printer works, but they know that if they buy one, install the driver software and plug the printer in then they can print with it.

For RepRap to become widely accepted, it needs to get to this level of simplicity of operation.

In software development (my area of study before my accident), we talk about a Shippable Product.

What this means is that even though changes will occur as the project continues, at certain points in the development process, you need to have a version that could be released, even if all the features are not implemented.

The way I see the project (in relation to the end user), is that only development version of the RepRap exist.

What needs to be done is that someone (or a group) state that Version Such-and-Such of the Electronic, Mechanics and Software are "Fixed" and call that a release version.

Development will still continue from that Fixed Point, but until the next Fixed Point is set, the first Fixed Point is the product called the RepRap.

It would be also the responsibility of this group to make sure that this Fixed Point works and is easy for the end user to implement. This would entail making sure that the instruction are correct for that version, that the design actually works and that there is a supply of the parts (and that it is easy for the end users to construct with no technical skills or knowledge beyond simple "handyman" skills - screwdriver, glue, etc).

They would also work with the developers as the time of setting the fixed point approaches in getting the features of the project sorted out and working.

It will mean that the Release version will not be quite as cutting edge as the development versions. But that is a necessary price to pay for end-user usability.

As people get more experience with the RepRap, then more people will get the technical knowledge that will enable them to keep up with the latest and greatest. I can tell you now, that even if the ReRap becomes wide spread, most people will not download and print new parts to upgrade their Reprap. They might do this if specific functionality is developed (say being able to print metals), but they would more usually just buy the new version (they will be paying for the service to have it assembled for them).

This is a big project in itself, and I don't think that the entire core team should be responsible for it (they will need to work very closely with this team). Some core members need to be on this project, but that will also mean that they need to split their time and effort between the two projects (the core development and the release development).

Greetings all,

I'm not convinced that a standard release is the best thing for all participants.
"One size fits all" often means a poor fit for many. We each bring different skills to the project, have different interests and differing budgets.

An alternative might be an "Annotated Taxonomy of Reprap/Repstrap designs."
A part of the Wiki that explains the alternatives and the constraints of mechanism, electronics, firmware, and software -- ideally, with views on the difficulty of the different approaches. This would NOT preclude suggestions about which alternatives are the best supported, lowest cost, most stable.... If the core team were to weigh in on what configuration was "the mainstream design" (at any given date) that would be fine also. Especially for a project that is supposed to evolve, a single "standard release" seems limiting.

-- Larry

We can make a rough division of the audience for Reprap into two basic categories

People with skills adequate to make not only to build a Reprap machine but also to advance the state of the art. Heretofore most of the people working on Reprap fell into this category. As a result, there wasn't a lot of necessity for a set of prescriptive descriptions of how to build one of these beasts. People participating had the skill sets that let them muddle through.

Now that Reprap is well off the ground, however, we've got people who want to build and use Reprap machines, specifically Darwin at the present time, who barely have the skills to assemble one and certainly DON'T have the skills to do development of the Reprap technology.

That said, it must be understood that those people are HUGELY important to Reprap. Those are the guys and girls who will be printing and distributing parts for more Darwins. Those are the guys and girls who will take Darwins and create wonderful things with them that will make even more people want one.

For THOSE guys and girls we need CLEAR sets of instructions on how to build Darwins, where to buy the parts, which parts to buy, how to tweak their Darwin till it works properly and where to go when they get stuck.

Reprap has to do that if we want Reprap to become something bigger than just another interesting piece of machinery built and used by a small cadre of people. There are a lot of interesting pieces of equipment around loved and nurtured by small groups of enthusiastic people.

I think Reprap is much, much bigger than that.

@Forest

I'm what you might call "Straight Edge" without the religious connotations that some have attributed to that...so I'm not smoking anything but you can certainly have a big hit of what I'm on! ;-)

@All

What I'm talking about is not so much an over-arching goal for all repraps everywhere but for Adrian's RepRaps here. A standard release that gives the newbies clear direct as Forest was talking about. I, personally, think the instructions are fairly good as they are. I simply would like the forks taken out of the main documentation--but kept maybe in the Builder's Wiki--so that the very important boys and girls Forest talked about--can make coherent progress.

What I see now is people posting in the forums who lack the skill set necessary to muddle through what we currently have on their own. These are the people that count the most to get us past the knee in the curve of the exponential growth and spread of RepRap. (whew! that was a bit much!) A "Standard Release" would aid in this cause it would take all the ambiguity out of the process for those who do not want to develop but who just want to come and follow directions.

That's all I'm saying.

Demented

Quote

I'm not convinced that a standard release is the best thing for all participants.
"One size fits all" often means a poor fit for many. We each bring different skills to the project, have different interests and differing budgets.

I actually agree. A One Size Fits All is generally a bad idea. But Reprap has two features that mitigate this problem.

First: Reprap is Opensource. This means that although an "Official" version is produced, there is nothing stopping other groups from implementing their own "release" version. If there is enough drive for a new version, then there will be a version of RepRap to meet that demand.

Second: Reprap is Opensource . This means that if an individual wants a particular feature, then the technical designs are available for them to get access and there is enough material out there with the development community that they can either learn how to make the modifications themselves, or find someone who can do it for them.

Actually the real second feature is that the Reprap can print itself and can print modifications to itself.

Because software has had this ability for some time now (since the Opensource movement began), people have been doing this. Actually it began before the Opensource movement and started when individuals could program computers.

The fact that the Reprap is Opensource and able to print itself means that it is capable of being modified to suit the end user's needs.

Quote

Now that Reprap is well off the ground, however, we've got people who want to build and use Reprap machines, specifically Darwin at the present time, who barely have the skills to assemble one and certainly DON'T have the skills to do development of the Reprap technology.

I agree with this. You also have to include the people who don't have the time, the desire, or physical/mental capabilities to construct a RepRap or become involved in its development.

I think Forrest has hit on the best approach. The first page of the "build your own" thread could be reduced to 2 buttons: (1) "I want to follow simple instructions to build a machine to print 3D objects with"- and (2) "I want to create a machine using reprap technology to suit my own situation or advance the reprap project".
Choice (1) leads to a set of pages with directions for a less than cutting edge machine which can be reliably built by following explicit directions (currently this would probably be a B&B/Ponoko machine with PIC electronics and a bootable Linux CD. Am I missing anything here?)
Choice (2) would lead to the current WIKI/forums/ [reprap.org] pages.

I like this idea as all it requires is for the development team to "bless" a current design as workable rather than optimal and then for someone to create some fairly simple pages:
(Page 1) You Will Need: A- a computer with X features; B-the following tools

(Page a) You will need to buy: (A) B&B silver or Gold kit [link] OR ( B&B Laser cut parts kit [link] and the following mechanical pieces [list with suppliers] and the these electronics:
(Page b) (A) RRRF complete kit [link] OR ( a set of RRRF board kits [list of links] OR (C) a set of RRRF boards [list of links] and the following components [list by board with suppliers]
(Page c) You will need to download the following software: [link]
(Page X) here is how to run the software a-from the cd: b- how to load the software
(Page Y) Here is how to build the electronics and program them [links], and connect them to the computer. Here is a tutorial on soldering[link]
(Page Z) Here is how to assemble the mechanicals and connect them to the electronics.

Obviously this is over simplified.
B&B and RRRF both have great tutorials/instruction sheets which should be used.
Should we include tutorials on how to use a ruler or identify electronic parts, etc.? In line or on a separate page?
If the demands of a given page are met than all the requirements of the following pages should be met.
Everything should be bought; if they want to scavenge motors or make DIY PCB's they should go back to the start and get on the developers branch. Purchasing specified parts provides consistency.
Should this path have it's own FAQ? Yes. Should it have a troubleshooting page? Only if someone will promise to work it every day.
I don't mean to say this is a trivial exercise, but given a "blessed" design it is straight forward and easily verified. So the next step here seems to be up to our fearless leaders. Guys?

As for the concept of pre-built boards and snap together kits, those will have to wait until someone is ready to pay for them.

P.S. I don't know where the little sunglass guys came from and I can't remove them.

Edited 2 time(s). Last edit at 10/08/2008 01:24AM by BDolge.

lol the sunglass guy is from using B and then ) (when joined they look like a smily wearing sunglasses and the forum automatically converts the symbols to an image).


==Back on topic==

two possibilities exist as far as I can tell:

1)Keep the design modular so that any part can be developed independently. an example for this would be to design the cartesian bot with some sort of universal connector, and have each extruder design plug into that connector. thus specific instruction would be limited to each individual extruder, and not clutter up the cartesian bot's page.
This is a half hardware half documentation solution.

2)Pick single paths and focus on them: for example we would decide that Darwin 1.0 would include Arduino+Cartesian-B+Extruder-A and create a complete instructions path for them.
Darwin 1.5 would include Sanguino+Cartesian-D+Extruder-B and would have it's own Instructions set.
This is a fully documentation solution to the problem.

Currently we are in a better position to implement (2) immediately (no re-design required).
In the future I think (1) is a better solution. I hear that mendel already sports interchangeable extruders/tool-heads

Regarding Clutter and Fragmentation:
I think that we should immediately decide on a new layout (not a design layout, a organizational layout) and have a single website for everything.
The replicat.org website seems great. we definitely need a wiki for this with a wider user base allowed to edit it.

Ideally i'd like a decision be made by the core team to do this, a new wiki set up at something like [www.reprap.org] and the current wikis locked for editing.
a skeleton would be set up on the new wiki and many people would be given permissions to edit it.
a frenzy of copying from the current wiki would occur, but not whole pages but just segments into the new design.
almost instant organization in the project by recycling the content into a single wiki with a more coherent structure.

what do you think about this idea?

-Leav

sid Wrote:
-------------------------------------------------------
> well not exactly
>
> split electronics from mechanics (just like in the
> current how2)
> then create a simple mask.
>
> just as simple as you did with the gcode php
> case "sanguino": $tron = "sanguino.php"; break;
> case "arduino": $tron = "arduino.php"; break;
> and so forth
> the same with the mechanics
> case "printed or moulded darwin": $mech =
> "darwin.php"; break;
> case "lasercut bitsfrombytes": $mech = "bfb.php";
> break;
> case "lasercut ponoko": $mech = "ponoko.php";
> break;
>
> you can have as many checkboxes as you want and
> just fill an array with all the necessary
> informations,
> what electronics, what motors, wich extruder
> subversion and so on and so forth...
>

I'm a bit confused on this. Is this something that can be done within the builders' wiki or are we talking about a custom site?

Demented Chihuahua Wrote:
-------------------------------------------------------
> No offense to anyone...
>
> The suggested build guide you posted, Steve,
> suffers from the same problem as the front page of
> RepRap...namely, you branch off into
> oblivion...which reprap do I want to make? Pic or
> Arduino? What bot type? Laser cut or McWire or
> Darwin? The newbie doesn't have the information to
> make these decisions and there are so many of them
> it is staggering.

True, there are a large number of options and the number permutations of those options is nearly unmanageable. One thing might be to create a set of pages that constitutes a "standard" or "recommended" build guide and freeze that (fixes and tips only, no major changes). Make it easy for people to follow that guide without having to chase a moving target. It's frustrating to be in the middle of a step-by-step guide only to find out someone's rewritten the steps.

In addition, set up various other build guides for other permutations. These would be more flexible and more of a "use at own risk" thing.

If and when a new "standard" guide is created, it would be frozen and given a separate set of pages. The previous "standard" build guide would remain untouched, since some people might still be in the middle of using it.

How's that sound?

degroof Wrote:
-------------------------------------------------------
>
> One thing might be to create a set
> of pages that constitutes a "standard" or
> "recommended" build guide and freeze that (fixes
> and tips only, no major changes).
>
Remove the "major" and you've got it. The only changes should be to fix real problems. Right now Darwin is suffering from too many people making too many marginal improvements. We need to separate the development stream from the product stream.
>
> Make it easy for
> people to follow that guide without having to
> chase a moving target.
>
Yup.
>
> It's frustrating to be in
> the middle of a step-by-step guide only to find
> out someone's rewritten the steps.
>
Which happens every day around here. Mind the people making that happen are doing so for the best of reasons in their own minds. All the same, from what I've seen, it's making life very difficult for people who just want to BUILD a bloody Darwin.
>
> In addition, set up various other build guides for
> other permutations. These would be more flexible
> and more of a "use at own risk" thing.
>
> If and when a new "standard" guide is created, it
> would be frozen and given a separate set of pages.
> The previous "standard" build guide would remain
> untouched, since some people might still be in the
> middle of using it.
>
> How's that sound?
>
That's what needs doing.

Looks like we are all on the same page here.

How can we get the ball rolling?

Like I said earlier, I think the best option would be to have a completely new wiki, which we can edit until it's ready to be moved in place of all the current websites and wikis.

then archive all the old stuff in a forgotten corner until it's no longer needed.

What say you?

-Leav

Leav Wrote:
-------------------------------------------------------
>
> How can we get the ball rolling?
>
Somebody who is building a Darwin needs to carefully document everything he does and collect, especially, both the identity and content of the software versions he is using.

If you can get several such people, all trying to do the same build of Darwin, the documentation work can go a lot faster.

Leav Wrote:
-------------------------------------------------------
> Like I said earlier, I think the best option would
> be to have a completely new wiki, which we can
> edit until it's ready to be moved in place of all
> the current websites and wikis.


The wiki Adrian mentioned above [objects.reprap.org] is a new wiki. Well, it shares space with the objects wiki but that shouldn't cause too much trouble. And unlike the main wiki, it's open for editing by anyone willing to sign up.

This page [objects.reprap.org] was created yesterday. It's as good a place to start as any. Nothing there is sacred or carved in stone.

Just to throw something out there as a "standard" build, how about:
- Arduino electronics
- Linux platform with side notes for Mac and Windows
- RepRap host 0.9
- Darwin hardware (moulded or laser-cut?)
- some sort of extruder

I have to confess to being a bit fuzzy on the various extruders. What's the best choice here?

Edited 1 time(s). Last edit at 10/08/2008 11:26AM by Steve DeGroof.