Standards Development

From RepRap
Revision as of 07:49, 4 November 2017 by Jobo (talk | contribs) (Standards in development)
Jump to: navigation, search
Crystal Clear action run.png
Standards Development

Release status: experimental

No image available.png
Description
A page for discussion of mechanical and electronic standards.
License
Author
Contributors
Based-on
Categories
CAD Models
External Link

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.

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

Standards offer an Alternative Development Model

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

Standards are not an authoritarian system!

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 when a standards is defined it does not create an expectation that everyone will adopt them. Standards are definitely not an authoritarian system from hell!!

Where are standards to be found?

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.


Meeting Adrian's Challenge using Standards.

Think of RepRap machines as systems built with interchangeable modules


Adrian gave us all a substantial challenge when he started the forum thread on how to deal with mutations and stay focussed. 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! We may be heading that way unless we pay immediate attention to the creation of standards to facilitate modular development and interchangeability of modules. In other words we start to think of reprap machines as systems built up from interchangeable modules.

Avoiding Whimsical Mutations


A system of standards invites the RepRap 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 any designer can then apply any relevant and available standard to assist the design process. This can give the designer confidence that designers of other modules can build them in fully compatible ways. That is exactly what happened with usb. Standards combined with Modularity leads to a reduction in design and build costs and removing the need to design multiple versions to meet meet arbitrary differences in MLC configurations. Such differences 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.

Who will adopt Standards?

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. This means designers/developers/users who have the greatest desire to support an open systems model are most likely to adopt standards because they do not wish to lock users into a "closed" model.

On the other hand Designers/Builders who, for commercial or other reasons, do not favour an open system are most likely to avoid them.


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

Modularity and open standards combine to ease the development path.

For example carriages could adopt a mechanical design standard to facilitate the attachment of alternative heads with a mechanical connection that accords with the M (Mechanical) portion of the relevant MLC standard. Such a head would also be able to offer a signalling connection when the carriage is desigtned to meet the C (connection) portion of the relevant MLC Standard. Another designer's head would be able to take advantage of the C portion if itsn design also meets the C portion of the relevant standard. The same comments apply to the L (Logic) portions of the relevant standards. [NOTE Standards do not have to be inflexible or exclusive 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 for another example. 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!


How do we set about creating standards?

An incremental approach


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.

Standard compliant adapters for existing designs

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.


Designing standards with the potential to maximise user benefits by increasing effective functionality.

What modularity can do is 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.

Using successful standard initiatives as a model for RepRap standards development.

Standards and modularity were the tools that enabled the PC world to meet the challenges of massive growth and virulent developmental mutation. The demand for upgrade paths (either adapters or replacement modules) was also easily met through modular adaptions for PC system upgrades. This means the combination of modularity and standards can facilitate the organic growth path essential to meeting the mutational challenge Adrian identified.

Making Standards earn their spurs.

Standards are not prescriptions to be enforced but voluntarily adoptable tools to facilitate design, build & operation for diverse and mutated systems.


Summarising the Benefits of Modularity and Standards.

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.

Standards in development

Vertical_X_Axis_Standard A standard for interoperability between the various mendel style bots that have adopted a vertical X axis arrangement.

Motor_Shield_Standard A standard to 'define' the ie: pololu, A4988, DRV8825 (stepper motor/pcb) interface. To enable modification by RepRap users, developers, and encourage the unimaginable, within the reprap community and elsewhere.