Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Standard parts and linked documents

3dcad3dcad Member, OS Professional, Mentor Posts: 2,475 PRO
edited April 2016 in Using Onshape
We got linked documents in last update. Highly requested feature and changes the way how we organize stuff into documents and tabs.

I would like to start some discussion on best ways to manage standard parts and other shared stuff.

In traditional cad, you just link the file & configuration and any changes made to that can break your assembly without you knowing when editing.
Onshape has prevented this by linking to version of document which cannot be edited. Good for robust design but makes it difficult to figure out what to model into single document.

Example: If you create doc nuts&bolts and add few nuts and create version to use them in another doc. Later you create more nuts and create another version to be able to reach them from another docs. Now assemblies that use 'the old' version give you the icon that newer version is available even though nothing has changed in those parts / tabs. So each addition to nuts/bolts library will create new version also for all existing parts.

It would be so much easier to figure out best practices if versions could be made per tab but I do understand also the importance of versioning the whole document.

I have a lot of special standard parts (furniture fittings/accessories) and the list grows all the time. I don't wan't to make new doc for each part which would be the only way I can see to avoid multiple versions without actual changes to part.

Currently all my linked parts show that there is newer version available because I'm in the middle of building the library as new standard parts are needed and I need to create new version after each update to 'accessories' document.

For now, I just need to disregard the icon reminding about never versions but at some point when there actually is newer version of that certain part, it will be not that easy to keep track on which docs should have the links updated. 

Any thoughts, opinions, guesses or experience?
//rami
«1

