Assemblies with revision controlled parts vs live workspace references

S1mon

I'm trying to figure out how to balance the need to have parts and assemblies revision managed vs making changes which are updated in a top down fashion.

Let's say you are working on a subsystem which is all (or mostly) driven by a single part studio. Assuming you have a part studio in the same document as the related assembly, how do you manage controlling the revisions vs seeing all the changes live?

Does it make sense to have a production assembly where all the parts are set to particular revisions, and a clone of the assembly which has all the parts as non-versioned workspace copies?

I like the idea that I can make major top-down driven changes when I need to, but I can avoid creating new revisions of parts that aren't actually changing even though the part studio which created them has had a lot of updates.

To a certain extent, the part studio is the live workspace of the assembly, but only for assemblies and part studios where the assembly largely has all the parts in the same position as the part studio.

What strategies does your company/enterprise use for this kind of thing? 

I kind of wish there was a quick way to toggle an assembly to show a revision managed state or a live workspace state.

billyzelsnack

I like to use versions as super lightweight tags and my workspaces tend to have a lot of versions. Other people I work with barely version their work. I think we kinda annoy each other with our version habits. Pinning is a nice compromise, but it's a mess really.

I personally would like an option to disable "live" editing between workspace tabs as well as having a warning in the version dialog that my rollback bar is not at the bottom.

michael_zeagler

Is it an option to treat the assembly as always live and rev the parts within a release of the assembly? 

I realize people have different practices. I've usually been held to the practice that if a new rev can be substituted, you don't rev the assembly. I'd think in that case you'd need to go through the hassle of manually replacing the references, which is not great.

eric_pesty

We basically don't use the "released" parts in the assembly to avoid the overhead associated with that...
In the scenario you are describing, if you go to the version where the part release happened and look at the assembly there, it contains the released parts for that rev already!

I understand this isn't necessarily workable for everyone though...

We have also created a rev-controlled drawing of an assembly that is set to "not revision controlled" as a slightly more formal way of capturing this: go to the released assembly drawing version and switch to the assembly from there!

S1mon

@eric_pesty
If all the part releases happened at a single version, then that makes sense. The issue is that while a bunch of parts may get released at once, it's often the case that a subset needs to be updated.

Let's say the assembly has "Part A", "Part B" and "Part C", all driven by a single part studio. I release all the parts together at Rev01. So in that case, I can easily look at the version of the assembly where Rev01 was released and see the correct revs of the parts, even though I won't see the triangles in the assembly.

Now let's say I make a change to the part studio in order to fix an issue with "Part C". I release "Part C" at Rev02, but if I look at a live assembly I'm not 100% sure that the changes I made to the part studio aren't changing "Part A" and "Part B". This is where I feel like I want the assembly to have selected Revisions of parts, but it becomes more of a challenge to manage that, and I can't see a live workspace assembly unless the part studio is good enough, or I create a duplicate of the main assembly, but set the parts to be workspace versions.

This is where I get a little lost.

eric_pesty

@S1mon
It does get a bit murky in that case...

You might be able to leverage branches to help with this: the "main/release" branch where the assembly references the released parts and the have a "Dev" branch where you do the part studio edits and the assembly is "live".

When you are ready to make a release, merge the relevant part studios into your main, do the release, and update the assembly to point to the latest release of parts.

S1mon

michael_zeagler said:

Is it an option to treat the assembly as always live and rev the parts within a release of the assembly? 

I realize people have different practices. I've usually been held to the practice that if a new rev can be substituted, you don't rev the assembly. I'd think in that case you'd need to go through the hassle of manually replacing the references, which is not great.

I agree, an assembly should only get rev'd if parts are added or removed or replaced, or perhaps the assembly process/order changes. If I'm creating an assembly drawing with an exploded view, and that explosion still makes visual sense, even with the revised parts, then I wouldn't rev the assembly drawing. I know a lot of companies like to put fairly complete BOMs on assembly drawings, but at a past company we had things set up so the exploded views just have an item number (e.g. the balloons are numbered from 1 to the number of unique parts). The assembly drawing can point to a separate BOM document (with a document number, no revision mentioned) which can be independently revised with the item numbers from the assembly drawing, part numbers, part names, materials, etc. That way the BOM can be updated without as many ECOs and drawing updates.

I haven't gotten to the point where I'm trying to do all this in Onshape yet. Our process is still a bit messy and partially managed with other tools.

If the overall form/fit/function of the assembly changes, then of course the assembly would need a new part number and new drawing.

S1mon

eric_pesty said:

@S1mon
It does get a bit murky in that case...

You might be able to leverage branches to help with this: the "main/release" branch where the assembly references the released parts and the have a "Dev" branch where you do the part studio edits and the assembly is "live".

When you are ready to make a release, merge the relevant part studios into your main, do the release, and update the assembly to point to the latest release of parts.

This is a really interesting approach.

