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.

When to use subassemblies / best practices for handling large assemblies?

cmot17cmot17 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!

Answers

  • edward_petrilloedward_petrillo Member Posts: 79 EDU
    Nice work getting a Rapid React robot modeled so completely at this point in FRC build season!  Our team (293)  is working on the 6th robot we've modeled in Onshape, and we're not quite as far along as you are.  Your difficulty handling a full robot assembly is a consequence of your approach toward modeling the novel parts that you are combining with imported COTS parts.  You've modeled those parts in about two dozen parts studios and left yourself the task of mating them all in your top-level assembly.  The number of mates you've used to constrain everything together is a clue to your performance issues.  

    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!
    .  
  • ilya_baranilya_baran Onshape Employees, Developers, HDM Posts: 1,173
    I have to say I'm always really impressed by the sportsmanship culture I see in the FRC.  Good luck to all the teams!
    Ilya Baran \ VP, Architecture and FeatureScript \ Onshape Inc
Sign In or Register to comment.