Standard parts and linked documents

billy2

So it's the weekend and I thought I'd try and build a library using nested linked documents.

So I have 3 documents:
v4 light- is my current layout (yeah, I know, I should be versioning, from now on)
library- is the top nested linked document
library electronics- is a sub-nested linked document


Bring in an electronic part from library electronics:
Since both libraries are easily accessible why nest them?


Library electronics is one sub-library that's link to library:
Copying part studios into the library electronics was really easy to do. Meaning, to construct a library is pain-less.


My Library consisting of sub-nested linked documents
A nested library has to belong to either a part studio or an assembly. I created both a part studio and an assembly not knowing which is better. I think the flaw in my nested idea is that a library can't point to library electronics and absorb it's resources. You'll have to maintain library to include the latest library electronics. This is just too much work nesting linked documents making a library.



Conclusion:
Putting this straw-man together using linked documents was easy and intuitive. Linked documents capture every permutation dealing with changes which for a library is too much. Changing some part names and adding a capacitor to library electronics caused my libraries to rev to level 3 in less than 5 minutes.

I think a library is important but I don't think link documents is the right tool.

Managing purchased parts in a linked document seems bothersome. Managing well established common assemblies seems likely in one library document. If you had 40 assemblies in this library, I'd suspect that at the end of the month you'd at version 2134. Let's say you added an assembly every day and made it available, remember you have to version the linked document, you'd have 30 revisions in a month. This is just adding stuff to the library.

Should linked documents change? I don't think so. If you try and manage a large project with multiple engineers, I think linked documents is a perfect tool for controlling every aspect of a project. This is a good thing. I'm a little concerned that an engineer has to version a design before it shows up in a master layout that has multiple linked documents. Need to build a simple straw-man and see if this is true.

My next straw-man will be to create a project with a shared master layout containing datums and see if I can create a structure inside Onshape for large assembly management utilizing collaborating engineers, outside companies and contractors. I think linked documents will make more sense in this application. I'll see if I can control a project from the top.

3dcad I can't envision a library here. I could write a bitch'n library using solution partners tools. If you come up with a good solution, please share.

billy2

Thinking about this yesterday, I guess it just comes down to the fact that not everything requires revision control. A library is a perfect example of this and shouldn't be under revision control. The parts inside? Absolutely need to be under revision control. OS has done a great job at version control, ok that's wonderful, now, how do I turn it off?

Wish we had versioning at the tab level so I could version each part as opposed to just the document or the family of parts. I'm not sure document versioning by itself will work for a library implementation. I think we need tab versioning.

I keep talking about a partner solution for a library. The changes above will make a library feasible at a user's level. The benefit of writing a partner solution app for a library has to do with search. A partner solution app could allow you to setup categories,  some type of meaningful index for your company. 

I'm learning eagle cad for designing circuit boards. The program is straight forward but learning where things are in the library is difficult. Setting up a library so people can find things is the next challenge.

tom_scarince

Ok, I've finally had a chance to play around some with versioning and linked documents.  

I had a theory that you could create "releases" of a library.  You could create a side branch, create a version and then leave it as a dead end.  You could then insert parts from this dead end version into other documents.  Later on you add some more to the library and create a new branch and dead end version.  Parts inserted from the old version don't get flagged because the newer version did not descend from them.  

Now lets say you had an actual update you needed to make to one of those old parts.  You could delete anything nonessential from each dead end version, merge them all back into the main branch, change the part in question and then create a new branch and version as you've been doing.  This ought to flag all those parts everywhere and allow them to be updated to the latest.  

However, it doesn't work that way.  

Here's one experiment:

• Create two branches.  
  
• Create a part1 in branchA and then create version1 in that branch.  
• Insert part1 from version1 in another document.  
• Go back to the source doc, switch to branchB and create version2.  
• The destination document now shows an icon for a more recent branch available, so you update to version2.  
• Part1 is now broken in the destination document because it doesn't exist in version2.  

Key concept is that a version is only a snapshot of one branch, however onshape flags a part whenever its document has any newer version in any branch, even if the part never existed in that branch.  

I'm more and more convinced that there has to be some sort of revision system to complement the version system.  It has to be automatic and sensitive to actual changes to each part and maybe also allow a forced rev bump for external factors that may not be reflected in onshape like purchasing specs.  You ought to be able to push the change out from the part as an alternative to wandering through all your documents looking for update icons.  Which reminds me, what about a "where used" functionality?  

Now, onshape is doing great things with every update and I have no complaints but I'm dying to know if there is some kind of roadmap for how they hope to get to a system that fulfills the purpose of a traditional PDM, ECO and rev control system even if it will accomplish the goal in a totally new way.  

traveler_hauptman

+1 for 'where used'. Nothing like coming back to a part after a year or two and trying to figure out what products you are going to impact with a change.

brucebartlett

I agree "where used" would be a great tool. Not sure where it would live though. I thinking the home document screen but there would first need to be a granular part search similar to when inserting in a assembly. 

robert_morris

+1 for "where used"

I created an improvement request for an advanced search of the Documents page a while back. Here is the link, please give it a vote:
 https://onshape.zendesk.com/hc/en-us/community/posts/210545607-Advanced-Document-Search

With that you 'should' be able to search for a part and find out what documents it is used in.

3dcad

+1 for where used
After another year with using links to documents I would like to see some sort of quick map of links between documents. I would also like to have quick view for any document to know if it has external links or if it's linked to external docs. We all know that situation where you do some housekeeping and delete stuff that breaks old assemblies ..

3dcad

billy said:

..

3dcad I can't envision a library here. I could write a bitch'n library using solution partners tools. If you come up with a good solution, please share.

I would like see the first iteration of configurations before making my mind with standard parts library - those two walk pretty much hand in hand for me.

One thing I expect for sure is that we should have some automation in assembling standard parts (create rules once, use later with 'one click'). I'm thinking something like named holes/patterns in part studio that are setup for some standard part from the beginning.