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.
When to use subassemblies / best practices for handling large assemblies?
cmot17
Member Posts: 6 EDU
I have a fairly large assembly and I am struggling to organize it correctly.
As the assembly has gotten larger, it's harder to find the instances that I want and OnShape slows down significantly. I also feel that some parts of the assembly make up logical subassemblies (such as the mount portion of the assembly vs the external intake). However, if I split those into subassemblies I lose the ability to reference their assembly on the common drivetrain and each other - both of which are really useful when everything in this assembly is so related.
It almost seems like in-context modeling of assemblies would be useful in a situation like this. Am I missing an obvious best practice here?
Thanks!
0
Answers
A better practice would be to model parts for each major mechanism in a single parts studio, and to orient all of your parts studios to the same origin as that in your top-level assembly. This approach allows you to create the parts in the same spatial relationship that they will occupy in the assembly. Use the group mate to constrain parts that don't move relative to one another. You've correctly perceived that it makes sense to have subassemblies correspond to mechanisms- the multipart modeling approach will allow you to realize that goal with a minimum of fuss.
Here's a link to a simple robot assembly modeled usign the practices I described. No game-specific mechanisms, but enough complexity to give you a feel for the approach. See you in Detroit!
.