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

larry_hawes

...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

konstantin_shiriazdanov

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.

konstantin_shiriazdanov

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_hawes

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.....

NeilCooke

Duplicate Part Studio is probably the only option. 

konstantin_shiriazdanov

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.

larry_hawes

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_shiriazdanov

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_hawes

konstantin_shiriazdanov said:

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_hawes

konstantin_shiriazdanov said:

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...

lana

@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.

billy2

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_hawes

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...

billy2

@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_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_mcclary

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.