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.

Released Configured Part Not Configurable

dt_userdt_user Member Posts: 8 PRO
I describe my issue below, which begs the question: What is the intended workflow for releasing configured parts?

The other day I released a configured part. Now, when I right click on that part in an assembly there is no option to "change configuration".

In this case, am I expected to "replace part" if I wish to change the configuration? This seems like a workaround. The other aspect of this problem, the different configurations all have the same part name, and I use non-significant part numbering built into the release workflow (see below), so I can't tell what's what. My only option to determine which part number is which part would be to view the "configured part properties" inside that part studio. 
 

Answers

  • mlaflecheCADmlaflecheCAD Member, Onshape Employees, Developers Posts: 179
    @david_troy the part name is configurable if that helps. See "name" as the option in the configured part properties
    Regards,
    Mike LaFleche   @mlaflecheCAD
  • dt_userdt_user Member Posts: 8 PRO
    @mlaflecheCAD Sort of. I can work with that, but I'm wondering, why aren't configurations available for released configurations of parts? Thank you for pointing that out though. 
  • romeograhamromeograham Member Posts: 656 PRO
    @david_troy
    Released parts are supposed to represent a single part (or assembly or drawing) - think of something that is physically producible. Once you make a part or print a drawing, you can't change the configuration. It's unlikely that a, say, fabricated sheet metal part can have different states (or configurations), once it's made. Also, in manufacturing, it's important that only one part (with a specific Part Number) can be used in an assembly or other application - if a different part is used, then the Parent assembly is actually different. The only way to track that is for a single Part Number to be associated with a single (released) state of a part. Released parts are meant to be like that - a real, unchangeable, part (or drawing or whatever). Release Management (and revisions) are supposed to be a permanent, traceable record of your design workflow, manufactured parts, or specification drawings. Imagine if you had produced 10,000 parts incorrectly. To figure out why, you go back to see what part number was produced, and see that part number P1234 could have two states (configurations) - and the manufacturer happened to choose the wrong one (that's possible with configurations, but not with Revisions).

    To use configurations of a part in another document, you need to use Versions (for those you can choose configurations).

    To expand on the @mlaflecheCAD note above, you can set any or all of the custom properties for each configuration. If you will need Released revisions of all possible states, then you need to Release each configuration - and you'll have all of them available for your other assemblies. Onshape needs to do a better job showing you the different configurations that have been released from a Part Studio (right now, they can be hard to find), but the absolute immutability of the Released Parts is a really great feature for manufacturers.

    Maybe your workflow should use Versions (so you can switch configurations) as you develop the concepts, then once you have design intent nailed down, you can update the references to Revisions, rather than versions of configurations. You may have noticed that you can't configure Assembly names in Onshape - this means that when you want to release an Assembly that might have different configurations, you actually need to make a separate Assembly for each configuration - which dovetails with the fact that you have to release part configurations too.

    Hope that helps!
    Romeo
  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,137 PRO
    edited May 2020
    I run into similar issues the other day when using configuration to get a mirrored assembly, I wanted to use configurations to make the top-level assembly configurable without having to re-do a heap of mates with multiple suppressed parts, ie configure the configuration but it will not work once released.  I ended up releasing the parts/sub-assemblies then versioned and linking to the versions rather than the latest release so I still had a top-level which are configurable and with all sub assembles released correctly. 
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • konstantin_shiriazdanovkonstantin_shiriazdanov Member Posts: 1,221 ✭✭✭✭✭
    @david_troy
    Released parts are supposed to represent a single part (or assembly or drawing) - think of something that is physically producible. Once you make a part or print a drawing, you can't change the configuration. It's unlikely that a, say, fabricated sheet metal part can have different states (or configurations), once it's made. Also, in manufacturing, it's important that only one part (with a specific Part Number) can be used in an assembly or other application - if a different part is used, then the Parent assembly is actually different. The only way to track that is for a single Part Number to be associated with a single (released) state of a part. Released parts are meant to be like that - a real, unchangeable, part (or drawing or whatever). Release Management (and revisions) are supposed to be a permanent, traceable record of your design workflow, manufactured parts, or specification drawings. Imagine if you had produced 10,000 parts incorrectly. To figure out why, you go back to see what part number was produced, and see that part number P1234 could have two states (configurations) - and the manufacturer happened to choose the wrong one (that's possible with configurations, but not with Revisions).
    Can't fully agree with you, the part is unchangeble when manufactured by its nature beacuse this is the purpose why we made them for our conviniences. But why should digital model to behave the same way, what conviniences it brings? I can't see any. We already release every desired configuration independently, but can't even switch between released configurations. This is not an advantage but a disfunction, which stops us in company from using release management at all.

  • romeograhamromeograham Member Posts: 656 PRO
    @brucebartlett @konstantin_shiriazdanov
    I understand that this has limitations for sure! I was trying to describe how it functions...not trying to say that it's the best it can be!

    I'm certainly getting used to release management, but Iooking forward to the improvements that must be coming, too. As @brucebartlett has often lamented - "Release Day" is getting to be a ton of work, especially with many parts / assemblies / drawings to release, along with the inevitable missed part in an assembly.

    However, I think there's some value in an immutable Released Object with a conceptual parallel in the physical world - a part or whatever. 
    A bread recipe can exist with all it's potential to be whole wheat, rye, or raisin bread (sorry, but with the trendy-ness of bread these days, it's the example that comes to mind) and the recipe with variations is the Version with configurations. Once you bake it (the Release!) you can't change that loaf between whole wheat or rye. It's baked. 

    It's a simplistic example, but it makes sense to me that this parallel exists.

    Clearly there are ways to work with released items in our Onshape documents that are more flexible - as you both called out above. I look forward to improvements from Onshape in this area.
  • dt_userdt_user Member Posts: 8 PRO
    Thanks for the feedback everyone. Even after reading the comments I do feel like I should be able to switch between configurations as a convenience, regardless of whether or not they have been released. This shouldn't clash with the release management workflow, because when releasing an assembly containing an unreleased part [configuration], the release of that part would be triggered.
  • brucebartlettbrucebartlett Member, OS Professional, Mentor, User Group Leader Posts: 2,137 PRO
    Thanks for the feedback everyone. Even after reading the comments I do feel like I should be able to switch between configurations as a convenience, regardless of whether or not they have been released. This shouldn't clash with the release management workflow, because when releasing an assembly containing an unreleased part [configuration], the release of that part would be triggered.
    I think at least we should be able to switch between released configurations 
    Engineer ı Product Designer ı Onshape Consulting Partner
    Twitter: @onshapetricks  & @babart1977   
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    I forgot that I couldn't switch between released configurations of parts in my configured assembly until today. I'm sad that this isn't a thing yet. 

    I have a configured product. I've released X number of configurations for my individual parts. Now, I want to make sure I'm referencing the latest released geometry in my assembly for each configuration but I can't...
  • shawn_crockershawn_crocker Member, OS Professional Posts: 798 PRO
    I feel for all these comments on a personal level as I struggled with all these issues when first trying to grasp release management. I struggle no more because everything about how release management behaves is perfect, once you get it. Here is how I work.

    - I create a product and everything I have to model on the spot (don't have already in my huge library of configurable company standards) lives inside the same document.

    - when I am done and ready to submit a release proposal, I look over all the tabs and decide if some of them should be moved to there own document and move them. I usually always move configured components.

    - creating the release, naturally, creates releases for everything downstream, even things I configured and are still in the document and for things configured that live in there own document. The release gets approved.

    - At this point that's it. You do not need to mess with anything. Just start creating drawings of things that other people need that the approver didn't. And when creating the drawing, use the part numbered released version.

    - At this time everything that is configurable, is still able to have it's configuration changed or is still live as I like to call it. All the configuration states of everything has been captured as a release for tracking. You do not need to switch anything to the released version as it will just create work for nothing.

    Now, something needs to be changed in the product and the change is in the top level document. Remember, everything is still in its live state.

    - I make the change that is needed.  This is the only time you ever need to use the change to version option (basically replacing things with there released version). If I attempt to release now, all the things living in the top level document that have not changed will still try to have the rev bumped because versioning is controlled at the document level not at the part. The system has no way of knowing that you didn't change the parts or assemblies not involved with the change. To keep everything safe and water tight, the system attempts to release them again even though you know they don't need to be. That's where changing to the released version comes in. Changing to the released version is the systems way of allowing you to instruct it not to release something again. So you just switch things living inside the top level document that didn't change to released versions and that's it. You do not switch parts or assemblies living in there own document to released version as it is not needed.  Because these components are in there own document, they, by default, are being referenced to there version not there in progress (workspace) state. Having created the previous release, the system records in the version that that particular configured state is released. When creating the second release, granted that the linked component is still in the same configured state and referencing the same version, release management will automatically recognize the component as released and will not try to release it again.

    - this is why I specifically choose, usually, to keep anything that is part of my design that needs to be configurable, in its own document. Being in its own document, allows it to remain configurable while still reaping the benefits of the system recognizing it has not changed and does not need to be released.

    - directly using the released version only benefits you if the component is contained directly inside the document that another release is being created in. Its also beneficial to use the released version when creating drawings of configured components because you can just select a part number instead of having to select all the right config controls before dropping down the first view. Not using the released version in a drawing I have found opens me up to creating a drawing by accident of the wrong thing.

    - that was sooooo long winded but I actually feel more confident in my own process after having done so. Ha ha.
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    @shawn_crocker - When you do your initial release of the top-level product, are you releasing a single configuration or multiple configurations? Do you manually add each config to the release? 


  • shawn_crockershawn_crocker Member, OS Professional Posts: 798 PRO
    edited June 2021
    @tim_hess427
    95% of the time its only one configuration.  There could be other components underneath that are being represented in many different configurations.  I usually drop the top level model into another assembly that I use as the true company coded product container.  from here I can create explodes and display states specific to the configuration that was selected when dropping in the model.
    I usually only manually add in other things to the release like files(renders) and other drawings geared for different departments (sales, mfg).

    I'm using configurations as a more robust way to achieve a solid works drive works type ability.  Advantage to onshape is that the generated model does not get physically broken away from the master and mistakes in selecting options does not mean you have to create all new files again.
  • shawn_crockershawn_crocker Member, OS Professional Posts: 798 PRO
    Thanks for the feedback everyone. Even after reading the comments I do feel like I should be able to switch between configurations as a convenience, regardless of whether or not they have been released. This shouldn't clash with the release management workflow, because when releasing an assembly containing an unreleased part [configuration], the release of that part would be triggered.
    I think at least we should be able to switch between released configurations 
    That would be handy.  I often want to do this in a drawing.  I can replace with a different part number but takes longer and exploded views reset back to default.  I find myself updating the drawing back to the version, changing the referenced config, and then updating back to the revision of the config.  Should be able to just switch selecting from a list of all the config revisions of the component.
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    @shawn_crocker - thanks for the context. That sounds a little different from my situation. 

    I have a product that can be configured many different ways, and all of the various configurations must be released (and updated when a revision is made). The trouble I have, is that before release, I can easily change the assembly configuration and the assembly updates correctly with configured parts. I'm trying to figure out the best method to keep that same functionality and easily switch between multiple released configurations. 
  • shawn_crockershawn_crocker Member, OS Professional Posts: 798 PRO
    edited June 2021
    @tim_hess427
    From where will you be doing the switching? From the assembly itself or from another tab that the assembly has been placed in?
  • tim_hess427tim_hess427 Member Posts: 648 ✭✭✭✭
    edited June 2021
    After everything is released, I'd like to be able to switch between my various configurations in the assembly tab for the top-level assembly (as well as the sub-assemblies). I really hope I've just got some blind spot in my thinking. 

    Recently, I wanted to check some clearances between two parts and verify that there was acceptable clearance in each configuration. When doing this, I also want the re-assurance of the triangle symbols in my parts list to make sure I'm checking clearances on released components. 

    For context, the top-level assembly includes a configured sub-assembly (also released) and configured parts (each configuration of each part is also released). The configurable sub-assembly also has configured and released parts. Each released configured assembly and part has a unique PN. 

    Simplified Example: 
    1.0 Top-Level Assembly (6 released configurations with unique PNs)
    |-- 1.1 Sub-Assembly 1 (3 released configurations)
    |---- 1.1.1 Part 1 (3 released configs)
    |---- 1.1.2 Part 2 (3 released configs)
    |---- 1.1.3 Part 3 (released, but not configured)
    |-- 1.2 Part 4 (6 released configs)
    |-- 1.3 Part 5 (6 released configs)
    |-- 1.4 Part 6 (released, but not configured)
Sign In or Register to comment.