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.
help finishing a CAD/Onshape Best Practices document for a FIRST FRC team
Our FIRST FRC team is transitioning from Inventor to Onshape. I wrote a "best practices" document to help the students get the most out of the software.
Yes, I've had them do the tutorials, yes, I've had them watch some of Team Spectrum's videos..
Does anyone have suggestions of things I forgot to put on there?
1
Comments
It looks good (though I'm not a mech e), but I feel like it's missing some performance tips — our version is here:
https://cad.onshape.com/help/Content/performance.htm
A couple of important ones:
Also, if you have a bunch of engineers all working on the same document, consider locking the main workspace (see https://forum.onshape.com/discussion/24144/improvements-to-onshape-june-7th-2024/p1) and having every change be done on a branch and merged in — that way the main workspace should always be in a "good" state.
Hope this helps.
thank you @ilya_baran .
Just to clarify, you said "Derive can be expensive, even if you're deriving only a small sketch from a large part studio."
But if we have maybe 6 simple sketches alone in a studio in the Master Document to define the joints and geometry of the robot, all of the subsystem documents can derive and reference them without significant impact, right?
should we Insert those sketches into the subsystem assembly and then use context within the subsystem doc, or can multiple part studios in the subsystem doc derive from the master doc?
Can the subsystem docs derive a few simple volumes (rectangular battery, basic chassis, etc) as well as the sketches?
You may want to watch Greg's video on controlling references using 6 simple sketches in a master design and see if your best practices ring out.
@ilya_baran @GregBrown
Why is derive more expensive than in context? That doesn’t make much sense. Is there any way to make them more equivalent?
@billy2 That is how I am trying to get the students to work, yes.
@joshtargo 6 sketches (that are not humongous, say less than a few hundred entities each) is not expensive — it's a totally reasonable thing to derive into all the part studios in your design.
@S1mon Unfortunately, here I have to say "it's complicated internal reasons" that have to do with caching, referencing, configurations (as a result of which we may not know what we're deriving until we're part way through the derived part studio regen), etc. Basically, derive is a very different and in some ways more flexible mechanism. We have thought about having a lighter-weight version of derive, but haven't yet figured out a solution good enough to implement.
@joshtargo many have tried to define best practices and your document is a good start. In practice it's a very complex problem and I haven't seen anyone do it correctly. It's elusive.
I would highly recommend you share Greg's video with your students because he did a great job setting up his project. It shows how a little organization can go along ways with parametric modeling. It'd be great if he would share his project with you and your class.
I'm not a fan of master sketch because I prefer in context. I did check the OS manual and it's still listed under derived. It's a simplistic way to control many parts using a part and the OS guys are really happy with this approach. My argument against master sketch is it's 2D, it's a sketch. Most referencing schemes are/should be 3D which can be handled more easily in context. But, how do you declare it? I don't know.
In a project, it's important to declare the design intent and how the CAD was constructed. With a parametric design, you have to declare the changes that you can make to the model. It's impossible to construct a model that can handle any change, you just can't do that. You need to explain to the next engineer how you created a model that allows the foreseeable possible changes. If you have an x-y table, then use a master sketch. If you have a 5 axis scara good luck with a sketch.
The last company I worked at had a part file or part studio that was 10 years old and derived over a dozen times from legacy part files. They were at feature number 20,000 and it was a total mess. I like Greg's statement, keep the feature count down. Also, his assembly constructs, he always knew where 0,0,0 was located in an assembly. Assembly by coordinates. There's many good habits in his video and I wish more followed his guide lines.
@billy2 this is an example of a master sketch that we would use. the sketch works out the shoulder and arm lengths in orange, and is then derived or used in context by whoever is designing the actual shoulder, arm and claw. if they use the critical points on the sketch to define the location of the joints, the lead designer can change those later from the sketch.
@joshtargo thanks for sharing. I was thinking more of a stickman representation or skeleton for the driving sketch. It looks like it translates and rotates in a couple of spots. Is the motion planar?
Here's mine. It's a partstudio located inside an assembly using coordinates. Assembly by coordinates is a must in my world and I got some tips from watching Greg's video on how to maintain assembly alignment.
I position all the components in an assembly and then let the "master" or in my case it's a partstudio defined incontext to figure out the solution. It fails 1,000 times a day and shows me where its failing. I tweak it a lot because at the end of the day, I don't want anyone else to package tighter than I did. I want it to be the smallest package possible. Parametrics is the lightest, strongest, fastest and cheapest possible because of change. I'm feeling like a salesman.
I do have a top level "master". It's driven by global variables and has a few components tied to it.
I tend to tie few things together to my "masters". It's more of a design tool versus demo candy showing how good I am at changing models. I'm trying to avoid tying things into a knot. I think the "master" should be simple definitions. Things pop out of the enclosure all the time and I have to fix them.
I am envious with your project, nothing moves in my project except the power box's door. The door will open/close using a simple configuration. That's kind of boring stuff. It's not tied to a master but it is good to know that the door can open when it's all built out.
My recommendation for "masters" is to keep it simple and declare it somehow for the next guy assigned to the project.
this is the kind of stuff we work on:
Interesting video, thanks for sharing.
I wish industry was as good as you at specifying CAD standards for their projects.
that's not my team, but we modeled our process after theirs.