Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- 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.
Release Management, Making changes after initial releases
brucebartlett
Member, OS Professional, Mentor, User Group Leader Posts: 2,141 PRO
I am attempting to use release management for another project. I've gone through and thoroughly released everything using multiple releases, with all the drawings and assemblies linked to the released versions of the parts/sub assys, this was no small task but hopefully, the work will pay off.
I am now going through an update to the design, after the first release and finding it hard to work on the main node with everything linked to versions, so, have branched and started relinking parts/sub assy through multiple levels back to the working node on the branch (i.e undoing the initial releases links on assy's and drawings, where changes required). I am wondering if anyone else has any tips here to speed up the process and also how I am going to get parts released from the branch and back to the main and then what to do next time I have to make changes. I am thinking I'll be able to release the parts on the branch then update the parts in the drawings and assys to the new rev but if another change happens do I have to do all this again?
Keen to hear how others are handling changes with multiple level assemblies and released parts.
I am now going through an update to the design, after the first release and finding it hard to work on the main node with everything linked to versions, so, have branched and started relinking parts/sub assy through multiple levels back to the working node on the branch (i.e undoing the initial releases links on assy's and drawings, where changes required). I am wondering if anyone else has any tips here to speed up the process and also how I am going to get parts released from the branch and back to the main and then what to do next time I have to make changes. I am thinking I'll be able to release the parts on the branch then update the parts in the drawings and assys to the new rev but if another change happens do I have to do all this again?
Keen to hear how others are handling changes with multiple level assemblies and released parts.
Tagged:
0
Comments
Option 1: Release drawings at the same time as the assembly/part so the snapshot in time occurs in the same release. If you released a part and drawing at rev A then main essentially represents rev B as they are in work in the latest version.
Option 2: What you have done, but it requires a lot of manual work to jump around make sure you have updated all the affected assemblies and drawings with the newest revision.
The first option breaks down when you want to release another revision of an assembly level. If the parts are not inserted at their released state (or updated to the released version) it will automatically treat them as a rev change even though no change has been made. We do a bit of a hybrid approach. Drawings are always released at the same time as the part or assembly that it is referencing. Therefore drawings in main are always in-work and represent the referenced part/assembly in the main version. The assemblies we update to the released parts and have to manually change to the current version to release another revision if a part or two change.
(It gets confusing to read version and revision over and over, sorry!)
It sounds like you have a drawing of an assembly that is released and then you release a new revision of a part. In that event, you would update the assembly to point to the new Revision (on any branch or Document) and then re-release the drawing (will automatically revision the assembly).
We are keen to understand how users want to use Onshape - and zero in on any areas where the workflow is potentially less than optimal.
To try and clarify my post, I am finding it very time consuming switching out links so assemblies and drawings are working with released parts and then switching back to make changes. It becomes really hard work when your assemblies are multiple levels deep. I am thinking there maybe be ways of dealing with this by working on, and releasing from a branch but my workflows are not clear yet.
Twitter: @onshapetricks & @babart1977
Yes, the fiddly today is the rigor of swapping out a workspace part for a revisioned part (RMB/Change-to-version). We are exploring other workflows (eg - 'automatically swap to Rev A when available'). We also with the June 18th release (for a short while) had the ability to automatically update all references (it will be back when we fix an 'inefficiency') - that will also help. What you shouldn't have to mess with is any action after revisions have been referenced. You are either releasing the assembly with the current revisions, or updating one or more revisions and re-releasing (either directly or through the drawing). If you are doing anything more complex than that, we should talk about it!
I've tended to follow @Stefan_DMS method of creating a separate document the has the links to all of my released parts/assemblies. This way, when I'm in the working document, I basically assume everything is a "work in progress" and just update the links the separate "released" document after approving a release.
Twitter: @onshapetricks & @babart1977
Here are the steps as I imagine them.
- For a second iteration - modify/revision the input parts.
- Update the assembly to the latest revisions
- Update the context
- Release revB of the guard
- Release revB of the assembly.
Sounds horrible in words - so I built one. IT APPEARS TO WORK VERY WELL!!!Ok, I am waiting expectantly for Bruce's verdict.
Here is the document - https://cad.onshape.com/documents/7373c20b83354ba0ac36aa23/w/c61e25c42ccd487b416e6963/e/76e0d94a33038ebb297173c8
Now that I read this, yes it's not obvious - happy to set up a GoToMeeting to walk through this and I am totally open to having missed something. As always, we want to learn how to make this better.
@lougallo - are you in?
A typical assembly for me has 4 subassemblies and each sub assembly has at least 1 sub assembly and some parts, and each of those have at least 5 - 20 parts.
I have drawings for all parts (NO Assembly drawings are part of my releases for now), which totals about 40 drawings. Particularly the "First" release of 40 drawings / parts is really slow...but updating a subset (or even all of them) after a change is really a bummer.
This is where Bruce's workflow (and mine, which is basically the same) becomes a horrible time wasting operation. If I was working at a consultancy with hourly billing, this would be an issue (now I'm just busy and it feels like I'm wasting time).
If I need to change, say 8 parts - because there are several geometric relationships...or my fabricator has a great suggestion that affects how I modeled several parts - the work can take hours and hours...just to manage the document release part.
(I won't even start on managing the Revision tables post-release - there's an Improvement Request for that).
I try to have Workspace drawings referencing Revisions of parts and assemblies. That way I can add a note or callout to a drawing, and don't have to worry about releasing a Revision of a part or assembly that didn't change when I Release the updated drawing.
I have started to release in batches:
- Parts only...(then in Assemblies: change all referenced parts to Revisions).
- Assemblies release
- Then release drawings
This means that for any change in a Part, I have to do 3 Releases that clutter up the timeline and make post-review very confusing. Not to mention finding the right Release to export the STEP files from!However, if I have a Part Drawing that also references the Subassembly that the part is in (sometimes I do this to ensure that everyone understands the context of the part)...I then have to reference the Workspace version of the assembly in the drawing before releasing the drawing.
Even trying to explain my workflow, I find that there's not a reliable or consistent way that I can work (let alone explain).
There are many IRs that address various aspects of this (from finding Released parts more easily to automatically updating revision tables, to updating all references at once, to exporting more than one part / drawing at a time), and hopefully they will be pulled together into a super-coherent Release Management workflow.
I'd be happy to talk live with someone about my workflow, and find out where:
- my workflow is not optimal for Onshape's intent
- Onshape needs to support my workflow better
@brucebartlett for continuing to ask questions about Release Management, and for sharing your challenges.@philip_thomas your workflow makes sense (although I don't quite understand the need to make a new part with same part number) but really breaks down when you have 40 parts, and several levels of subassemblies AND drawings to deal with. This is a place where (Oh God I Can't Believe I'm Saying This Out Loud) whatever I did with SolidWorks seems a little better.
I tend to use a "master-model" approach (where I have a single, skeleton / layout Part Studio). I then Derive that into several part studios. Each Part Studio becomes a "master model" for each Sub Assembly. Then my top-level assembly brings them all together.
I have done it this way to keep the number of features in each part studio below 200. Above 150 features, I find that my Part Studios really really slow down.
All that to say, that I tend to keep the contextual constraints internal to each Part Studio, other than Derived parts / planes / sketches etc.
[EDIT] @philip_thomas I just realized that I do use a couple of in-context features, but not many.
The beauty of Onshape in my eyes falls in the automatic linking, updating, and simultaneous part design in a single studio. The real issue is then capturing snapshots of that puzzle and putting all the different pieces together. It is very easy to see if the version created is a released version of everything in that document, however that is very rarely the case. Therefore we have to "update the version" to a previous release which fixes it in time. Essentially assembling puzzle pieces (parts and assemblies) from all different version/releases of the document. Now changes no longer propagate through and it is up to the designer to track them all down and update again manually. In my opinion this is where the work flow breaks down, I understand the why, but a methodology or tool provided by Onshape to ease this process would help a ton.
I have recently started using release management workflow in Onshape, hence I am not entirely sure if I am doing it right. But after looking at others' issues, I will share my problems on editing files after initial release.
Currently our company is a young startup and most of projects are related to R&D and are prototypes, so they require extensive modifications based on the test results of prototypes after initial releases. Most of the parts are purchased from outside suppliers and so I categorise them as standard parts. And, these parts are seperated into different documents (not release managed) and referenced by versioning them (as their design is dependent on supplier). So, in the end, during release management, they don't show up and which is very good and works as I wanted to.
We make each project in one document. Lets say, I designed a machine containing top assembly A that has sub-assemblies SA1, SA2, SA3, parts P9, P10, P11 and respective drawings in the same document. I will explain the links as follows:
SA1 is linked to assembly drawing D12 and has parts P1 (linked to Drawing D1), P2 (drawing D2) and P3 (drawing D3).
SA2 is linked to assembly drawing D13 and has parts P4 (D4) and P5 (D5).
SA3 is linked to assembly drawing D14 and has parts P6 (D6), P7 (D7) and P8 (D8)
Parts P9, P10, P11 are linked to drawing D9, D10, D11 respectively.
Top assembly A is linked drawing D0
So, initially I release the document with all drawings, parts, sub-assemblies and top assembly together for initial release (R1). After certain time, when I make modfications to the design and prepare for next release, things start getting confused with release numbers.
SCENARIO 1 : P9 is modified but nothing else is changed. So, I release drawing D9 and Part P9 to new release R2. Everything works good and all other parts and assemblies are in revision R1.
SCENARIO 2: P9 and P10 are modified. Due to this, some extra fasteners (or removal) are required and my top assembly A is modified. So, I start release management with A, D0, P9, P10, D9, D10 to new release R2. Suddenly all other parts like P11 and other sub-assemblies (and parts included in it) are bumped into revision R2 because top-assembly drawing D0 and A are part of this release. However, NOTHING HAS BEEN CHNAGED IN P11, SA1, SA2 and SA3. So, these parts gets new revisions without having actually any revision.
SCENARIO 3: No part or sub-assemblies have been modified. But there are changes in top assembly drawing D0. I prepare D0 and A for new release R2, and all the rest gets bumped to new revision R2, without having any revision on them.
So, in my case, only SCENARIO-1 works well for new revisions after intial release. SCENARIO-2 and SCENARIO-3 are same when modification happens on sub-assemblies (without modifications on respective linked parts) and released.
So, I assumed in the design release process, when something is changed and new revision has to be created, everything has to be included even though some of the parts or sub-assemblies don't have any change. But after 5 or 6 new releases, I have lost track of number of modifications on each different entity as all the parts have undergone same number of design revisions according to revision numbers.
I have seen others splitting into different documents to avoid this and also having problems as mentioned in this post. But even though most of our projects have 70-80 different parts in a single machine, there will be only 20-25 parts designed by us and rest are treated as standard parts. So, I make single document for one machine or project.
So, I generally make an excel sheet to follow up on actual revision numbers of each project.
If Onshape provides an option during release management to remove certain sub-assemblies or parts when main assembly A is included in release management, doesn't it solve all the issue?
Any experienced engineer(s) is(are) welcome to point any mistakes I am doing in part data management, that causes the problems I am facing. As I can sense, in future, my method of onshape release management will make me spend plenty of time looking for different revisions of each part with increasing number of projects.
Thanks.
My biggest concern is that the current workflow/environment is hard to explain even with the simplest of scenarios, this will get very complicated with every level of assembly or number of components being released.
CAD Engineering Manager
Twitter: @onshapetricks & @babart1977
RM provides a mechanism to document milestone changes in a design. These changes are specific to a part, assembly or drawing and NOT to the Document as a whole. These milestones are subject to the rigor of a review process (approvers) and proposed design changes can either be approved or rejected. An approved change records in an auditable log the names/dates of the approvers as required by any number of governing bodies or certifications (eg ISO9000,FDA,FAA). With a record of fit/form/function changes, it becomes possible to use (for instance) stock-on-hand for some designs (until exhausted), or a record of interchangeability (Rev A & B are interchangeable but not Rev C) and a way to demark what should be manufactured/assembled (vs a version that potentially represents ongoing work that has not been released yet).
As i read this (awsome) thread, i am wondering if people think (incorrectly) that this is an all or nothing proposition. It's perfectly acceptable for instance to use versioning until a part (for instance) needs to be manufactured - at that point it would (likely) be moved to another Document and released there (along with its drawing) and then shared with a supplier (or the machine shop). After releasing this part, its back to versions until a change is made to the previously released part. Oh and in this scenario, the assembly that the released part is used in (at Rev A),does not need to be released until that assembly needs to be manufactured and at that time, it is likely that all the constituent parts have (or need to be) released.
We are not perfect and want to learn from the people here - tell us how you want it to work. In the meantime, asking specific questions is a good way to understand how or why something is or its intended use
Just make it clear, I do love working with the black triangled released parts. This black triangle gives instance understanding of the part state. Onshape is on the right track, it just needs some of these very complex workflows to be made easier and far less time-consuming.
Twitter: @onshapetricks & @babart1977
1) We need a way to know which of the parts in a tree have revisions available (regardless of whether or not they are referenced by Revision).
2) We need a way to automatically or enmasse swap workspace references for revisions.
@philip_thomas I think you're right, why not keep the geometry and drawings in their own document? It's obvious now. Machining has to have the geometry these days to make your parts and having them in the same document only makes sense. Why have assy, parts & drawings in a document? Having all this in one container seems like a good idea because you can send one document to the machinist.
Also, most important, I don't have to fight the system. It's a better way to build a manufacturable container just keeping everything together in one document.
Thanks,