Best Uses of In Context?

S1mon

This video from Onshape was posted recently https://www.youtube.com/watch?v=mFRe9D4M_uo

It shows the process of modeling a (simplified) radial bearing using a part studio to create the inner race, outer race, and one ball. Then they create an assembly and use the context to create the cage part.

While there are always many different ways of modeling anything, it got me thinking about my personal biases. From years of pain in Creo and Solidworks, I avoid In Context modeling as much as possible. I'm very aware that In Context is much better in Onshape than in many other tools, but it still seems like one more set of references (in this case to a separate tab) which could go wrong. 

Personally, I would probably define a variable which controls the number of balls in the bearing, and then I would create the cage in the same part studio as the other parts, using the variable to control the angle of the segment of the cage. Then I would pattern that segment to make the full cage. In the assembly, I would pattern the balls using the variable.

To me, In Context makes the most sense when using references from parts which have movement and/or lots of off-the-shelf parts which are not driven in a top-down manner. For example, the wiring features make heavy use of contexts. Or in the training, there's a set of pedals which have motion and different positions are used create contexts which impact part design. This bearing example is easy to digest, but is it the best use of In Context?

Konst_Sh

I think in-context is best to use for creating some minor features like holes, machining to mating geometry, tabs and so on. The base shape should be made without reference to the context

eric_pesty

@S1mon
I agree there is no value in using a context in this example as all the other parts are already in the PS! so you could create the cage around the one ball and pattern that.
Knowing that things won't change unexpectedly makes it a lot "safer" to use and I have occasionally used a context as "quick and dirty" way to create "one time" static references, even deleting the assembly afterwards as I don't plan to ever use it again. 

Basically I try to do the design within a single part studio or using derived references before using a context as these are easier to maintain and update.
Contexts are most useful for referencing different positions of a design. The "pedals" example is a good example, as well as the stepping stool one if you haven't watched it yet... https://www.youtube.com/watch?v=U-Kp7z_xPUs.

Or for wiring and other things that need a bunch of references from a higher level like mounting holes for a bunch of OTS hardware placed at the assembly level.

S1mon

@Konst_Sh

@eric_pesty

Thanks. That's pretty much what I thought. I wish that videos from Onshape would reflect best practices more clearly. Just because something can be modeled in a particular way, doesn't mean that it should be modeled that way

Another pet peeve - sketching on faces of models when a plane or mate connector would be a better reference, especially when "disable imprinting" is set to its default state. I see this kind of thing too often.

I'll give a pass to people competing for something like a Too Tall Toby speed modeling contest, but in general, I judge parametric CAD modeling skills based on how easy it is to modify and maintain a model. What expected (and unexpected) changes can I make easily without things breaking? How hard is it for a new team member to open a model and understand what's going on?

In Context has great uses, but it should not be the first thing that you reach for.

eric_pesty

A more general comment, some of the videos on the Onshape YT channel (like this bearing one) aren't actually produced by Onshape and there is some variation in the quality... I wish there was some more strict "vetting" going on to avoid ones that show "sub-standard" quality of work, especially if the video doesn't explicitly state that "this might not be the best way to do this, etc..."
The Too Tall Toby ones are good because he clearly states that the series intends to show a progression and aren't presented (at least the early ones) as "tutorials". 

martin_kopplow

In context can be a very powerful tool, but as with all powerful tools, it is pretty easy to drill yourself into the knee with it. A few days ago I actually managed to build a circular reference that wasn't cought and which I could not resolve. I find it especially hard to keep track of what references exist and beween which 'nodes' in the model. That is probably my biggest issue with in context and feels like flying IFR with no campass. 

Else, for parts that depend on each other, it can be a life saver. Nobody else looking into the design later, will understand what is going on, though, and I've gotten much more careful using it lately. I do, for example not design complete parts in context any more. I rather use it to extract reference geometry (mate connectors, planes, points) from an assembly (like for connecting parts), but then design the actual parts in their part studio. 

