Why are you so Afraid of In-Context Design?

I’ve done a fair bit of consulting, and generally visiting CAD users from beginners to advanced. Between my time working for resellers and working for myself, I’ve been invited to visit and suggest improvements at dozens of facilities. Every company has a different level of sophistication with the software. CAD software is really like any complex system where the majority of people don’t understand it 100% in that there’s a lot of – how do I say this – superstition. You get the folk tales, rumors and wives tales that combine into beliefs that have a certain level of truth, but no one really knows how much, or which parts. Superstition often leads to fear.

One of the stories, maybe the most common story I’ve heard talking to SolidWorks users is the various tales about in-context design problems. In-context is one of those things that seems to work well when it is demoed before you buy the software, but after you own it, no one wants to try it, and those who did try it have returned bloody and beat up. The sales demos seem to work in a clinical environment only, not in the real-world life situations that you find in day-to-day CAD use.

The worst abuse of in-context processes I ever witnessed was on a relatively small assembly of less than 50 parts. It was an injection mold die. The company was a relatively new set of users, and once they saw the ease of in-context modeling, and how many problems it seemed to solve for them, they embraced it whole-heartedly. When they were done, it took 30 minutes to rebuild the assembly with a Ctrl-Q. SolidWorks now embraces Ctrl-Q, but it used to be something that only developers and overly-ambitious application engineers knew about. Anyway, I had a way of laying out the relationships between parts in an assembly, and I found 3 levels of circular relations, and hundreds of those Update markers at the bottom of the tree (that most people just hide and ignore because they don’t know what they are). After I pointed out the problem, the users and I agreed that the best answer to the problem was a layout sketch that included all of the shared data (mostly hole locations, and cavity/core parts). Reduced rebuild time to about 30 seconds, still had all of the needed relationships, just driven in a smarter way.

Let me tell you another little story. Once upon a time there was a company called PTC that invented a lot of what is now found on the mass-market CAD desktop. Pro/E had a dedicated following. They had a specific way to train users to make models. It seemed kind of complex and convoluted, but incredible things were possible. Eventually a new CAD company called SolidWorks made all of that complicated stuff very easy. But then they needed power, so they added power to the easy. The problem was that what they had simplified was mostly the method to get a short CAD rope around your metaphorical neck. They ran fast and loose with what PTC users thought of as “the” way to make models. Pro/E users scoffed at neophytes who were willing to just sketch on model faces, and willy-nilly make references to anything they could get their mouse on. There were few rules, and multiple ways to do just about anything, but users figured out eventually, through a lot of painful mistakes that you needed more discipline than the demo-jocks show. It turned out that the Pro/E users were really on to something, and SolidWorks users started thinking about best  practice issues, and things that might get you into uneditable situations, circular references, infinite rebuilds, and just generally bad practice.

Given that story, I’m a little ambivalent about how to direct this conversation. On one level, I know that in-context design does work, but on the other hand, I’ve blown it up and had to rework designs so many times that it’s a wonder I ever tried it again. It’s really rare when I work on something that doesn’t require at least some level of in-context work.

Just to be clear, when I say in-context, I mean any sort of link from a part file that connects to another part file. That may connect directly from part to part, or it may connect through an assembly. Strictly speaking, the in-context definition technically probably only includes connecting parts through an assembly, but I’m willing to let that requirement slide to include external references generally. So any time you have a “->” symbol.

Further, I’m not really trying to convince you that in-context is workable, or to tell you how to make it most workable, I’m really writing this as an observation. An observation that many people who use history-based software professionally on a daily basis are scared $#!+-less of in-context relations.

How many companies have an official requirement that users remove all “->” in-context relations and rebuild as fully-defined local data before releasing production data? So what I’m saying is that a lot of you people who bought into the glory of the history-based associative system refuse to use one of its most powerful functions, and one of its most compelling selling points and rightfully because it is frightening.

This is a story you hear many many times. It’s not just the irrational fear of a rogue CAD Admin, it’s a collective irrational fear. Or maybe its a fear that has grown out of a combination of real-world nightmares with poorly understood problems that can’t be fixed.