Comments

  • _Ðave__Ðave_ Member, Developers Posts: 712 ✭✭✭✭
    I think that I would like an option to break the link. If I import an object from a library in most cases that would be it and I wouldn't need any reason to update. Granted that for some there are cases where they would need the link but I'd like the option to break it.

    _Ðave_
  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,140 PRO
    edited April 2016
    Absolutely hear what you are saying Rami, this has been my experience too. I am all for the versioning before linking because of the scars I have in traditional CAD from assemblies and parts falling apart from changes unintentionally migrating in. But I am now see the little link showing up on all my bolts and nuts with no change to the individual part. 

    I did have a grand plan of building out my full fasteners Document so it's complete and doesn't require any more changes hence no little link icons but this isn't going to happen for a long time, if ever. I have also started a sprocket's doc, hydraulic ram's doc, gas struts doc, and general company hardware doc and it's going to be the same experience for each these alway being a living doc that has parts being added as required which in years to come could drive hundreds of links to be updated. Like you I want to use the document as the grouping container but versioning needs to be at the tab level or even better at the part level in this case to stop links pushing and we don't have a method of grouping neatly at the document level hence using the doc to group. On a pure design and concept development project I think I am fine with the links, just an issue on the common part doc's with high chance's of change.

    With these new linked improvements so far I have tended to take the view of reviewing the changes only on parts I know need updating and just leaving the link icon there for bolts or sprockets I know have no change, this is OK when it's just me but when collaborating with multiple user's across doc's may start to become bit confusing. 


    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • chris_8chris_8 OS Professional Posts: 102 PRO
    I agree, per tab versioning would be great, and per part might work out even better.   I tried organizing documents by using long descriptive names, but now half the names get truncated by the slim derived window, so many docs seem to have the same name :-o
  • _Ðave__Ðave_ Member, Developers Posts: 712 ✭✭✭✭
    I don't believe that the linked documents function was actually intended to be used with libraries.  I feel that we should be able to import a dumb part from another document without having to version or link. This may require a separate function which may be more appropriate to use with a library of standard parts such as nut and bolts.

    _Ðave_ 
  • robert_morrisrobert_morris OS Professional, Developers Posts: 168 PRO
    I've been giving this some thought here too and ran into the same issue with linking things like libraries of nuts and bolts, o-rings, etc.
    Document organization within Onshape is something that we are still trying to figure out as we have probably 1200+ parts and 500+ assemblies with many of those common across products. With traditional CAD it was fairly easy to keep things organized with folders, but that method doesn't really work well in Onshape.

    Right now, the current idea is to have the main products, certain subassemblies, and possibly certain common parts as their own documents and use links between them when needed. For library type parts (like nuts and bolts), they would be in their own document and when a specific item was needed, we would just copy its tab into the project instead of linking it since those items would likely never need to be updated.

    I'm always interested in hearing how other people are keeping things organized within Onshape as well.
  • 3dcad3dcad Member, OS Professional, Mentor Posts: 2,475 PRO
    I definitely need the links since my standard parts can change from time to time if I have new supplier or so. Or sometimes we might upgrade certain products with better hinge / drawer slide or so. In those cases I get BIG benefit of just making new version than copying&fixing hundreds of models.

    It seems like we all have quite mutual experience on current system, I would like to hear also some comments from Onshape if possible @scott_harris @lougallo

    I can live with this for a while to wait for configurations and other standard features to get implemented but as Bruce mentioned update icon can be very confusing when we really start to get collaboration possibilities into production use. And also with only one user after many years of modeling and using standard parts library it is difficult to manage version updates if icon is always there.

    //rami
  • 3dcad3dcad Member, OS Professional, Mentor Posts: 2,475 PRO

    ..

    I'm always interested in hearing how other people are keeping things organized within Onshape as well.
    This is one thing I haven't figured out yet. Everytime when I try to create frames and rules how to 'play' I change my mind.
    I have started a discussion on this earlier and it helped me a bit but I think also this issue needs all features (like configurations and improvements to infinite documents list) available before final conclusions can be made.

    Currently I have some documents where I have exploited versions feature to have completely different models in each branch - not so good.
    I have tried to put too much stuff in single branch, tab navigation gets messy - not that good either.

    I don't like copying tabs between docs but I haven't had time to fully explore the possibilities of linked stuff so I hope I will find some temporary solution there..
    //rami
  • scott_harrisscott_harris Moderator, Onshape Employees, csevp Posts: 66
    Rami, Bruce, Dave, Chris & Robert (and others...),

    Yes... currently when you (or a collaborator) creates a new version of a document that you have linked to, you will get the "newer version" indicator. The good news is that your link will never get wonky because it is to an unchangeable version (which is why we link to versions). You can totally ignore the update icons since they just indicate the reference document version status.

    If the linked items have not changed from version to version of the reference document, updating to a newer version will clear the notification symbols without changing the linked items.  

    Of course, if a part has changed in a newer version, you can selectively update it or all links together. If you do not like the results of an update you can restore your document to before the update or simply change  individual links back.

    The design philosophy is to never let references get lost/dropped and keep assemblies, drawing views and derived features completely stable.
    We are continuing to think about ways to manage versions and updates so your input and issues are really useful to hear about. 

    /Scott


    Scott Harris / Onshape, Inc.
  • robert_morrisrobert_morris OS Professional, Developers Posts: 168 PRO
    The document linking is definitely a huge and necessary improvement for us here since we do have a lot of common parts and we will be making heavy use of it. I also really like the way it is tied to versions to help prevent breakages down the line.

    The only issue that I think we (and others it sounds like) have is in the case where there is a "library" document for things like bolts, brackets, etc., and a new item is added to that library, it will cause an unnecessary version bump which can trigger a "newer version" update request in a bunch of other documents where nothing has actually changed. Even then, it's more just a minor annoyance than a real problem.

    One possibility that I can think of that might alleviate the issue would be a way to "pin" a linked item to a particular version so that it would not show an update request icon until you unpinned it. The "link" icon in the feature tree should probably be changed to something else when pinned (maybe a pushpin?) so that it was obvious that it was "pinned" instead of an "active" link. Just tossing out an idea, and I'm sure there are some other details that would need to be worked out with it.


  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO

    One possibility that I can think of that might alleviate the issue would be a way to "pin" a linked item to a particular version so that it would not show an update request icon until you unpinned it. The "link" icon in the feature tree should probably be changed to something else when pinned (maybe a pushpin?) so that it was obvious that it was "pinned" instead of an "active" link. Just tossing out an idea, and I'm sure there are some other details that would need to be worked out with it.


    +1
  • raj_Onshaperaj_Onshape Onshape Employees Posts: 110
    One possibility that I can think of that might alleviate the issue would be a way to "pin" a linked item to a particular version so that it would not show an update request icon until you unpinned it. The "link" icon in the feature tree should probably be changed to something else when pinned (maybe a pushpin?) so that it was obvious that it was "pinned" instead of an "active" link. Just tossing out an idea, and I'm sure there are some other details that would need to be worked out with it.


    It might be better to do this pinning per element at source otherwise every time you insert the bolt into a new assembly or another instance you will need to remember to pin it.
  • 3dcad3dcad Member, OS Professional, Mentor Posts: 2,475 PRO
    edited April 2016
    I like @robert_morris idea with @ptrajkumar edition since it would also allow to use version for creating actually different versions with same level of importance (no older/newer, only different versions of same part) without system pointing out I'm using old version and I should update.

    I agree this is minor thing at this point, but if you ever need to create that newer version of standard part and you need to update few hundred models to use the newer version, that little icon can be very precious to tell you if model is up-to-date and ready for manufacturing.

    ps. Thanks for @scott_harris and @ptrajkumar for hopping in, it keeps the value of this forum very high.
    //rami
  • tom_scarincetom_scarince Member, Developers Posts: 47 ✭✭✭
    edited April 2016

    Thinking out loud here. How about this: If there is a newer version, but the part itself has zero change, why do we need an icon?   At least have it grayed-out or something.  "New version, same as the old version..." 

  • robert_morrisrobert_morris OS Professional, Developers Posts: 168 PRO
    @ptrajkumar
    Does that mean you would pin an individual part within the Part Studio that it was created in so that it stays at its current version even if you change the version of the document?

    How would you manage the versions and what would happen if you later unpinned the part?
    Would its version automatically be changed to the version of the containing document?
    If so, I can see issues with someone accidentally unpinning a part, the version changing before they re-pin it, and then we have the same problem with multiple documents all wanting to be upgraded.

    The idea of pinning something only once at the source sounds great for a library part, but it seems like it could be complicated to do correctly.
    Pinning at the instance level seems like it would be easier to manage even if it's a little more work for the user.
  • raj_Onshaperaj_Onshape Onshape Employees Posts: 110
    @robert_morris   If there was a standard library that had a bolt A in it.  and A was never going to be superseded i felt it would better to specify it with version rather than specify it on a instance every time it was inserted. It seems like what you are proposing is a freeze/unfreeze that also has it uses.

    Assuming a doc D.. that has tab X and Y.
    X was changed in V1.
    Y was changed in V2.  the model state of X is same in V1 and V2.

    Now assume we insert stuff from X into a new document E. Currently we would show on instances linked to X that they could potentially be updated to V2 even though the change would not do anything to the E.

    Would simply detecting this special case and not showing X with blue icon suffice for most needs ?

    Would there be more confusion when someone else opens E few months later and sees E referring to both X from V1 and Y from V2 ? Would his life be easier if E was only referring to V2.






  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    @ptrajkumar   The real fix would be allow derived parts to specify the HEAD of a branch (I guess this is a workspace in Onshape parlance) instead of a version if desired.

    When one is in the initial development stage of both documents, the derived features will stay up to date as changes are made. Later when things are less in flux, one can lock down any of the derived features to a specific version.

  • raj_Onshaperaj_Onshape Onshape Employees Posts: 110
    @traveler_hauptman In both of the scenarios that you have outlined there would still be a need to stop the update/notification from happening and start it back again. Or are you suggesting that once you lock it to a specific version there will never be a need to update it again ?
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    One would not need update/notification when linked to a workspace... it will always be current. (ie in the same way that onshape synchronizes between tabs open in different browsers. I realize that it means a little behind the scenes work for you guys depending how you handle transactions and a little latency for us in the interface while you check microversions of dependent documents on rebuild...)

    Current update/notification behaviour when linked to a version works fine, thought I like the addition of being able to disable the notification if you want to (my interpretation of the pinning behaviour described above).
  • robert_morrisrobert_morris OS Professional, Developers Posts: 168 PRO
    @robert_morris   If there was a standard library that had a bolt A in it.  and A was never going to be superseded i felt it would better to specify it with version rather than specify it on a instance every time it was inserted. It seems like what you are proposing is a freeze/unfreeze that also has it uses.

    Assuming a doc D.. that has tab X and Y.
    X was changed in V1.
    Y was changed in V2.  the model state of X is same in V1 and V2.

    Now assume we insert stuff from X into a new document E. Currently we would show on instances linked to X that they could potentially be updated to V2 even though the change would not do anything to the E.

    Would simply detecting this special case and not showing X with blue icon suffice for most needs ?

    @ptrajkumar    Yes, that sounds like it would work.

    I think I understand what you are proposing now. The "pinning" in this case would not be done by the users, but simply the software detecting that there wasn't any changes to X (using your example) and not showing the update icon. The icon would then show only if there was an actual change to that specific item.

    Would there be more confusion when someone else opens E few months later and sees E referring to both X from V1 and Y from V2 ? Would his life be easier if E was only referring to V2.
    If the software could detect that there wasn't any actual changes to X, then perhaps it could be automatically upgraded to V2 without a notification?
    Even if it can't do this, I don't think it will be a problem as long as it's still available to update manually via the "Selective Update" dialog.


  • robert_morrisrobert_morris OS Professional, Developers Posts: 168 PRO
    @traveler_hauptman
    I think that requiring the part/assembly to be linked to a specific stable version is what makes it better than other CAD systems.

    Having an assembly or part studio linking to an item that automatically propagates geometry changes is basically the way it works in programs like Solidworks, and can cause lots of breakages down the line - usually when you are in a hurry and don't have the time to fix them.

    Also, the problem of not requiring the link to be to a specific version is that most people would probably just link to Main by default (because it's easier for them) and then they will get frustrated when things start breaking. For instance, say I create Part_A and link to the Main workspace from another document (Doc1) before saving a version of Part_A. Later on when I make a change to Part_A, and it causes something to break in Doc1, I can't switch it back to a working version because there is no version to switch back to.


    I prefer the Onshape way of linking, that way I can worry about fixing any update breakages when I have the time and not have to stress out about it.
  • traveler_hauptmantraveler_hauptman Member, OS Professional, Mentor, Developers Posts: 419 PRO
    @robert_morris I'm not suggesting Onshape remove the current behaviour. Just add useful capability.

  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,057 PRO
    edited April 2016
    I'm not sure a library is a good use case for shared documents. 

    I was thinking that shared documents would be used for larger projects where multiple companies where involved in the design process. Now you have the ability to link to what others are doing and staying current without any effort.

    Currently, on multi-company projects, using an older CAD system, I have to ask for a zip file of the other companies work. Then I have to thread into my layout. Most don't agree on coordinate orientation or don't understand assembly by coordinates so it's a struggle every time you request an update. 

    Since we now have shared collaboration, I see this as a big picture snap shot never seen in a CAD system. One place to get things done for everyone.

    Don't get me wrong, I'm still waiting for the basic design work flow:
    concept->layout->parts->assemblies->manufacturing->data archive



  • 3dcad3dcad Member, OS Professional, Mentor Posts: 2,475 PRO
    @billy Are you thinking about some kind of built-in standard part library where we could manage maybe constraints too so that when you add bolt it snaps into suitable holes and click would confirm and let you select next hole.. ?
    //rami
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,057 PRO
    edited April 2016
    3dcad, no, libraries are important, but I was thinking more about a large project with many engineers & contractors. Currently parametric modelers work well with one guy managing/doing everything but when you start adding people, you need to start planning and adding organization to your document structure so everything stays copacetic.

    Collaboration is something I'm really interested in and I've been waiting for a long time. I think OS has a really good chance at making it work well. It's still going to require a plan & implementation. One rogue engineer can mess everything up.

    For library parts, I just insert them into a part studio using derived components. I typically run them through parasolids and strip out the parametrics. I typically de-feature them as not to create a video issue. A bolt from mcmaster will get a cylinder drawn over the threads to help minimize display over head. I spend a lot of time making sure my library parts are good to go.

    Yesterday, playing in sw2016, a tab popped up telling me to run solidworks RX, so I did. It basically told me SW wouldn't run in my virtual environment, but more interestingly, it warned me that I had a local version of toolbox. It's been 25 years and they still have issues with that library and how to install it. I guess it's not an easy problem to solve.

    I'm wondering if you can nest an linked document with each of these being linked documents having many tabs:

    Library
    -connectors
    --amp
    --molex
    -screws
    --metric
    ---shcs
    ---bhcs
    --imperial
    ---shcs
    ---bhcs

    This would be a mess to navigate and to find something once it gets large, impossible. Not sure this scales.

    If you became a solution partner, you could build a library data structure that google could index and then you would have search in your library. You can build/maintain your own search or expose your database to google and let the world know. You could build a simple front end to all of this allowing you to find stuff and construct a really nice library. If you got good at programming, you could build a spider that scraps every existing 3D library and add it to your own. If you do this you'll have to figure out how to index it because it'd be huge. 

    I fear building a library at a user level could be problematic in that the larger it gets the harder it becomes to find stuff. 



  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,057 PRO
    edited April 2016
    So I was working with a young engineer and talking about design work flow in parametric modeling.

    I cited this:
    concept->layout->parts->assemblies->manufacturing->data archive

    I realized this is old school, pre-cad, drafting board circa.

    PTC omitted (concept->layout->) forcing us to:
    parts->assemblies->manufacturing->data archive

    PTC realized their error and gave us design in the assembly which made the assembly kinda like a layout:
    parts->assemblies/layout->manufacturing->data archive

    or loosely like this:
    assemblies/layout->parts->manufacturing->data archive

    Since no body talks about a layout any more, we have 
    assemblies->parts->manufacturing->data archive

    No body starts a project in an assembly, so what's wrong?

    Anyway, I told this young engineer that it was ok to be confused about how to start a design using a parametric modeler.


    Read this, we're all struggling:
    solidsmack



  • 3dcad3dcad Member, OS Professional, Mentor Posts: 2,475 PRO
    I'm a simple guy so I would prefer model (combined parts&assemblies)->manufacturing->version archive 

    How would you @billy work with standard parts used in many models that needs occasional updating to newer version?
    //rami
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,057 PRO
    edited April 2016
    Create a new part & move faces. This is how I'd manage a dumb solids library.



    We're talking about purchased parts right?

    Are you talking about your own common assemblies  part studios?


     
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,057 PRO
    edited April 2016
    Combine layouts & parts & assembly, hallelujah brother! 

    Maybe in another decade,



  • robert_morrisrobert_morris OS Professional, Developers Posts: 168 PRO
    @jon_hirschtick
    I think that idea would work great, both for library parts and our common in-house designed parts.
    That way we can update the version of a product document and not worry about other documents that use common parts requesting an update if they don't really need it.
Sign In or Register to comment.