Standards Development
What are standards?
Standards are tools incorporating criteria which any Reprap developer is free to adopt when designing something for RepRap. In Standards Development terminology Standards are developed for "Modules" which are self contained elements.
Currently there are no standards. This Wiki page is here in anticipation both of there forthcoming creation and of your participation in the process.
What is the RATIONALE for developing standards
In the developers' Forum Adrian posed the following question: How do we both encourage RepRap mutations and stay focussed?
RepRap development pathway: Currently there is a tendency for us to have models e.g. Prusa which refer to specific whole reprap machine configurations.
Standards offer an Alternative Development Model
The alternative notion of modules offers a more flexible structure which would improve the opportunities for mutations.
OVERVIEW 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.
Standards will come about through an incremental method which slices and dices Reprap into large scale modules. Each module irrespective of type would lay the groundwork for configuration master system which could then recognise the modules used to build any particular reprap machine. This would mean MLC Data could be used to assist rapid configuration and testing of the whole system.
MORE DETAIL
This description is intended to make sure everyone understands the concept of modularity with which the writer is familar. It is important to understand that defining standards does not create an expectation that everyone will adopt them. Standards are definitely not an authoritarian system from hell!!
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 used by designers to build such systems. They deal with all sorts of modules which may be incorporated within any 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 the forum thread is substantial. 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.
The writer invites the community to envisage [MLC Data] "Standard" as a model for defining the kind of standards we need for a RepRap world. 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 can lead to a reduction in design and build costs by removing the 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.
Standards development is arguably 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. MLC standards might 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!
The proposal is to create 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.
Designers/builders may offer MLCs 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. Those who support standards development believe this will, in turn, lead to lower costs, easier configuration, cheaper systems, greater competitiveness, simpler adoption procedures and facilitate standardised documentation for users.
