I gave a presentation at the New England Mentor Conference about Onshape Best Practices with a heavy focus on improving performance in Part Studios and Assemblies. I got around to cleaning it up and wanted to put it out for more teams to use. The performance recommendations are informed from conversations I’ve had while working here at PTC.
Onshape Best Practices for FRC
Hopefully some of this is useful!
Sincerely, this is one of the best FRC presentations I’ve seen in a few years.
Likely some confirmation bias as I’ve been focused on onshape performance recently… But it’s damn good and helpful.
Seconded. This is a great presentation. Everything in here is relevant, valuable, important, and helpful. I already sent it off to 1678’s hardware design students.
5 Stars!
Great stuff Drew, thanks for sharing! Lots of good stuff in here I feel like maybe I knew, maybe I didn’t, but definitely had not put much thought into having guidelines around
In part studio, set tessellation qualities to medium (can be turned up in assembly)
Can this be turned up in assemblies just because it’s then all versioned parts/assemblies?
Also, could this be summed up (in a grossly oversimplified way) of suggesting that the following are some recommendations?
Are folders also all loaded in parallel? Or is putting stuff in folders an effective way (although maybe too hacky) as limiting initial load time performance hits?
are you able to share some of the context about what makes this example take 31s as opposed to (25 s + 2.5 s)? It may be one of those things I just accept, but it doesn’t make intuitive sense to me right away.
Appreciate the feedback! This presentation went through a few rounds of development, so I’m glad it ended up as a useful reference.
The way to change this from the assembly is to right-click parts/subassemblies you want to bump the quality on and choose “Use best available tessellation”. This’ll set the quality to very fine, and while it looks good, you’ll definitely see a performance hit. It’s easy to toggle back off and I generally only use this when it’s time to take screenshots for the tech binder.
In theory, no. Ideally the parts that are being split off are things like custom gears, pulleys, or camera mounts that rely on maybe one or two of the parts. By default when you derive from a part studio to another in the same document, it derives from Main, and changes made to the part are immediately reflected in the derive. Deriving across documents is where you’re pulling from a version and need to carefully watch and update when needed. There is definitely some risk though if references are somehow broken, so it should definitely be done with some care.
I don’t think it matters a ton, groups are so low-resource. I instruct the students to group them by “motion group” in each subassembly (like outer elevator uprights, inner elevator stage, and carriage are all separate groups). Go with whatever feels best.
Your top-level robot will still be chunky regardless if you split at the subassembly level, so I’d focus more on what can be suppressed or swapped out for simplified versions. The FRCDesign.org group has made nice simplified swerve modules and gearboxes - swapping those in would help a lot.
Yup, I’d say this is pretty good!
Yes, loaded in parallel.
My very mechanical-brained explanation for this is load times go up exponentially(ish) based on the complexity of the part studio. A sketch in a new part studio will resolve faster than the same sketch at the end of a busy part studio based on how many other existing features the new feature needs to check against to see if it references those or changes them in any way. This is why pulling the bevel gear out helped - there were a lot of other features in the part studio, and while they were irrelevant to the gear, there are still some number of dependency checks that have to be made.
Awesome presentation Drew! I’m happy to say there’s a few things here that I haven’t yet learned, so I’m excited to try those out!
One thing you touch on but don’t elaborate on in much detail is a consistent Orgin. I’ll admit that initially I was skeptical, but I must admit that the Origin cube featurescript is incredibly intuitive to use! It also has the added benefit of built in functions which makes designing powertrains really parametric. My team struggled with maintaining consistent orgins in 2024 (our first season using Onshape) but with the Orgin cube FS we’ve eliminated this problem practically overnight.
I love origin cubes, we had been using ours with the bottom on the origin instead of the cube’s center. That let us always use the bottom as the floor and made it a little easier to grab small MKCAD parts inserted at the origin. The featurescript makes it much easier so it’s worth the slight change in our process.