[Discuss] discuss Digest, Vol 10, Issue 6

[Chris Church]

On Mar 1, 2013, at 3:55 PM, Matt Maier wrote:

>  
> This is particularly evident when you factor in the wide variety of manufacturing steps that are as much a part of open hardware as the components themselves. If a cut has to be made then the tool that does the cutting is a prerequisite to capture the benefit of the design files. A drill is just as important as the bolt that will go through the hole, but a project should still be called "open" even if it doesn't include design files for the drill or the bolt themselves. Only the defintion of the hole itself needs to be opened.
>  

Hi Matt,

I think this is a great point, in some ways it is analogous to not requiring to include the std c libraries with every project that uses them.  

I wonder if, with mechanical parts, the software analogies hold up.  For example, a STEP file for non-trivial parts is more of a description of the output of a piece of software than the source code for the software.  Much like Gerber files with PCBs, it may be more appropriate to share standard GCODE if we're relating the hardware to the same level of sharing as we would see with software and PCBs.  

Obviously, for those parts that are 3D-printed and expected to be printed using slicing software, that's not required (nor may the author actually ever know what the GCODE was), but for more complex parts - it may be required to not only express the shape and form of the part, but the critical inputs for how to generate the right GCODE on the right machine.  (For example, surface finish, tolerance, maximal runout, tempering processes, etc.)

Perhaps the requirement should include "a description of the manufacturing inputs and processes required to make a functional part." even if they don't describe fully how to make an actual replica. (Which may be useless to someone with different machines/tools/processes.)

Chris