Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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

brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,137 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.
Engineer ı Product Designer ı Onshape Consulting Partner
Twitter: @onshapetricks  & @babart1977   

Comments

  • michael_bromleymichael_bromley Member Posts: 110 PRO
    This is the issue that I struggle with.  Unfortunately I have yet to find a good workflow that is both easy and retains good visibility on the release state.

    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!)
  • philip_thomasphilip_thomas Member, Moderator, Onshape Employees, Developers Posts: 1,381
    @brucebartlett - I am struggling a little to figure out what you're struggling with (some people here say it's just me ;)).
    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.
    Philip Thomas - Onshape
  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,137 PRO
    @brucebartlett - I am struggling a little to figure out what you're struggling with (some people here say it's just me ;)).
    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.
    Hi Phil, thanks for jumping in here, release management gets quite complex very quickly and IMHO one of the less fun things with CAD Design on all systems. I am keen to learn better workflows and also see Onshape improvements here so I can focus more effort on design but also have confidence my data is strictly managed. @michael_bromley outlines some of the problems faced and it sounds like we are using similar workflows. 

    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. 
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • Stefan_DMSStefan_DMS Member Posts: 48 PRO
    One of the tricks we use to keep the links under control is to keep the revision controlled assemblies (ie the BOM assembly) in their own document outside the design document. This way it can only reference a versioned or released part. We separate the versioning of the parts and the assemblies into 2 operations. Revisions of assemblies and their BOMs trend to increment a bit more than the part revision numbers though. 
  • philip_thomasphilip_thomas Member, Moderator, Onshape Employees, Developers Posts: 1,381
    @brucebartlett - ah!
    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! :) 
    Philip Thomas - Onshape
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    @brucebartlett - can you clarify why you need to un-link from specific versions when making your design changes?

    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.
  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,137 PRO
    edited July 2019
    An example I am facing at the moment is placing a guard on a machine. I need to design the guard around a fully released assembly, this is easy with an in-context but then using the new guard positioned in the assembly  I need to add the mounting holes on the released parts and this becomes an issue as to create an in-context the parts have to be switched from the released version (in this case, the parts are 3 levels down) to create an in-context and the all the sub assys have to be released for the small change.  Solving this may come back to restructuring the way I am releasing things. @tim_hess427 separate documents for released components may be a solution, I'll have to look into that.  
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • philip_thomasphilip_thomas Member, Moderator, Onshape Employees, Developers Posts: 1,381
    Bruce - I read your guard example and want to make sure we are not missing a simple (intended) workflow.
    Here are the steps as I imagine them.

    • Create an in-context Part Studio with the (released) parts that need the holes.
    • Transform the parts that need the holes in the Part Studio
    • Create the Sheetmetal guard in this In-Context Part Studio
    • Assign the SAME PART NUMBERS to the pieces that are getting the holes
    • Insert the SM part into the assembly
    • From the In-Context Part Studio, create a release candidate that contains the parts-with-hole and the guard
    • Onshape will tell you that parts with those part number have already been released  - go ahead.
    • Release the Assembly

    • 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? :)
    Philip Thomas - Onshape
  • romeograhamromeograham Member Posts: 656 PRO
    edited July 2019
    I have essentially the same problem as Bruce.

    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:
    1. Parts only...(then in Assemblies: change all referenced parts to Revisions).
    2. Assemblies release
    3. 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.
  • philip_thomasphilip_thomas Member, Moderator, Onshape Employees, Developers Posts: 1,381
    This is a great thread that we are following with interest - keep the info and suggestions coming and we will noodle on all of this :)
    Philip Thomas - Onshape
  • philip_thomasphilip_thomas Member, Moderator, Onshape Employees, Developers Posts: 1,381
    @romeograham - would you please confirm whether or not your process does or does not include in-context parts?
    Philip Thomas - Onshape
  • romeograhamromeograham Member Posts: 656 PRO
    edited July 2019
    @philip_thomas
    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.

  • michael_bromleymichael_bromley Member Posts: 110 PRO
    Bruce - I read your guard example and want to make sure we are not missing a simple (intended) workflow.
    Here are the steps as I imagine them.

    • Create an in-context Part Studio with the (released) parts that need the holes.
    • Transform the parts that need the holes in the Part Studio
    • Create the Sheetmetal guard in this In-Context Part Studio
    • Assign the SAME PART NUMBERS to the pieces that are getting the holes
    • Insert the SM part into the assembly
    • From the In-Context Part Studio, create a release candidate that contains the parts-with-hole and the guard
    • Onshape will tell you that parts with those part number have already been released  - go ahead.
    • Release the Assembly
    @philip_thomas I feel like this gets away from the wonderful always "in-work" ideology behind Onshape. You have essentially done an old school save-as copy by transforming the part into a new part studio and reassigning it the same part number. Now when a new designer goes back to look for the model there will be two instances and it will take some digging to figure out why. I can imagine this snowballing very quickly if this is how a majority of the changes took place.

    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.
  • c_harshac_harsha Member Posts: 15 PRO
    Hi,

    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.


  • adrian_vlzkzadrian_vlzkz Member Posts: 258 PRO
    edited July 2019
    Sounds to me like we to have a Release Management Summit of sorts to discuss all this. I agree with most here, it is very unclear to me of what the Intent is of Release Management. I'm assuming it was designed with some best practices in mind, I'm yet to find what those are. It feels like it would be the workflow that @brucebartlett describes, but also seems like the most tedious for the user and counter intuitive.

    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.
    Adrian V. | Onshape Ambassador
    CAD Engineering Manager
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    I've played around with different workflows, but one thing I keep coming back to is visibility. Regardless of workflow, it'll always be easier to understand what action to carry out next with better visibility into design status. With design information distributed between documents, branches, versions, revisions (and then duplicated via assembly links and derives) its very hard to look at a project and quickly get an understanding of what's going on, what's happened most recently, and what needs to be done next.

    In terms of visibility, two questions that I want to answer most often when looking at a project or document are:
    1. What (and where) are the most current released versions of my parts?
    2. What's been happening most recently? 
    I think there's room for improvement in both of these. For #1, I'd like to see part numbers displayed for search results on the main page. For #2, I think some improvements to the history tree could include information about what parts are released and at what version, ability to make the history flyout wider and scroll left/right, and a graphic showing where branches merge.
  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,137 PRO
    Bruce - I read your guard example and want to make sure we are not missing a simple (intended) workflow.
    Here are the steps as I imagine them.

    • Create an in-context Part Studio with the (released) parts that need the holes.
    • Transform the parts that need the holes in the Part Studio
    • Create the Sheetmetal guard in this In-Context Part Studio
    • Assign the SAME PART NUMBERS to the pieces that are getting the holes
    • Insert the SM part into the assembly
    • From the In-Context Part Studio, create a release candidate that contains the parts-with-hole and the guard
    • Onshape will tell you that parts with those part number have already been released  - go ahead.
    • Release the Assembly

    • 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!!! :)


    Thanks, Philip, this is much appreciated! Assigning the same part number looks useful, but I have gone down the path of using a branch to make changes on the parts, release on the branch, and update on the main branch and then release again, I am thinking this gives a better solution than a copy from the in-context but this may not be a bad way to go and will keep it in mind for the future. I am right in the middle getting drawings out for production using release management, so do have the time or brain energy or focus to look at this thoroughly at the moment.   
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • philip_thomasphilip_thomas Member, Moderator, Onshape Employees, Developers Posts: 1,381
    @adrian_vlzkz - On the one hand, release management is a vital part of many Engineering company's workflows, but i am also agreeing that some of the intended workflows are not obvious (and we need to work on that). What I can give you is a first-order answer to the question 'what does RM do for me?'. 

    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 :)
    Philip Thomas - Onshape
  • michael_bromleymichael_bromley Member Posts: 110 PRO
    I would agree with @adrian_vlzkz that one of the critical issues is visibility. @philip_thomas, although you mention "These changes are specific to a part, assembly or drawing and NOT to the Document as a whole" that is true of the release package, but when viewing the document version tree it IS a snapshot of the document as a whole.  This is where it gets confusing because there can be many releases along the way in a version tree, but no great view for understanding what was released when at a high level.  This is in contrary to conventional vault style CAD where each part (file) carries its own release history.  I realize that I could right click on each part and view the revision history then dig into the releases.  However, at a high level I do not know of a good way to get visibility of the current state of the document.

  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,137 PRO
    edited July 2019
    @philip_thomas On a part level what you just described works ok but once you start working with assemblies that are released with parts that have been switched to released (best method to stop revs auto rising) they have to be switched back to make the intermediate changes and see results in the assembly, then parts released at the part level, then switched in the assembly and part drawings to release the assembly and part drawings then the same for the assembly drawing, then switched back again for the next wave of changes. 

    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. 
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • shouldNotBePostingshouldNotBePosting Member Posts: 10 PRO
    edited July 2019






  • billy2billy2 Member, OS Professional, Mentor, Developers, User Group Leader Posts: 2,014 PRO
    I've always had the drawings in a separate document but left the geometry in the original creation document. When moving a document, it moves all the dependences and I fight it putting the geometry back.

    @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,
  • david_rubli136david_rubli136 Member Posts: 16 PRO
    @michael_bromley - AGREED!!!!
    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.
    Where do we stand with this? I see some stuff is done with signd in the part tree of the assemblies, but other stuff i'm still missing.
Sign In or Register to comment.