I guess with the dev branch approach, you would always branch from Main right when you want to make updates. That way the assembly in Main would be the source of truth for what parts are in there. In the dev branch you'd "unlock" (swap the revisions for workspace versions) only the parts you wanted to update, and make any changes in the part studio and be able to see them live. Then as you say, you'd merge the part studio updates, rev the part(s) in the update, and swap the revs in the assembly in the main branch.

I'm not sure if you'd want to make assembly changes in the dev branch, but if the merging works correctly, I suppose that would be ok too.

adrian_vlzkz

We are developing a system where we define Design State with 3 levels, based on this article from @philip_thomas

Ideation State:

• ~90% of Components and Assemblies are within the same document
• Assemblies Reference
• No Drawings are typically generated
• Versions only (No Revisions)

Definition State (Release Prep):

• Components get Part Numbers and Metadata
• Drawings get generated
• Components and Sub-assemblies are moved to independent Documents
• References switched to Versions

Controlled Stage:

• All components are contained in separate documents
• All components have Released Drawings
• Changes thru Revision only

So it's not necessarily a matter of "How" we manage a Document but more of "When". One of the main reasons opted to breakout into multiple Documents, is because Versioning and Branching are at the Document level, not the "Tab" level, so once you entered a state where more people are involved, hosting an entire assembly(with components and drawings) in a single Doc, it gets overwhelming really quick.

eric_pesty

It does add some overhead to kill of and create a new branch everytime but it would make things "clearer"...

In theory though you should be able to keep both alive and use merges. I would see the workflow going this way:
- Do your design work in DEV on both the assembly and the part studio.
- When ready to release, merge into "main".
- Do the inevitable last minute edits or changes in main as required and perform the release
- I guess if you merge back into DEV after changing the "main" assembly to the newly released parts you would have to switch them back to "live" but maybe that's ok as you would do it "as needed"... Or you you could merge to Dev after the part release but before updating the assembly to the new revised parts...

Either way there should be no reason to make any changes to "main" (other than by mistake...) between releases.

One of the biggest challenges is being aware of which branch you are in before you start working as I have done work in the "wrong" branch more than once! I wish it was a lot clearer what branch I am in than the washed out text next to the document name!

S1mon

@adrian_vlzkz

At my company, we have three defined workflows in Onshape: development, pre-production, and production. Each has its own revision scheme and requirements for approvals. That's based on practices and experience at previous companies, including being the Solidworks PDM Pro admin. I strongly believe that no files/parts should leave engineering to go to vendors without a revision.

I struggle a lot with with when things should be split out into separate documents. There's something nice about a document being the container for a subsystem, but as you say, the versioning and branching can become convoluted and confusing. When you get to that "Controlled Stage" point in your development process, are you still driving design using a top-down approach, or do you only make changes in local part studios per part?

eric_pesty

We are just getting to "production release" in our first major project completed with Onshape so not exactly sure what we will do going forward!

We control BOM and product structures through a (heavily manual...) process outside of CAD with the output being a "manufacturing package" that gets sent our CM.

We are currently using "large" documents that each cover basically the entire "product".
Our current plan is to any work in a DEV branch starting from a "post CO" version of the document. I would expect any change to be "sandboxed" (i.e. more likely "bottom up" unless we do want to update related parts). We should be able to control what gets merged/updated in main (i.e. only merge the part studios that were intentionally modified and check everything for fit before releasing).

That said it might also make sense to "part out" some stuff but we haven't fully figured out what our approach is going to be yet so I'm very much following this discussion and happy to hear about what others are doing!

adrian_vlzkz

S1mon said:

@adrian_vlzkz

 When you get to that "Controlled Stage" point in your development process, are you still driving design using a top-down approach, or do you only make changes in local part studios per part?

We do both, our "Product" is primarily Top-Down, and Equipment design is typically bottom up. The nice thing about Onshape Data Management is that moving items around doesn't break references, so we've come to trust that robustness.

Another benefit of having more documents for our Product Structure is that Sharing also happens at the document level, so when Products/Projects get to the stage where Quality, Supply Chain and Production need access to CAD Data, they don't have to navigate an entire Structure, but just the specific item they need (Part or Sub-Assembly)

We also have 2 rev schemes, but unfortunately Onshape only supports a single Rev Scheme, even if you have more workflows.

S1mon

We also have 2 rev schemes, but unfortunately Onshape only supports a single Rev Scheme, even if you have more workflows.

I'm not sure what you mean. I did have to get help customizing our setup, but we have three workflows with three different revision schemes. Do you mean that you can't have some parts with one rev scheme in a release with parts with a different rev scheme?

What we don't have is the ability to enforce that you can't go from production to development or things like that.

romeograham

@adrian_vlzkz
You mentioned that Onshape only suppports a single Rev scheme. Do you know about the custom list you can use for revisions?
At our company we have a very simple Rev Scheme, but use Letters (A, B, C) for parts, assemblies and Files, and use numbers (1, 2, 3) for Drawings. We also share part numbers for parts and drawings (except for the leading letter: P1234 is in Drawing D1234). The different rev scheme makes it easier to Rev up drawings at a different rate than parts. (for instance, you can work through many revs on a part while you work through design issues, but the drawing only up-revs from 2 -3 .  Likewise, drawings can get tons of information updated without up-revving parts).

