Why Is one of the Biggest Selling Points of Feature-Based CAD also the Most Feared?

During the years that I’ve worked with CAD, there was one thing that I found that just terrified a lot of users and even CAD managers: In-context design. It’s true that people fear what they don’t understand, and this falls into that category to some extent. The real root of the problem, though, is that people just don’t trust it. And this is one case in which understanding it may make you trust it even less. Like what’s really in a hot dog? It may or may not be appetizing as it is, but knowing what’s in it will certainly not make you feel better about it.

Things happen with in-context models that users sometimes can’t explain, and that situation leads to mistrust. If you have been through a CAD demo in the last 25 years or so, you’ve probably seen the value of in-context design shown in a rather clinical way. Nothing ever goes wrong, and it’s all perfect. The relationships are simple and easy to follow.

[pullquote]The best you can hope for in some cases is to intentionally break the references. The external references still remain, they just don’t work. And as hideous as this sounds, this may be the way your software is designed to work.[/pullquote]

So why does it become “best practice” at so many companies to remove all of the in-context references at the end of a project? In-context is a huge selling point, so why would you strip it out? Plus actually stripping all external references can be difficult or impossible. The best you can hope for in some cases is to intentionally break the references. The external references still remain, they just don’t work. (Yes, as hideous as it sounds, that’s intentional behavior!;o))

It’s probably fair to say that the source of the mistrust is more often than not related to file management. A name changes. A folder moves. An assembly gets renamed. The software loses track of where the relationships are supposed to be coming from. But users don’t really want excuses. No one really cares “why” when data gets corrupted. Users just want software they can count on. If the software makes it easy to do the wrong thing, then maybe you have the wrong software. If one of the main selling points of the software actually endangers the stability of your data and works against best practice, then maybe it’s time to re-evaluate your choices.

[pullquote]If the software makes it easy to do the wrong thing, then maybe you have the wrong software.[/pullquote]

Just to define terms, In-context design is synonymous with top-down design. It happens when you’re in the assembly, and make some sort of relationship between parts. We usually look at it like geometry in one part is driven by geometry in another part so that a change in one part creates a change in the other part at the assembly level. This means that in order for the whole in-context change to take place, you have to have at least three files open: the driving part, the driven part, and the assembly where the relationship was created.

The assembly has to keep track of:

• Which parts are related, and which occurrences (instances)
• Which entities within the parts are related and how they are related
• The name(s) of the assembly(ies) in which the relationships exist

Real products work this way, with relationships between parts, so real CAD should too, right? Relationships might be:

• Face A from Part 1 has some relationship to Face B in Part 2 (coincident, at a distance, etc.)
• Sketch A in Part 1 has relationships to edges in Part 2

But then things can get really complicated. What happens when:

• You have family of parts in one part (sw: configurations) that is driving or driven by another part?
• You have driving features in both directions (Part 1 drives features in Part 2, but then other features in Part 2 drive features in Part 1)?
• You have in-context features driven by assembly features, like patterns?

The fact is that there are just a lot of ways that a reasonably educated designer can get caught in one of a number of logical traps that might cause all sorts of unpredictable stuff to happen to your data. Infinite rebuild loops. One part changes every time it is rebuilt. Error messages on the links between parts. Copying or moving files makes a mess of the internal housekeeping for inter-part links.

And then the unimaginable happens – you have to have a designer work on someone else’s in-context assembly. Suddenly it becomes a research project to understand all of the relationships. The software doesn’t have a simple way of laying it all out for you. If there are problems or circular relationships, you have to discover that for yourself, and the path isn’t easy.

So now each and every one of your designers has to be a forensics expert when it comes to troubleshooting in-context links between parts. It’s no wonder that many a CAD manager just throws up his or her hands in despair, and proclaims that all links must be removed or broken if removing isn’t possible.

Beyond the in-context nightmare scenarios, let’s talk about design intent. Design intent is that intelligence that you’ve built into a model that allows it to react to change in predictable ways. We all know that the dirty reality about design intent is that sometimes your intent changes. When this happens, ideally you should reconstruct your model to reflect the new way you want it to react to change. Truthfully, sometimes we want models to do conflicting things, but we can’t build in complex decision making processes. And honestly, rebuilding a model to change the design intent, especially when the design intent is on the assembly level (in-context), making changes is simply not practical.

So what happens? A lot of people just ignore it and workaround the inconvenience. Some people just break all the relationships and go old-school. I’ve seen people export/re-import the model and continue from there. All of these are bad ideas, but the software doesn’t really leave you other choices unless you are some sort of relationship-nixing wizard.

You tell me; how do you handle this situation?