Our team is trying to find a good method to start properly cading out our robot for this upcoming season. As of right now our cading program is going to be OnShape mainly because of how its accessible from Chromebook. From what I’ve heard from those who are working on OnShape, they state that it is really slow and can’t handle large files. We use the edu version of OnShape if that means anything. Is there anything that can be done to help this issue or fix it? Or any tips ion general that could help to make our cading go smoother?
What my team does is CAD all the subsystems in different onshape documents then do a finial assembly in a different document, that way you are rarely working with the who robot, that helps speed things up quite a bit. But really unless you do extra detail (like every fastener or something) it’s usually not that bad and really more dependent on how fast your internet is.
1745 has used onshape as our primary cad platform since 2017.
I don’t think there is any performance difference between edu and enterprise.
Things do get sluggish towards the end of the season, but that’s like a week 9+ issue.
Many of our students use Chromebooks for basic parts and assemblies.
The best way to make it manageable is logically break up your assemblies and sub assemblies and part studios and only have 1 or 2 “everything” assemblies.
- Check if you have hardware accelleration on and use this status checker (Onshape) to check if everything is turned on and working. For FRC, Onshape isn’t really slow unless you make it slow.
Be EXTREMELY deliberate with part studio, feature, and feature script usage as well as deriving parts. It’s fine to have subassemblies and even multiple subassemblies in one part studio (switching between part studios is a waste of time), but if it gets too big or complex you gotta split it.
Featurescripts love to eat into load times, but they also can be huge time savers. Definitely a double-edged sword you gotta consider.
For example, the gusset feature script + tube converter featurescripts can be useful, but both can add insane amounts of load time if used multiple times, especially with gussets. You can get away with designing the gusset yourself quickly, so you can skip it, especially if you know it will be a bigger document.
Design simple, have a decent computer and wifi and understand how features impact your document load time are all important.
I would recommend splitting into multiple documents anyway, as it’s good for versioning purposes and load times too.
You can also play with sketches and deriving to optimize load times, but it’s kind of a hassle to learn.
When it comes to parametric multi-part modeling, there are lots of ways to approach saving time, though its a careful balance between deriving the right parts, utilizing master sketches, and modeling in context of other parts, as well as making sure your sketches and CAD are as parametric as possible (easy to edit) to make sure that you can quickly fix issues that arrive, and iterate on cad as you get more information.
No reason to have 15 part studios for an intake when you can have a single-part studio, an assembly, and a folder for imported parts. Reducing the number of part studios you use will massively help with saving time as you don’t need to switch and cognitively keep track of each thing, but on the other hand, it can punish you for poor feature use more frequently as load times stack.
For the majority of teams, though, it’s probably min-maxing to a high level. You can get away with a loooot of stuff for FRC as long as you design a robot or two, and learn stuff on the way through survival CAD, go through the onshape fundamentals and top-down design pathways. You should be fine. CAD efficiency isn’t too much of a problem if you have multiple designers, or designing a dead simple robot. (always design simple)
I’ve been using this example robot that got cooked up last season and it has a lot of good stuff in it as far as file structure and modeling practice goes. Let me know if this helps or if you have any questions.
The main idea is to have a master sketch that drives the modeling of all your components. Getting away from dimensions as much as possible opting instead to use sketch relationships to define geometry. That way if you need to make changes you aren’t changing 800000 different dims more so a few misc ones like ball size, shooter height etc.
I agree with all the advice here, and just want to recommend strongly emphasizing with your CAD students that it’s actually important not to put in every rivet and bolt, and why. Every year some rookie hears “don’t bother” and thinks “that’s okay, I WANT to spend the time! It’s no trouble!”
It depends on the performance. Putting in every nut and bolt can help with ordering and assembly instructions. Sometimes (often actually) it’s important to know the correct length of bolt.
If fasteners were put into a sub folder and hidden when not needed that should speed up rendering.
Absolutely. I usually advise them to put in one or two bolts in each place, to make sure they fit & to help them remember which ones they planned to use. For example, one bolt on a bracket instead of all 8. But your way is a valid strategy too, if it doesn’t slow you down too much.
I believe you should have at least one assembly with EVERYTHING.
If it can interfere or be purchased, it needs to be in CAD.
You can make a configuration and put nuts and bolts in that if you want, then suppress them as necessary.
I think rivets are the main thing snichols is emphasizing.
The main problem is that you get extreme diminishing returns doing what you are mentioning, especially when you get slightly more complex.
Especially in build season where time is crucial, wasting your time cadding rivets and dealing with load times to cad the random details will eat up a ton of crucial time that could be used for somewhere else. A full robot assembly with every fastener, wires, and whatever takes 2-4 minutes to load in onshape, and requires a high proficiency to do efficiently, something most students aren’t experienced enough to do optimally.
Design is all about trade offs (time being one of them), if you design with intent, you won’t need to cad every small thing.
The time tradeoff is when fasteners aren’t ordered because they didn’t show up in the BOM.
You can cad the necessary fasteners, no? Back to the idea of intent and tradeoffs, you’d throw it in cad if something is a special fastener that isn’t regularly stocked by your team, needs to exist with tight clearances, or you just feel like it.
Design things are necessary while reducing assembly and part studio load times so that you can design faster. The CAD is more accessible while still having everything necessary to ensure there are no delays.
I doubt even you are cadding every single detail, most designers will purposely leave stuff out if they know they don’t need it.
Show me some of your CAD if I’m wrong, that has every single fastener, wire, and detail in which you were able to, and tell me how accessible it was for your team.
Just to add to the discussion, we usually CAD bolts but not nuts or rivets. That makes sure there’s clearance for bolt heads in any tight spaces and gives us a better weight estimate while still saving time and processing resources. We use almost entirely standard bolt sizes that we buy before the season so we don’t have to worry about including bolts on the BOM, but this would allow for that as well. It also means that when we go to assemble the system the assemblers know what size bolts they’ll need for where instead of having to measure in the CAD. IMO it’s a pretty good middle ground.
My experience with onshape in frc is just try not to use the actual .step of some of the electronic components (vrm, pdh, rio, etc) instead, cad it as a square to figure out placement. Other than that, it’s pretty good other than later on when you’ll see longer times with opening the file.
We try to add fasteners as much as possible for the following reasons:
It forces students to think about how the parts will physically be assembled and whether assembly is possible.
It allows the assembly team to easily identify what fasteners to use.
By selecting faces it is fairly easy to quickly add fasteners. The replicate tool and standard parts help with the speed. Since it doesn’t add us much time, why not?
As I mentioned earlier having items in the BOM makes it much easier to check out inventory. Our location means we have to wait a few days for orders to arrive so ensuring specialty items are ordered early is crucial.
Onshape is pretty fast. By using separate documents for each subassembly we don’t find load times are much of an issue. We do suppress fasteners if we need speedier load times.
We have been within 0.2 lbs of the weight limit. Having fasteners in CAD allows us to have a pretty good estimate on weight.
At the moment we don’t CAD wire paths although we do work out a plan and add holes to allow us to add velcro or zip ties to secure wire bundles. Our main reason for not including wiring is he haven’t developed an efficient, easy method of doing it. We are exploring options like featurescripts.
At the end of the day each team has to develop practices that works for them. These work for us.
That makes sense. Especially new members may have trouble with assembly. I’ll take that into consideration.
There isn’t an easy way.
If I wanted to model the wiring I’d use an estimated diameter for the multi wire bundles and split off other smaller multi wire bundles to motors, controllers, modules and sensors. To make things simpler I’d just model the paths of the main bundles and use it as a space reservation for wiring to locate where the cable ties need to go.
I wouldn’t even attempt to model each individual wire.
This is what they do in the various companies I have worked for that make electrical equipment for industrial applications.
1745/8874 is going to try and have the design team put in ziptie anchors in the cad as a standin for the wire routing. Trying to “force” thought and decisions
Once we get our OA stuff up you can follow along to see if it works or not…