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.

Is There a Way To Save a Derived Part as its Own New Part...

larry_haweslarry_hawes Member Posts: 478 PRO
...breaking the link to the original derived part? I have some features added to a derived part and would like to use this as a new and separate part. Is there a way to do this or does the derived link have to remain in place? Tried to make the question a little more confusing but couldn't do it, sorry...and Thank You

Best Answer

Answers

  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 1,221 ✭✭✭✭✭
    Derived maintains single direction associativity, so that all changes in the original body are reflected in the derived copy of the body, but no changes of the copy affect on the original body - it's just a new body, which geometry is a copy of original untill you don't modify it.
  • larry_haweslarry_hawes Member Posts: 478 PRO
    Thanks Konstantin and understood, was wondering if there's way to break that single direction association, and save the new features as a completely new part? I am getting in to deriving derived parts from derived parts and want to simplify things a bit by saving all the derivations as a completely new part, maintaining all the features. Question seems a just a little dumber each time I ask but.....
  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 5,305
    Duplicate Part Studio is probably the only option. 
    Senior Director, Technical Services, EMEAI
  • larry_haweslarry_hawes Member Posts: 478 PRO
    Haven't used 'duplicate' feature before. Is it different than copy and paste new tab? Seems to keep all the derived part links intact which makes sense. Trying to break those derived links but might defeat the purpose of derivations.
  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 1,221 ✭✭✭✭✭
    duplicate is a quick way to make a copy of part studio within the same document, copy tab/paste tab works even between different documents
  • larry_haweslarry_hawes Member Posts: 478 PRO
    Now it got clearer. I should say that what you doing - deriving and modifying is a normal practice, as well as copying in place and modifying or making copy of part studio, or making branch. But you can't merge a chain of modifications from different part studios into one, only reproduce it manually.
    Thanks again Konstantin and appreciate your accurate reading of my question. I sometimes only get to work on projects sporadically and forget which is derived from which and it gets quite confusing but that, I think, is the nature of any complex task.
  • larry_haweslarry_hawes Member Posts: 478 PRO
    duplicate is a quick way to make a copy of part studio within the same document, copy tab/paste tab works even between different documents
    Nice, did not know that...
  • lanalana Onshape Employees Posts: 689
    @larry_hawes
    You could repoint derived part reference to a version in the same document. This way derived part studio does not update for every change in the base, but if you need to update it, you can manually repoint it to a newer version.
    Long chains of derived would hurt performance, less frequently if referencing versions, but it might take a hit when we loose caches.
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,014 PRO
    edited June 2019
    I'm trying to use the version graph more often now to control these scenarios:


    I know it's not totally understood right now, but it has great potential. One thing that I'm discovering is that things won't / and shouldn't merge back to main like GIT does. Controlling all the permutation of a design for a product should be manageable using the version graph. Should be. I understand the tendency to use documents & tabs with copies, because that's where we're coming from which is easier to understand but may be more difficult to manage for the long term.
     
    I'm constantly deleting stacks of features that didn't work out only wishing I had captured the end point with a version. I still need to work on documenting the creative process.

    If anyone has a good example, please post.


  • larry_haweslarry_hawes Member Posts: 478 PRO
    billy2 said:
    I'm trying to use the version graph more often now to control these scenarios:
     
    I'm constantly deleting stacks of features that didn't work out only wishing I had captured the end point with a version. I still need to work on documenting the creative process.

    If anyone has a good example, please post.


    This is good advice...
  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,014 PRO
    @larry_hawes I keep telling SW people not to use configurations because you can't manage them. And it's true, even with PDM, the longevity of a project with configurations in SW is short lived and a mess.

    Hoping with a graphical representation of the creative process, a little discipline, we can have a better understanding of what happened and where we're going. At least from a design & manufacturing stand point.




  • Hunter_1Hunter_1 Member Posts: 1 ✭✭
    I know this is an older post, but I just ran into this very problem, and was not having much luck with getting the versioning to allow derived parts to be modified and then used again in the original part studio. My very inelegant solution: export your part as a Parasolid, then reimport it into your project. You no longer have the history tree associated with the creation of that part, but it doesn't matter if you are trying to circumvent that historical link anyway. This can lead to some messy organization of a project, but unless you have some major revision early on in the original part studio from which you were deriving the part, then it probably isn't that big of a deal...assuming you aren't working collaboratively.
  • john_mcclaryjohn_mcclary Member, Developers Posts: 3,890 PRO
    I'm not sure why you would want to derive a part into another studio, modify it, then bring it back into the original studio. 

    That would be a circular reference. 

    You may be better off using incontext instead. 
Sign In or Register to comment.