Standard Parts - what is the best way to reuse them?

pete_yodis

billy said:

pete-


Pete, kinda sounds like you might like a meta data driven CAD environment vs. drawings. Am I pushing this to far?

@billy ;;; Ah man, you're baiting me into this one... alright, I'll bite - but the caveat that this is really a side issue on this thread and I don't want to highjack it....

You might not be pushing it far enough.  I've said it elsewhere on another post that we treat models like second class citizens in comparison to drawings and that's really ashame because thus far in 3D CAD modelling we haven't allowed 3D models to be what they really could be.  I think geometry definition of the model should be like object oriented programming.  The objects or features of the geometry, if possible, should have information defined about them much like a class has properties and objects have properties and objects can belong to classes... etc...  So,  the definition of a hole should not just contain the raw modeled size, but also have information attached to the hole about the hole - metadata as you mentioned.  What tolerance, what expected probability distribution, etc...  This way of working could be awesome and would completely blow static semi-attached drawings out of the water.  I do not want information existing on drawings that can't exist on models and be pulled from the model.  Notice I did not say eliminate drawings... allow us the choice of whether we need them or not, but don't let the shortcomings of the definition of the geometry on the model drive us to needing drawings all the time.  If models contained information like this, then they could be machine readable and be applied intelligently to inspection and CAM and FEA and tolerance analysis and whatever else... Is that far enough? 

Another step farther.  I think geometry definition, as much as possible, should be like the synchronous technology in Siemens products.  I want the faces of the geometry to be where the information resides and not in underlying sometimes overriding complicated relationship based sketches that can become jigsaw puzzle Rube Goldberg material when I just want to change 1 wall in a complicated injection molded part design or metal cast design.  I want the creation of the model to be the same as the documentation of the model.  That is where synchronous technology is going and it makes total sense.  Do not divorce the editing/definition of the model from the documentation... make them one and the same as much as possible.  A convoluted history tree, with a separate MBD/PMI layer, with a separate drawing yet again is too many places where information can be at odds with one another.  That's too SolidWorks like (ugghhh they make you pay extra for the convoluted MBD module!!))

Yet another step further.. I want the digital definition of the model to be able to be tied to the physical, via QR codes or something like it.  I want augmented reality projection of the digital/virtual to be projected onto the real.  How about that for dreaming?

pete_yodis

Back to the thread and it's main topics after @billy and my soapboxing...

@brucebarlett @3dcad Onshape is definitely working on interdocument referencing.  They have to be if they are working on drawings  .  There will definitely be considerations as to what happens when references change.  Do you want the references automatically being rolled up into where they are used?  This is an issue with file based check-in check out data management systems - the main difference is that Onshape has completely lowered the overhead with not needing to check-in and check-out.  Regardless there does need to be consideration of how changes to references ripple through.  There is a lot going on here and it relates to shared community libraries and drawings and inter document referencing and data management and workflows.  It's all related.  I don't mind if Onshape takes their time here and really get's it right.  The unwind could be nasty if they don't.   @ilya_baran latest blog post on what's going on under the hood with microversions really sheds more light on this.  The management of microversions must be really right when you start adding in all these other things.  And all these other things must be right to add more things on top.  Really neat stuff.

pete_yodis

I think Onshape's use of the Agile process is also at play here.  I would think they would want their technology partners to be able to kick the tires a bit and then for things to cement further as they see their partner's needs and pain points.  I've been interested in seeing how the technical partners implement how their data or model gets updated when the Onshape model changes.  Is it a straight refresh button for some, a dynamic update for others, a reference to a particular point in time that is hard-locked? 

stephen_dohan

Standard part libraries are always an issue. Too much effort is dedicated and duplicated in each company.  An old work around we used for years is copying a series of hardware in an assembly (document) and distributed to users. I am interested to see what approach OnShape takes.

 

michael_k_sanders

@philip_thomas Has there been any progress on improving this workflow?

dennis_20

Check out this Improvement Request and vote for it:  https://forum.onshape.com/discussion/1407/public-standard-parts-library#latest

philip_thomas

Michael - the short answer is yes, but some of it is future functionality.

Since i started this thread, the app store entered beta and there are 2 partners that enable the insertion of standard hardware directly into a document. Those workflows work well where the standard parts do not change. The BOM app (also in the app store) does a good job of collecting together components by the same name to assure accurate part counts.

Between the methodologies described here and the app store capabilities, you can certainly get your job done.

Moving forward, there are coming enhancements that will significantly enhance the re-usability of standard parts (think of a 6 week horizon, but as always, only when it's ready).

I hope this helps

florian_ford

What about reusing my own "library" by inter-referencing documents? I create parts that will be used in other documents.
I'd like to be able to import one of my own documents (part studio + assemblies) and be asked what I want to do with it: use it as is (this will change in new documents if "master" changes) or "fork" it (or just parts of it) and It will fork it so I am able next time to choose this fork to include in one of my future projects.

Is there any documentation if this can be done? or will be?

jiri_r_

[deleted because of irrelevance]

Anyway, that step which creates the Standards Parts part studio is not very clear.
http://bit.ly/OnshapeSampleStandardParts)

Why these are there?
- boolean
- unique id
- mate connector

Jiri