Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- 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
Iterative modeling in separate documents without versioning
james_howard360
Member Posts: 28 PRO
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?
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?
0
Comments
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.
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.
www.virtualmold.com
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.
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.
www.virtualmold.com
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?
@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.
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.