Pearadox CAD standards (onshape)

Technical CAD
#1

For 2020 our team switched to using Onshape, and it was a great switch for us. We’ve had more students engaged with CADing than ever before, MKCad made things easier than ever, and after the season we learned about featurescripts which would have made the build season CAD even better.

One issue we did have though was once the robot assembly started getting large, it was hard to tell when it was taking awhile to load due to the document, due to the schools wifi connection, or if some part studio was broken or had a long regen time. Also, keeping track of everything got to be a mess; why do we have 5 drawings for a part? Is it up to date? Where is this part located? Why is part ABC not even in this document? etc.

So, for better or for worse we had some students and a mentor really put some time into generating some CAD standards by figuring out what is our ideal set up for an onshape document and feature usage. I’m not sure if there’s anything ground breaking in here compared to how 1678 or 319 structure their onshape documents, but this way it’s written down for us - especially a lot of things that we consider “best practices”. Please feel free to peruse, critique, use and call your own. There’s still plenty of clean up and things we’ll want to add at some point, so we’ll have new versions come out if we decide to change any processes. They’ll be available here: Pearadox Resources - Pearadox

If you’d like to compare our 2020 Robot CAD pre-standards and post-standards:

Huge thanks to our students who put a lot of time and effort into not only building this document, but also redoing the 2020 Robot following the standards to stress-test it. Also, a huge thanks to Laura, our mentor who initiated and oversaw the effort. Most of my efforts were limited to trying to reduce how much structure/standards we create, haha. I’m excited for more of the team to use the standards as we re-do past robots in onshape following these standards this fall!

15 Likes
#2

Thanks for sharing, there looks to be some great stuff here. We experienced some of the same slowdowns and found that there was a daily backup that ran when we were meeting. They switched the backup to 3am and it was a huge improvement! The other strategy we are trying this off-season is to have a separate document for each subsystem. It seems to work pretty well so far.

1 Like
#3

I’ve intended to investigate a different document option, but one problem I think with it is the main robot assembly will not automatically update with any changes to the other mechanism documents. That may be a desired feature though.

I think in general though inserting an assembly that’s been versioned does also speed up loading time (even if it’s in the same document). It’s just no longer “live”

#4

That is a feature that I like. My plan is for two people (student and mentor) to be responsible for the main robot assembly - they update it when subassemblies are complete. There is an icon in the assembly view that indicates when a subassembly has a new version. My goal is to be more methodical when reviewing subassemblies.

1 Like
#5

Ooh, this is a great document! There’s a lot of really great standards which i definitely might look at using. 1745 has been wanting to add part numbers for a while now, so I’ll probably look more into your method of implementation now and in the future.

There were a few things I found peculiar while digging through. For example, I was surprised to find that you guys were using configurations for mechanism positions, as opposed to display states and named positions, which was something I had never really considered before. I suppose using configurations makes it easier to see and update the positions, but I do like the flexibility and ease of use of the built in options.

Drawing wise, I also personally like using ordinate set dimensions on longer parts, as well as annotating the depth of holes (I use THRU if they go all the way through), any tapping I want added, and I’ll occasionally use TYP to call out a dimension or hole which is the same for the entire drawing. Those are personal standards I like to use, but they might be worth adding or at least mentioning them or something like them, if your team wants to use similar nomenclature to make your life easier. Ordinate dimensions in particular are lifesavers for really long parts with lots of holes, like big pieces of tube or angle stock, and they can make a drawing much easier to read.

Also, I’m not sure if you guys use belts, but if you do, then it might be worth mentioning my Belt Calculator, which I think you might find useful. In any case, I really like your document! It’s clear that a lot of work has been put into it, and I’m definitely going to refer to it in the future!

1 Like
#6

I’ll ask the students about the display states/named positions vs configurations. I’m still learning about that myself, so I don’t have anything intelligent to contribute about that.

As far as drawings go, I also like ordinate set dimensions - however for our machinists that doesn’t always make sense if a part is long enough that they re-zero at any step. That’s a big part of the reason for having a machinist sit down with the person doing the drawing to get it approved (or “approved”…we’ll see how it goes in practice compared to in theory). We do a lot on our manual mill, so we’re obviously optimizing the drawings to how we do our machining - which may not make sense for other teams.

We’ll have to check out the belt calculator. We’ve only just starting using belts a little bit more frequently

#7

These standards look really good! I’ve been meaning to do something of the sort for a while, and will 100% use yours for inspiration

I don’t mean to derail this thread too much, but this belt calculator is quite possibly one of the most useful tools that’s been made for fs (on the level of tube convert imo)

1 Like