Working Notes, please edit.
The Combinatorics Problem, relative to the RepRap project, deals with the tremendous amount of variation that happen in the project because of it's nature. There are many goals of the project, and many needs of the userbase. Because of this, it's very difficult to address all the needs and goals of all users involved. Hopefully we'll be able to find solutions to the ever-expanding amount of information and how to properly document it.
- 1 Stack
- 2 Examples
- 3 Table
The Stack template is one solution to this: Template:Stack
(Work in Progress) --Sebastien Bailard
Personal and individual user solution
We need a solution for each user. This may be a paper or text file copy of the the Stack Template?
A "Stack" is a current and hopefully working software and machine configuration, that exists on the desktop of a user. The "RepRap Stack" is the software and machine configuration we guarantee will work. All other stacks are "Stuff that needs more research and documentation".
The particular RepRap or RepStrap system on someone's desk can be (conceptually) divided into a stack of regions or "layers". Usually a layer of the stack only touches and communicates to two other layers, the layers "above" and "below" it, with (hopefully) well-structured and well-documented interfaces.
Note: I may want to rewrite all of this as the "RepRap Stack", and other "Stacks". The RepRap Stack is guaranteed to work. Everything else is ongoing research, todo notes, abandonware, and so on. I'm not sure where the action items are yet. Besides "make the website better".--Sebastien Bailard 02:52, 14 February 2010 (UTC)
Presenting and maintaining a "RepRap Stack" of modules that work together is a crucial RepRap developer responsibility. As is documentation. Mind you, I might be working on an Eiffel, BitBanger, Extruder-and-Spindle aka Shape Deposition Manufacturing (SDM), and EMC Stack 50% of the time.
This is much easier with the Linux kernel, gnu tool chain, Filesystem Hierarchy Standard directory structure, X window software, KDE Desktop, and Firefox browser that I'm using right now, aka my "Browser Stack".
But helping maintain the wiki that we use to sort this all out is the responsibility of all of us.
Deleting everything but the current working Sat Feb 13 22:13:21 EST 2010 RepRap Stack is silly.
The way RepRap developers collaborate to design new, improved machines is similar to some models of bacteria-style evolution.
There are so many people involved in RepRap that every part of the stack is under research and development and simultaneously being improved by someone, somewhere.
One method of improvement is obvious: someone thinks up a different way to make something -- generally inside one layer of the stack, perhaps "merely" a little incremental improvement -- and does some cutting-edge research and development to see if it works better(*) that way than the previous known-working way in the RepRap stack.
A second method of improvement is not so obvious: someone gathers up a bunch of cutting-edge developments and confirms that they "play nice with each other" -- alas, occasionally they don't.
To make both methods easier, we try to design (hopefully) well-structured and well-documented interfaces, so it's easy to pull out any one layer and slide in a (hopefully better) layer. Hardware interface standards such as the RepRap Interface Standard, documentation standards such as the Printer Build Instructions Outline, etc. We want to make upgrading more like replacing an incandescent light bulb with a fluorescent light bulb, less like replacing the stock engine out of a Volkswagen Beetle with the kind of engine that the winner of the most recent Formula One race used.
We design little incremental improvements in terms of changing one layer -- or changing 2 layers and the interface between them -- not because anyone ever wants to upgrade only one or two layers and stop there, but because this design method is the fastest way we know of to develop a completely new known-working RepRap stack that is better in every way.
(*)"Better" in many different ways: higher precision and bigger build volume, faster print times, faster assembly and calibration time by relatively inexperienced potential new RepRap owner, faster doubling time, better interfaces to accelerate future improvements (perhaps by slicing a previously monolithic layer into two layers to make it easier to improve each one independently), lower net cost to a potential RepRap owner (perhaps by merging two layers to reduce interface costs), etc.
- New user-developers can't do this unless each step has been documented.
- Experienced user-developers would rather research and develop than document. If they are documenting and uploading parts files, which, happily, does happen, then it is unreasonable for them to support other combinations besides their Snapshot
- Entrepreneur user-developers want to sell one set of Mendel parts, or 50000 sets of electronics, filament, *Mendel vitamins and need RepRap to do documentation and support.
User 1 uses w0, x0, y0, z0. User 2 uses w1, x1, y1, z1. ... User 134533 uses w4, x2, y_not, z5.
Here is a list of all the layers of a stack. For convenience, we order the layers in order of data flow through the system.
For each layer, we (fixme: not yet true -- please edit this page to make this true) first list the current "known-working" version of that layer (in the RepRap Stack), followed by other alternatives in no particular order.
We archive an easily editable ("source") file in one of many File Formats, sometimes including formulas that document "design intent". Then, as needed, we "export" the data from that file into a temporary STL file to feed into the next stage.
Committee for Deletionism and Self-Censorship
- main article: RepRap_Options#CAM_Tools
Adrian-Slicer, Povray, Blender?, Rhino (Huh? Can you really use POVray as a slicer?)
The slicer slices up the 3D model into a series of 2D slices, and does tool path generation for each slice. It does the conversion between STL and G-code. See Useful Software Packages#Software for dealing with STL files for the latest list.
Tool Path Generation
Machine Controller Software
Machine Controller Electronics
- Main article: Category:Electronics.
3-Axis Positioning System
- Main article: Category:DriveTrains.
See Alt Select Mechanics.
Darwin, Mendel, Builders/LaserCut RepStraps, CNCRouterCut RepStrap, RepOlaRap, Delta, MillStrap, Eiffel, LeCorb, Unnamed PourStrap Named After Architect who Pioneered Prefab Poured Concrete Stuff , Sarrus Z Linkage , Alternative Rails
- Main article: Category:Toolheads
All the stuff above could be in a set of autonomous columns. It's a slot machine (or Enigma device) really.
Note: It will be fun to do this as a 'Slot Machine'-type desktop toy.