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.
New Video - Project Topologies: Planning Onshape Models
I made a video detailing the document strategy (one or multiple) and the flow of data through part studios to create robust models. It's not cool modeling tricks, but is a super important topic that you need to think through to have a good time modeling anything of meaningful complexity in Onshape, especially as part of a team.
3
Comments
already showing this to my robot team
Very nice.
I have subscribed to your YouTube channel!
Thanks!
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
@EvanReese
This is a very helpful explanation for a lot of people and small teams. I plan on sharing this with my team.
Onshape training needs to have more stuff based on real world projects/products. There are too many toy examples which don't have the complexities or constraints of actual development engineering. Hopefully in your new role you'll be able to collect more examples and learnings from multiple industries.
One thing that is important to understand about larger projects and/or teams is that a document is a unit of branching, merging and history. You rightly started splitting things into more documents as complexity grew in the projects. The reasons for that are not just performance, but also the ability for the story of a document to make sense. One of the many reasons for OTS parts to be in their own document(s) is that they are mostly going to come from imports and need a little clean up and metadata at most. OTS stuff is unlikely to branch and merge. OTS stuff is also more likely to get reused in future products/projects. It's awkward for it to be in the same document as all the custom parts which are related to a particular project.
For complex projects, subsystems often need their own document because their development path is not identical to the main product or ID. Early in development, those subsystems may be bench tested and iterated on with different concepts where branching and merging the entire project doesn't make sense.
I'm a little confused about the mentions about Super Derive and variables. Now that we have Variable studios, is Super Derive still useful and necessary for distributing variables? I'm also curious what your take is on @GregBrown 's Publish feature?
Another way I would look at this document structure topic is to review some of the things that don't work as well and why. For example, there are occasionally people that will say that every part should be its own document. For me that's completely missing the point of top-down design and collaboration possibilities, but it seems to have grown out of a fear of how release management works and how to find things. It's coming from people used to file-based CAD that haven't really understood Onshape.
Document structures also evolve over the course of a project. Early on, most/all of the project may be in a single document where rapid iterations with live workspace references are essential. As maturity and complexity grows, it makes sense for a bunch of reasons to split into multiple documents where, by definition you have to use version references. Even within the same document, there are phases of development. As things become more real and release management is essential, references need to switch from workspaces to versions/revisions.
@S1mon Lots of excellent points and comments here. My replies below
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com