rafael_telgmann

Very interesting topic. I have been working in a mechanical design environment for 20 years in various positions. To cut a long story short... my conclusion is: regardless of the CAD system you use, the less dependencies a part or assembly has, the better. But I think you have to distinguish between the development workflow and the "maintenance of CAD models" workflow.  If you are creating completely new assemblies and looking for solutions, making variants and so on, then features like "in context" are useful. But it is often the case that you need to clean up after the "mess". Rebuilding a part or assembly, even if everyone hates it, is sometimes the best thing you can do to get a model that is easy to maintain, update and understand.

eric_pesty

The nice thing with the way Onshape does contexts is that you can use a context in the early design phase and then never update it again, basically just use it as "layout" geometry. You then just need to avoid creating direct relations to it down in the tree (just create a couple of layout sketches/faces that reference the context at the beginning) then you can basically ignore the context when it comes to maintenance...

The good part is that you do keep the option to update the context in the future. You can do it in a branch to check what breaks and do a compare of the part studio to decide if you want to do it that way or just "manually".

billy2

Global variables are fantastic for controlling top level parameters and I'm using them a lot. I had the same thoughts about in context when instead you can use global variables. Global variables are front and center and easily discovered. Will an engineer learn them and use them? Who knows?

What about 500 global variables? Some will create a project with pages of variables which will make them useless.

In context won't go away especially with larger projects. Global variables & in context will both be abused for those who don't plan.

There's no substitution for project management and controls for how things get done. It's the wild west out there, with everyone doing things their own way. Or worse, people are just building solid models without thinking about parametrics. Most companies should be using ME30, space claim or some other direct modeler. I have no idea why they're using parametrics.

32 years ago we were selling against SDRC with Cadkey (the best CAD system ever), SDRC said that without parametrics a handheld camera would take 7 years to develop and with their parametric CAD they could be in production in 2 years. They were right and most CAD systems are parametric modelers today. Parametrics was sold for rapid changes, quick iterations and shorten development times.

The best instructions for using parametric modeling was proengineer in 1994. That's when skeletons came out because no one could figure out how to build a parametric assembly. Controlling the datums in a higher level was an easier concept than controlling the details. Building parametric assemblies in proengineer was difficult but it made you think of the structure and forced you into project management.

Solidworks came around and simplified a lot of things. Tri-association was gone where drawings, parts & assemblies were sync'd up. No one used the feature dimensions in a drawing but instead added new ones. Building assemblies was now easier because you could just throw things together. The required structure that pro required was stripped away.

You have to figure out the structure and then get everyone to follow it. This is missing today. Look how @eric_pesty is telling you how they do it, it's because they have structure. How come he's the only who talks about it?

There's a mis-conception that companies are to different to apply a specific process to CAD. I've worked with 1000's of companies and they aren't that different. There's at least 95% overlap and Onshape should develop a basic project structure for companies.

You need to fly to Massachusetts and guide them to do the right thing. I believe they want this.  I support you. Go do it.

In the very beginning before in context, we fought proe in the early 1990's when it was a bottom up design tool. We would tell engineers that with proe you're going to design a bunch of parts, then throw them into an assembly and start selling product. The room would roar with laughter and designers would ask about the engineering layout? 2 years later PTC released "design in the assembly", a convoluted engineering layout. The rest is history.

Solidworks eventually added "design in the assembly" and renamed it to in context. I don't know the differences but it seems we all call it in context now days including PTC.

On the PTC website they have a history which very interesting. They did create parametric modeling and it's a good thing for rapid development and quick changes. We sold a lot of pro/e, but I don't believe it was about parametrics, I think people really wanted shade n spin. You see, most engineers were doing wireframe and then saw pro/e spin a model. I think that's what really sold pro/e. Forcing people into parametrics is difficult but it's still the best engineering tool.