Part studio shows released revision, but assembly can't be updated

S1mon

I'm probably not understanding this correctly, but I have a document which has a few part studios and sub-assemblies, and one main assembly. The main assembly has some hardware which is not in a release state, and I'm not ready to release those parts, but I want everything else to go to our initial release revision (X01). I'm able to get some parts and subassemblies to be shown at a revision, but there are a few that I can't get to show at a revision in the main assembly.

The following parts are in the master part studio for the document. They've all been released according to this .



When I'm in the main assembly, I can't get any of these parts to show at their released revision. I have other parts and assemblies which I sent through the same release process, and I was able to get them to show at the correct revision with the part numbers.

Here's the instance list for the main assembly in the document, with the problem parts highlighted:


What am I doing wrong? Is this a bug?

S1mon

Ok. Thanks to Onshape Support, I have the beginnings of an understanding of the issue. I have configurations driving a bunch of these parts, and now I need to figure out how to manage them consistently. One main part studio config variable which is really only driving a change in a single part, needs to be selected at the assembly level to match the parts which were released so I can use released revisions where I want.

romeograham

That's what I was going to say too: look at the Configurations of the problem parts. I've had similar issues with configurations being hard to find / diagnose as a source of Release Management issues.

adrian_vlzkz

We've put in an IR to have an option to "Merge" configurations of part into a single "releaseble" part number. We have scenarios where we show a single part in different states (i.e spring compression stages), and don't need/want to manage them as separate Part Numbers

S1mon

In this case, in retrospect I just didn't really think about how part numbers and revisions are only connected to particular configurations. Once that became clear, other stuff has fallen into place. It does make be think a lot about how I was to use configuration variables and derived parts moving forward. See this discussion.

I think in the case of a spring, or one of my project's parts, a tire, there's often an "as manufactured" state which is likely what would be inspected. Then there might be a typical "as installed" state, but there might be an infinite number of states for something that flexes. I feel like all those things are still the same part number, but perhaps there needs to be one main or typical or as manufactured state which is what you get as a default choice for a drawing or when you first insert it into a new assembly.

When you think about it, assemblies oddly can show all kinds of motion and still be the same part number. It would be nice if configuration variables could be marked as something that doesn't change the part number. That could be the start of having flexible parts which are represented accurately. Assuming we get to the place where a config variable could be driven by an assembly measurement, Onshape might be able to generate parts which change shape.

romeograham

We have parts that go through some transformations (we make the part, then cut it to a different shape). Then, that part is "bent" into yet another state for visualization / drawings / rendering.

We've adopted few prefixes to help identify the "work in process" states of the part. In some cases, we'll use it to connect the part numbers of different states together. These are all driven by configurations - and we use the "Configured Custom Properties" to assign unique Custom Properties to each configured part.

P1234 (make the part with bits that have to be cut off)
WIP1235 (first transformation on the way to the second transformation)
P1235 (second transformation)
V1235 (visualization state)

If we're careful and assign the part numbers all at the same time, the numbers are sequential. There's some value in WIP* and P* sharing a numerical component (so we can remember what the number is!).

However, it's important to remember: Onshape doesn't care what is in the Part Number custom property - as long as it's unique Onshape can use it to track Releases.  The convenience and "human-readable-ness" of similar part numbers is just so that I (a human) can remember the connections between the part numbers, and the transformations of the actual part that are represented in the configured parts. We keep track of each configuration (releases, drawings, etc) as completely independent parts. 

In fact - Onshape doesn't even keep track of the connection between a Part Number custom property and a PartID. You can release a part (with a part number) and then manually assign that part number to a different part (from a different document or whatever) and Onshape will up-rev when you release that new part. Onshape will (depending on conditions) remind you that you released that part number from a different document previously, but will let you go ahead and assign the part number to a new part. This can be handy to clean up poorly-organized in-progress work, but also allows you to mess things up if you're not careful.