Basic setup
You make a csv file with your different schemes, one after the other. The letter part is "scheme 1" and the numbers part is "scheme 2":
A, B, C...AX, AY, AZ, 1, 2, 3 ... 99

Then, the first time you Release something Onshape will always start at the beginning (A). If it's a drawing, you need to just set the Revision manually to "1". Thereafter, Onshape just checks the list for the current Revision and goes to the next in the list when you do a new Release. So, if your drawing is at Rev 8, Onshape will find "8" in the list, and use the next item (9) for the Revision.

I think you could add as many "schemes" as you like to that csv file; though you'd have to manually get Onshape started in the right place when you need to use a different Scheme for a Part, or phase of the project or whatever.

Look at your settings here: https://jps.onshape.com/c/manage/release-management



also- take advantage of the "Unreleased revision suffix" - it helps remind you that the drawing you're working on is unrealesed!.
I think this is totally separate from the options for different "workflows" in Release Management.

Assembly Structure

@S1mon
We use a combination of Released parts in Assemblies & workspaces with only workspace parts.
The weird part about this is that in a WorkSpace you can have an Assembly (workspace only!) that is populated with Released parts. But you can only see the Revision of the assembly in a past release version. 

We've started to play with a Top Level Assembly in another document, populated only with Released SubAssys and Parts - then that Top Level assembly gets released as needed.

We also make sure that anything "shared" (emailed out, 3D printed, shared for RFQ, production etc) has been released. I like the strategy  that Philip Thomas laid out - but we tend to work with custom properties / part numbers etc a little earlier. I really like the transition from 1 document - many as the project moves along. 

Branching
We have found that it's very (very) confusing to use Branches for any long-term work. We use them for exploratory / developmental work or to have different people explore different ideas. However, we try our best to release ONLY from Main branch. We use Release Management extensively (along with the automatic obsoletion feature) to help maintain single source of truth. As we develop technologies or physical systems, the actual equipment can end up having many "generations" of parts - and making sure that our Onshape assemblies are populated with Released parts helps us keep track.

shawn_crocker

For us, we sort of have two types of designs.  One that is a standard product that has been configured so that new sizes and such can be selected from a drawing and then released by releasing the drawing.  In this case, I spend a bit of extra time setting it up where once I am done, before releasing the first config, I branch everything out.  First, each part is derived into its own part studio and its config control are setup to drive the derive feature allowing its configs to be specific to that part only.  Then, I branch the master studio out, and delete everything except itself and create a version.  Then I branch out each part part studio in the same way so that everything is contained in its own branch and the derives are referencing the version in the master part studio branch.  By the end, every component is in its own branch and any references are being made to an item that exists in its own segregated branch.  This basically adds the advantage of moving things into there own document but retains the advantage of them not actually being in there own document.  I only use this for standard type highly configure products that need to be usable similarly to a solid works drive works setup.
  For a one off completely custom design, everything is referencing the workspace and initially once finally approved for MFG, everything is release all in the same version.  Then if I need to make changes, I first update all assembly items to reference revisions.  Then I do my changes.  Then I go through the assemblies and update what I need to to reference the workspace.  If the design is particularly large, I may branch what is going to be changed and then in higher level assemblies reference the items from the new branches version.  Even in this case, I usually derive each part studio part into its own part studio and use that part in an assembly for releasing.  I find it much cleaner in the end and easier to see what is actually changing.  Especially when the part studio starts to have 10 plus items.

shawn_crocker

adrian_vlzkz said:

One of the main reasons opted to breakout into multiple Documents, is because Versioning and Branching are at the Document level, not the "Tab" level, so once you entered a state where more people are involved, hosting an entire assembly(with components and drawings) in a single Doc, it gets overwhelming really quick.

I used to follow the approach of moving all components into separate docs at the final stages.  I does make it more clear when revision time comes around.  I do find you get pretty much the same functionality though, by keeping it in one doc but using branches to simulate separate docs.  It is sometimes hard to find a branch when there are lots simply because the UI of the version tree is quite limiting in usefulness.  I am hoping onshape could just address this and realize the version tree could be a lot more useful in many ways that they may not of actually intended if they could just let people see better what is there.  Another great thing about putting single items in there own branch is you still get the same benefit with respect to the blue version update icon that displays beside an item in the assembly tree.  When an item is branched into it own workspace and everything else in the branch is deleted, referencing the item from the branch will only show an update icon if a new version is created through that branch.  For instance, if I keep everything in a straight line and I decide to reference a part version further down the tree, the assembly will always be fooling me to believe that new versions of that part might actually exist.  And I constantly feel the need to check just to be sure I'm not missing something or switch to a revision if possible which is often not the case if the item in configured and needs to remain dynamic.  However, once an item is branched and everything except itself is wiped out of the branch, a version is created and referenced in an assembly, the assembly will not show an update indicator when new versions are create through other branches.  The update icon will only appear if a new version is create through that items branch.  Which brings in the advantage of having the items in there own docs but beneficially not actually having them in there own docs.