Home› Using Onshape

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.

How do you manage delivered products in Onshape?

e_g_ee_g_e Member Posts: 18 PRO
in Using Onshape
Hi!

Our company is transitioning from purely R&D work to a phase with more delivery focus and aftermarket services.
As a consequence, we will have to manage several products operating simultaneously at the customer.
It is probably most common that info about a delivered product consists of a BOM and a set of drawings, but we would like try having a "digital twin" of each one in Onshape.

Currently we are branching out from the R&D workspace to capture the version of the ordered product, but with an increasing number of deliveries, this quickly clutters the history tree.

Are there any best practices out there on how to keep track of all the delivered products in CAD and at the same time continue R&D?
Tagged:

Comments

  • S1monS1mon Member Posts: 3,293 PRO
    Revisions + publications.
  • Nath_McCNath_McC Member Posts: 130 PRO
    As S1mon said, Revisions and publications. 

    I use versions on the model changes. However, I use the revision of the drawing as the control point for products. This is when you follow the release process.

    For example, I may have part one, which has a drawing at revision C, but the tree is at version 31. I then make multiple updates that change the model and drawing to version 41. However, I will then update the drawing and release that to Revision D.
  • tim_hesstim_hess Member Posts: 46 ✭✭
    It sounds like you might be discussing something like a large machine that is developed and then shipped to a customer. Over time, that product might be upgraded. In parallel, you might make design changes that apply to the next products that will be produced. So, you want to track the design evolution of existing products as well as future products.

    If that's correct, I would consider making a copy of the product's top-level assembly and putting it in a new document at the time it's delivered to the customer. This copy, in a separate document, would be the "digital twin". That way you can capture how it was delivered and have a clean history tree for any chances made after delivery. 
  • shawn_crockershawn_crocker Member, OS Professional Posts: 884 PRO
    Feels like a separate system that integrates seamlessly with onshape would maybe make it easier for the non-cad team members to visualize what is going on.
  • e_g_ee_g_e Member Posts: 18 PRO
    tim_hess said:
    It sounds like you might be discussing something like a large machine that is developed and then shipped to a customer. Over time, that product might be upgraded. In parallel, you might make design changes that apply to the next products that will be produced. So, you want to track the design evolution of existing products as well as future products.

    If that's correct, I would consider making a copy of the product's top-level assembly and putting it in a new document at the time it's delivered to the customer. This copy, in a separate document, would be the "digital twin". That way you can capture how it was delivered and have a clean history tree for any chances made after delivery. 
    Yes, you are right, tim_hess. We are building robots, basically. I guess I should have specified that, since I guess it is a different story having a vast assembly as a product compared to a single part.

    Doesn't sound like bad idea to copy the top level assembly into a separate delivery document
    Our top level assembly consists of several sub-assemblies, all having their own document. Any idea on how I should manage upgrading a single part iside one of these sub-assemblies in the delivered product? I would have to modify the sub-assy document then?
  • e_g_ee_g_e Member Posts: 18 PRO
    S1mon said:
    Revisions + publications.
    S1mon and Nath_McC, I'll check out publications, thanks! Haven't tried it out yet.
  • e_g_ee_g_e Member Posts: 18 PRO
    shawn_crocker said:
    Feels like a separate system that integrates seamlessly with onshape would maybe make it easier for the non-cad team members to visualize what is going on.
    Yes, that too is necessary. We are going to try out OpenBOM, using it as a link between Onshape and another PLM software.
  • JPMJPM Member, csevp Posts: 16 ✭✭
    edited April 9

    e_g_e,

    We're changing from a custom machine builder to more standard machines and I'm having the same questions about how to best manage a growing number of the "same" machine. Were you able to work out a good system for this?

  • e_g_ee_g_e Member Posts: 18 PRO

    @JPM

    Yes, I think we have landed on something that works.

    All our assembly documents including the top level assembly of the product have a Main branch and a DEV branch in the history tree. All work is done in the DEV branch, and all feature changes are branched from and merged into this.
    Main branch is workspace protected, so we only do releases of the documents main assembly here.

    For the top assembly of the product, we make sure all sub-assemblies and parts are released before we merge it into the Main branch for final release of this robot version. This release markes the point where we can duplicate separate robot units from.

    NB:Since the Main branch is workspace protected you need to copy the assembly tab to clipboard. It can then be pasted into a a separate document, and here receive the metadata for that specific robot.
    Once it have its own document, we do a release on the assembly, to mark the point where it was delivered/FAT/SAT/or similar.

    Now this assembly represents the unique robot, with a uniqe part number associated with it. It will have a dedicated BOM and lifecycle in PLM from here.

    Hope that was more or less understandable.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Sign In

Categories

Vanilla Forums