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.

Iterative modeling in separate documents without versioning

When working with assemblies, I can only insert a part from another document as a version. In some cases, I may be updating an assembly and at the same time updating the inserted part, which requires me to version every update that I want to see in the assembly. Even "edit-in-context" requires creating a version on every edit to see those updates in the assembly. 

My desired behavior would be to insert the part as the unversioned top of the branch so changes are reflected in real time, then apply a version once I'm finished. Because that's how I always worked in SolidWorks, versioning in OnShape has seemed a bit backward to me. If I have the part and the assembly in the same document it's not an issue, but that's not always a good option if a part is used across multiple documents.

How can I use OnShape to freely model in multiple documents? Or is my behavior somehow a bad habit that I need to break, and if so, how can I do that without this being yet another thing that makes OnShape way less efficient to use than SolidWorks?

Comments

  • S1monS1mon Member Posts: 3,046 PRO
    One approach could be while in the early stages of development you keep things in the same document if possible and only move them into separate ones later. 

    Versions are “free” in the sense that you don’t need to worry about disk space or things like that, It does take some clicks and thought. 

    I’m still getting used to this myself coming from Solidworks. I like the possibility to be more deliberate about when a master model forces updates of parts. Early on, having part studios and assemblies all in one document for ease of “instant” updates makes sense. Later, pulling out some of the top level part studios can be helpful to allow for some released parts to stay unchanged by a high level part studio update until you’re ready to revise it too.

    I actually have the reverse situation at the moment where I’m considering combining some documents in order to reduce the need to explicitly request updates. So I get the frustration you’re talking about. 
  • alan_baljeualan_baljeu Member, User Group Leader Posts: 111 ✭✭
    As best I understand, it doesn’t exist to do what you ask.  What you can do is put multiple part studios and multiple assemblies in one document, and all of these will concurrently work to the latest version.

    As best I can tell working in one document means everything is versioned as a package and you can’t mix from one part to the next.  But if you use multiple documents, you need to choose a specific version to reference from another.
    Creating knowledge-driven design automation software, for molds, etc.
    www.virtualmold.com

  • james_howard360james_howard360 Member Posts: 28 PRO
    That's too bad. It doesn't seem practical to put everything in the same document sometimes. In that context, what's the best way to handle this scenario:

    I have a product line with 14 different models. Each of the 14 assemblies has 40-50 parts, and 4 parts are shared across the entire product line (plus 2 configurable parts that are shared but with different configs for each model). In Solidworks I would have simply inserted those parts from their own part files into the assembly, worked on everything at my leisure including changes to the assemblies and parts, then checked everything in and released. This is most useful when initially designing the line or when making changes to entire line.

    In OnShape I would either need a) put the entire product line in a single document which seems unwieldy with almost 600 parts, 14 assemblies, and probably 50 subassemblies, b) leave the parts in different docs, and while I'm working make a change, release a version, go back to every assembly and update, repeat on every change until finished, or c) duplicate the 4 parts into each assembly and accept all the risks associated with that sort of data duplication, negating many of the benefits that should be provided by a PDM system.

    Is there an option I'm not considering? Could I copy a part studio into a document, modify it, then copy-overwrite back into the external doc keeping references? Still means I can only work live in one assembly at a time, but might be better than none.
  • alan_baljeualan_baljeu Member, User Group Leader Posts: 111 ✭✭
    edited December 2021
    I’m with you in spirit.  My preferred workflow would be to have my open branch of an assembly be allowed to reference open branches of parts, and when I create a version of the assembly, I must lock the part version for each reference as well.  Doing this would allow easy co-development, but not force being stuck to.a single version for the whole package.  But this workflow is not possible in OnShape.  

    Your proposal of copy-overwrite also wouldn’t be possible as Overwrite doesn’t exist in a versioned data management system.  You could in theory add a new revision to a part but I’m not aware of such a flow existing.  Imagine generating a new branch of a part as you add a reference into your document, and each version of the document adds a version to the source part branch.  That would work great, if it were coded into the system.  But I don’t think it is in there.

    You could try putting all 600 parts and the assemblies in one document, and think of it like in SolidWorks you would think of a folder.  I’m not certain the UI is up to it; it might be.  But the versioning would be viable if you wanted to do it.  You would imagine creating a new revision as being like a SolidWorks Save All, and creating one Branch for each product assembly (I mean your 14 products).  Onshape has the tools for merging data across branches.

    My alternative suggestion is you keep 14 documents, and this might be doable because if I read you right only 6 parts are reused across all these.  I would have a 15th document to host these 6 parts.  Then unfortunately you will need to manually update the assemblies when one of those parts gets revised.  Or this process could be automated with some programming, where every time the part document is saved (New Version created), all the assemblies get their references updated to the latest version.
    Creating knowledge-driven design automation software, for molds, etc.
    www.virtualmold.com

  • shawn_crockershawn_crocker Member, OS Professional Posts: 869 PRO
    @james_howard360
    Just thought I would mention it as it seems to not have been stated explicitly.  You can move a part studio or assembly out of one document and into another existing document.  I do this often to avoid endlessly versioning and updating when I know I am about to go through a lot of iterations of checking and testing.  When you are done and about to submit a release, you can just move the studio back into its original document.  As a point of interest of mine, how did you end up with 600 different parts all in separate documents?  As I can imagine, many of these parts must need some sort of geometric relation to each other and I am wondering why they would ever have been sent to there own spaces?
  • james_howard360james_howard360 Member Posts: 28 PRO
    The moving part studios between documents actually may be decent solution in some of these cases, though if the part studio has references in its original document as well it may require moving back and forth repeatedly. To clarify, I typically design a single model size (1 of the 14) in its own document, so that doc would only have the 40 or so parts specific to that assembly. Only the parts common to several models would be in separate docs. 600 parts in all separate docs would be untenable in OnShape due to the versioning problem. In Solidworks all parts and assemblies could be separate docs while maintaining live-updating, in-context references, so it was never a problem and gave a really great level of granular control and at the same time allowed complex interdependencies.

    @alan_baljeu I'm interested in the possibility of automated version updating in the assemblies, though I suspect that will get me in big trouble when at some point when I forget to check an assembly that's been auto-updated. The entire product line in a single doc I'm not innately opposed to, but browsing folders and parts in a single doc in OnShape is already a hassle at a much smaller number. The 'tab manager' has eased the pain a bit there, but it still seems miles behind working in Explorer windows speed-wise. I suppose that could be in part my level of practice with each. I think I'll just try tossing everything in a single doc and working with it until I get accustomed to it. What's the major loser from putting all 600 parts in one doc? I only get one level of version control, right? So change history becomes tough to manage, roll-backs have wider-ranging effects, and a branching applies to every part and assembly in the doc. I assume there are permission implications as well since sharing is at the document level.

    Seems like a multi-stage approach is looking best: Initial design of product lines in massive documents to maximize designer efficiency, move/split to appropriate assembly-level docs plus a doc for common parts, then move or combine docs as necessary during heavy change work and re-separate on completion. At least that will have to work until/unless OnShape gives us another option like a persistent "preview latest" setting in contexts.
  • shawn_crockershawn_crocker Member, OS Professional Posts: 869 PRO
    What's the major loser from putting all 600 parts in one doc? I only get one level of version control, right? So change history becomes tough to manage, roll-backs have wider-ranging effects, and a branching applies to every part and assembly in the doc. I assume there are permission implications as well since sharing is at the document level.
    @james_howard360
    The versioning system works the same if all in one doc or all in separate docs.  If you create a version to signal a milestone and you have in your mind certain parts are ready to be stabilized and locking it there current state.  You can "update" them to reference back to a previous version.  I do this and then push the parent part studios into a folder to get them out of my visual space.  I believe the performance of the document as a whole becomes better when doing this also because referencing versions of same doc verses different doc is the same in onshapes eyes.  If you decide to make more changes to these parts, you can update them again to reference the workspace and they become live again.  As for permissions, I agree.  I am really hoping soon we will be able to get more granular control of permissions.
Sign In or Register to comment.