Remove Part # references when copying a document

Jed_Yeiser

My team and I duplicate documents often to create new sizes of a design, or to create a related design. When copying a document, all part numbers from the source document are retained in the copied document and treated as a revision of the part in the source document. This means that when releasing a new design, we must first manually clear out part number references in a release candidate before generating new part numbers. I'd love to see an option to 'Clear Part Numbers' when copying a document so that the new (copied) document has 'fresh' or no Part Numbers assigned to bodies generated in Part Studios. 

S1mon

When you mention new sizes or related designs, I can't help but wonder why you wouldn't be using configurations and then configuring the part numbers?

How similar are these new documents?

Jed_Yeiser

Hey @S1mon, the model structure of the documents is similar, but they are fundamentally different designs. Often (nearly always) the different geometry requires tweaks in the feature tree, so configurations would fail. 
Thanks!

S1mon

Without seeing the models it’s hard for me to say, but configurations can control just about any aspect of a feature tree. Suppressing features, changing values, flipping directions of extrudes, changing appearances, etc. 

I can see that configurations may take more effort than they’re worth in some cases, but if you’re copying a document to create another one that sounds a lot like there might be enough commonality to warrant a configuration approach. 

romeograham

@Jed_Yeiser

Here's one approach. We have a similar process: it makes a ton of sense to copy workspaces, but then Properties have to be updated.

We use an Assembly with a BOM template for editing Properties.

In this assembly you can put all of the parts that you will release from the document - and can edit all of the properties at once. This would include deleting all of the old part numbers, names, descriptions etc, and then applying new part numbers quickly as well.

If you aren't ready to assign new part numbers at this stage - at least remove the existing Part Number properties so you don't accidentally release the wrong part!

We have started to use configured Part Studios for design - and then deriving EACH configuration of parts into their own Studio - and applying Part Numbers etc to that derived part. This means that Released configurations are much more visible and discoverable in the document later, since they each live in their own tab. (When a configured part is released, you can't see that it's released unless you happen to show the correct configuration in the configured studio tab).

We basically use a folder structure in the document:
Design

Parts

Drawings

Assemblies

etc

etc

In Design - there are only Part Studios for Design (configurations, working bodies and surfaces, etc), Variable Studios, Reference images, etc.

In Parts - Part studios with a single configured part with all properties, materials, sketches for drawings etc.

In Drawings - just the drawings for each of the things we need drawings of.

etc

etc

If you have used Publications, you can see the benefit of having each configured part in it's own tab - because Publications can't (yet?) have only 1 part in a tab - you can only put a complete tab in a Publication. This makes them virtually useless for Project managers, leadership, customers / vendors - because they have to wade through many bodies, surfaces, sketches, curves, and configuration settings to find the Released part that is supposed to be in that tab.

Jed_Yeiser

romeograham ! We're using a similar(ish) process where one main part studio creates most of the surfaces we're going to need for part creation (~20-100 surface bodies) with some custom features and then deriving those surfaces (and variables through super derive) into individual part studios for each individual part. We're not currently using an assembly template as you suggest - I'll look into this as it could simplify matters. 

@S1mon
To be fair, I probably need to take a deeper look at configurations. There are instances where I could see configurations working, specifically different sizes of a given construction (my team and I are the ski engineering arm of a ski company, so different sizes here would mean different sizes of skis). The challenge with this approach is being able to see documentation and data for multiple different sizes at once to compare. We will often take one 'model' (read: Onshape Document) and copy it for use in a completely different ski construction. The data for the new ski construction needs to be maintained separately and - aside from some feature tree structure - really doesn't share much in common with the source document. I've always seen configurations as 'slightly different versions of the same fundamental thing' whereas unique documents are 'fundamentally different things, even if the inherent structures are broadly similar'.