I want to propose 3 different solutions, ok, 4:

  1. Learn hero-level Crowd Control
    The truth is, with the correct backups, the correct file management, the correct training, in-context is totally manageable. In fact, a lot of situations that people think are not fixable are indeed fixable. You need some out-of-the box thinking, and some very constrained in-the-box thinking. To do it, you have to have and follow the correct best-practice rules, and be willing to pay the rebuild time penalties that are directly connected to in-context design. You have to train everyone to do it, and how to handle problems when they arise. Maybe later I’ll get into what these magic best-practice rules are, but if you aren’t doing this now, it’s unlikely you’ll be able to do it in the future. This is hero-level kind of stuff. Figuring it out requires a lot of hair and blood loss. Maintaining it requires a lot of service pack testing, training, and policing your CAD operators.
    Beyond that there is still the question if it’s worth it in the end. It’s an expensive philosophy. Yes, you can win the fight, but the race might be over by the time you show up. It’s an academic argument where you seem to lose regardless if you figure it out or not. Still, I guess it’s up to you if you want to go this route.
  2. Get Fancy.
    SolidWorks has added several functions that can help you limit the downside of in-context modeling. Stuff like the Freeze Bar, Lock/Break External Relations, the Parent/Child visualization thing. It helps mitigate the hair pulling, but in the end, it also minimizes access to the benefits of in-context. In the end, I’m not sure this is any better than just not creating the external relations in the first place.
  3. Simplify and Organize Your External References
    This method should just be called Resilient Modeling. There is a CAD-neutral way to plan your internal and external relations between parts and features that ensures that your parts are built to handle changes without blowing up. Yes, this method really works, regardless of which CAD program you use. It works with Synchronous Technology or with history-based methods. It is a common sense method that has been developed by a guy named Dick Gebhard. I highly encourage you to examine his method. At the very least, it will educate you about what’s going with your models. Really, check out the site.
  4. Kill Associativity, Go Synchronous
    Synchronous Technology is really about limiting parent/child relations and associativity. Its the associations between parts that really kill you with in-context. The Synchronous answer to in-context is to match the parts by editing them simultaneously (synchronously), but not create any external associations. Next time you need to make a change, you change the parts together. It’s hard to explain this in a sentence or a paragraph, just google Synchronous Assemblies, or read that chapter in the Synchronous for History-Based Users book.

Anyway, in-context relations are frightening, and for good reasons. SolidWorks has sent a lot of users down the “ease of use river” without understanding what that was going to cost them later. There are ways to deal with it, ranging from just trying harder, to using more “ease of use” bandaids, to just getting synchronous on it to eliminate the issues altogether. Resilient Modeling is a set of rules that will help you gain control over your models. It even works on top of Synchronous Technology to make direct edit and history-based design intent work together smoothly. I’m planning a more in-depth article on Resilient Modeling in conjunction with Mr. Gebhard. So stay tuned for that.

6 Replies to “Why are you so Afraid of In-Context Design?”

  1. Hi Matt.
    I’m CAD Engineer & Product Designer.

    And I use PowerSHAPE 10yr. I need advice which CAD software that I must learn. I learn SW 3 month (still beginner) but I left it cause it’s frustated when I got long history tree and I got error when edit it (for example: over constraint, or failed to rebuild feature), I must check one by one feature in history tree. Now I still learn NX (1 month) with my friends, and I feel it easier.

    I know SW has big user and it have more job opportunity.
    But I need software that not make me frustated when edit my model, or edit imported model (from other cad). I also need great surfacing capabilities.

    Have a nice day Matt.

  2. Matt: When we started Onshape, we made the decision to build on the things that work in our industry and to re-think some of the things that are clearly broken. To wit, we made a very fundamental decision: we made a declarative system, this would insure that models would always re-generate.

    More specifically, as it relates to in-context design, with Onshape you automatically have a local copy of the geometry so that other users cannot affect your model (e.g. simply by changing a components location or break the model by moving the location of the referenced file). With Onshape, a live link is created and preserved. If any changes are made to a referenced part/model, you are notified and can accept changes (if you like). The good news is that since we have infinite undo, so if you don’t want to accept the updates, you can simply hit undo.

    Bottom line: because we went back and re-thought the process, with Onshape you get the power of in-context design without any of the downside of file references.


    1. John, thanks for the comment. I’m interested in this approach. Is it mainly a product of the database, or are you copying data from one part to another in case they get separated? Can you elaborate on how that live link works? It has to be connected through the context of the assembly to account for relative position, it’s not just part-to-part… Sorry, so many questions.

  3. I try to stick with resiliency. Really hate having to do rework because of failing or crossed-up software, and over time have learned where to expect the problems to originate. Faces can share identities, and therefore get mixed up, renamed, or later misidentified by software. So keeping things as close to the core of the software’s modeling structure as possible seems to reduce such failure (planes, origins, and other basic geometry that tends not to change based on shifting foundations).

    With that said, I’ll often have (and leave in place) in-context relations of various kinds if I have resiliency built-in with them. I frequently model with a master type model that I’ll later break into pieces for detailing, simply because editing is really a breeze when done correctly. And I’ll ALWAYS keep the current revision of that master model within the assembly in which the derivative parts are found, lest the relations become easily lost/broken or reconnected to an old version of the master model.

  4. Amen, Matt. Amen. In-context design has powerful potential, just like atomic energy. If all goes well, great. If something goes wrong, you can have anything from a hidden issue that’s a ticking time bomb or a catastrophic meltdown in your design.

    A good portion of learning SolidWorks was on the fly for me, at an injection molding company. I never had any formal training, just learning from the previous designs. I didn’t know any better, so I used in-context design more and more with each new project until I realized I was getting some serious rebuild issues. Eventually I plotted out a standard dependency organization (molded part parent to cavities, cavities parent to plates, cavities and plates parents to the pins, etc.) to minimize those issues and maintain some of the automatic updating.

    When I changed jobs to engineering industrial equipment, it was strictly forbidden to have any external references. Lots of reused parts and assemblies between the various machines, and it could have been a big problem to have an inadvertent change due to in-context design. We’ve adopted Resilient Modeling to a degree, but we still have issues.

    It’s taken years of campaigning, but my colleagues and management are opening to the option of going synchronous. Hoping it will further reduce our issues and boost productivity.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: