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.

Options

Structuring

AECAEC Member Posts: 21 ✭✭
Hello,
I have a document/drawing challenge that I can't really wrap my head around, or maybe I did but I need some guidance or wisdom.

To simplify the scenario; I have a document with a part in it, this part has 4 configurations and I then have 4 drawings, each referring to a separate configuration, all with individual revisioning from the common part, but all referring to the part revision as well.
What I can't figure out is if it's possible to keep this common part as reference for the drawings, because changing something in the part and releasing that change through the drawing causes a revision increment in all 4 drawings, whereas increasing the common part revision for the other 3 drawings will cause confusion as there's no change in the geometry of this when the another drawing is released.

I think the solution is to make 4 separate documents that pulls in the said common part in the 4 different configurations in each their own part through a derive feature. These individual part files, in each their separate document will then have their own release cycles with individual part revisions. I'd have to recreate the drawings and put those inside those documents as well.
In this case any change in the common part would have to be manually updated in the separate documents of course, but I don't really see that being a issue.

Question is... am I on the right path, am I complicating things unnecessarily?
My goal is to have each part configuration living their own life revision-wise, with their own drawing also individually revised, but with the common part defining the geometry.

Any input is highly appreciated, I'm sure I'm not the first with these kind of thoughts and dilemmas.

Thank you in advance :)

Best Answer

  • Options
    eric_pestyeric_pesty Member Posts: 1,514 PRO
    Answer ✓
    You shouldn't need to create "derived" parts to achieve what you are trying to do. Also it doesn't matter if things are in the same document or not as released go "across" documents anyway...

    If each drawing only has one configuration of the part on it, then releasing one of the drawings should only release the one configuration of the part and should not cause the other drawings to uprev...
    Now if you are showing a "common" configuration of the part on every drawing it explains the behavior you are seeing. The fix is to change each drawing to reference a specific version/revision of the base part instead of the "workspace". In that case you will have to manually update the reference when creating a new revision of the base part.

    That said, deriving the base part into separate part studios might actually make sense depending on the relation between the "base part" and the configuration. You could then make the "master" not revision managed and that would make take it out of the revision cycle. 

