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.