Answers

  • Options
    eric_pestyeric_pesty Member Posts: 1,514 PRO
    Answer ✓
    You shouldn't need to create "derived" parts to achieve what you are trying to do. Also it doesn't matter if things are in the same document or not as released go "across" documents anyway...

    If each drawing only has one configuration of the part on it, then releasing one of the drawings should only release the one configuration of the part and should not cause the other drawings to uprev...
    Now if you are showing a "common" configuration of the part on every drawing it explains the behavior you are seeing. The fix is to change each drawing to reference a specific version/revision of the base part instead of the "workspace". In that case you will have to manually update the reference when creating a new revision of the base part.

    That said, deriving the base part into separate part studios might actually make sense depending on the relation between the "base part" and the configuration. You could then make the "master" not revision managed and that would make take it out of the revision cycle. 
  • Options
    shawn_crockershawn_crocker Member, OS Professional Posts: 807 PRO
    As @eric_pesty has mentioned, looks like you are trying to keep everything traveling together in the same versions which is causing all the unnecessary revision bumps.  I used to struggle with this, trying to find the perfect way to not revise things unnecessarily and make it easy for production people to see what they need.  I found it was too much work.  If you are trying to keep things tidy and all together, I would create a publication.  Then you can sort of flatten out the version tree and have lots of drawing all releases in different versions shown nicely all together in one clean list.  I don't use publication too much but I really like them.  They really make the system easier to navigate for viewers who don't have time to master an understanding of the version tree.
  • Options
    AECAEC Member Posts: 21 ✭✭
    You shouldn't need to create "derived" parts to achieve what you are trying to do. Also it doesn't matter if things are in the same document or not as released go "across" documents anyway...

    If each drawing only has one configuration of the part on it, then releasing one of the drawings should only release the one configuration of the part and should not cause the other drawings to uprev...
    Now if you are showing a "common" configuration of the part on every drawing it explains the behavior you are seeing. The fix is to change each drawing to reference a specific version/revision of the base part instead of the "workspace". In that case you will have to manually update the reference when creating a new revision of the base part.

    That said, deriving the base part into separate part studios might actually make sense depending on the relation between the "base part" and the configuration. You could then make the "master" not revision managed and that would make take it out of the revision cycle. 

    Hi Eric,
    Thank you for the response, as the structure is now, the drawings does refer to each their own version of the common part, and each only to one configuration.
    So the optimal process according to your reply is that I keep the above structure with each drawing referring to a specific version and configuration of the common part studio, then if I'm to change something for a specific drawing/configuration, I create a new version in the common part studio and change the reference in the relevant drawing to that version to update it?
    It seems to make sense to me to do it this way, because then each part, with its separate part number, also has separate revisions created with each release.

    As @eric_pesty has mentioned, looks like you are trying to keep everything traveling together in the same versions which is causing all the unnecessary revision bumps.  I used to struggle with this, trying to find the perfect way to not revise things unnecessarily and make it easy for production people to see what they need.  I found it was too much work.  If you are trying to keep things tidy and all together, I would create a publication.  Then you can sort of flatten out the version tree and have lots of drawing all releases in different versions shown nicely all together in one clean list.  I don't use publication too much but I really like them.  They really make the system easier to navigate for viewers who don't have time to master an understanding of the version tree.
    Hi Shawn, also thank you for the response!
    It's rather new to me to work with MCAD in this way, generally I've used an excel sheet or similar to keep things in control in previous jobs, however with the functionality onshape provides, it's so appealing to utilize and I already feel immense control and overview, it forces one to approach the design in a much more structured way than what I'm used to which is fantastic. I know this enthusiasm is probably just a product of me never really working properly with vaults and PLM in bigger organizations, but yeah, I guess I'm just trying to express my gratitude of discovering onshape after being well around the block in this world of software.

    I'll have to look up publications, I've not heard about that before, but if it is anything that can help viewers with a better overview it's definitely a thing worth looking into. I'm the only MCAD engineer in this company and it being small, everyone has their own world to attend which exactly as you say, makes it cumbersome to try to get into yet another "world" to follow along.

  • Options
    shawn_crockershawn_crocker Member, OS Professional Posts: 807 PRO
    I also have more or less no experience using any other cad data control system other then onshape.  Of course, I have seen videos on things like solid Works PDM.  I think the onshape version control system is pretty hard to beat.  Thinking about having to check items out of a vault and have them get copied in my hard drive for editing sounds nightmarish.  When compared to this system, everything just there waiting to be worked on with no real premeditation of an approach needed.  BTW, publications are just another document type available in the create button in your home view.  A publication is sort of like a folder where you can add any item type in and pick which version or revision should be displayed.  If you share a link to the publication, the person opening it just sees everything they need to see as the items are meant to be seen.  No digging through a version tree for the released version of an item.  Or making a bunch a searches for part numbers using the released filter option.
  • Options
    AECAEC Member Posts: 21 ✭✭

    I also have more or less no experience using any other cad data control system other then onshape.  Of course, I have seen videos on things like solid Works PDM.  I think the onshape version control system is pretty hard to beat.  Thinking about having to check items out of a vault and have them get copied in my hard drive for editing sounds nightmarish.  When compared to this system, everything just there waiting to be worked on with no real premeditation of an approach needed.  BTW, publications are just another document type available in the create button in your home view.  A publication is sort of like a folder where you can add any item type in and pick which version or revision should be displayed.  If you share a link to the publication, the person opening it just sees everything they need to see as the items are meant to be seen.  No digging through a version tree for the released version of an item.  Or making a bunch a searches for part numbers using the released filter option.

    I tried out doing a publication and I really like that feature, thanks for mentioning that!
    I'll close this thread now as I think I got my answer, thanks again for pitching in!
Sign In or Register to comment.