Design is NOT a Linear Process

Those of you who have been working in design for more than a couple of years, and I’d assume that’s most of you, already know that design is not a linear process. You may start in one place, and jump around, and eventually come back to where you started. You may revisit the same area of the design multiple times. Of course this isn’t the most efficient way to work, but you don’t get your information in perfect order, or you may not see a solution for a problem until you’re half way through. Or the requirements change part way through the design process. We all know stuff happens. Lots of things happen, and people are imperfect, so you never go through a project (at least in my experience) straight from top to bottom on each part.

This implies, then that you have to jump around when you design, from one part to another. Maybe between subassemblies. You may have multiple people working on the same design with different ideas of how you should manage the CAD work.

Even within a part, the most important features on the part are often holes, which locate parts with respect to one another, and serve as hinge points for motion. In a history-based system you cannot add holes until you have material from which to cut.

If your modeler keeps track of features in a linear list, but your design process is, like most of us, a bit chaotic, then unless you are very meticulous, your feature tree winds up a bit chaotic. I know, I’ve been there.  A long list of features, then fillets or chamfers which you intend to be at the end of the tree, but then another wave of changes, and another wave of features, then more end features. Before you know it, you’ve got a feature tree like the last Lord of the Rings movie – with more endings than you can count.

When it comes down to it, your design itself is not linear. The design process isn’t linear either. So why should your CAD software try so hard to force a non-linear design in a linear history-based mold?

In the end, what is it that matters to you? The end product. Shape. Geometry. Dimensions. Relationships. History and order have nothing to do with your design.

One thing that always confused me when I was a dedicated history-only user was that sketches are not history-based, but when you assemble multiple sketches, you think of them as being in order. This just seemed pointless to me. Dealing with sketches all at once is one of the things you’ll find freeing in Solid Edge.

Also, in history-only modeling, your assemblies aren’t history-based, but certain assembly-dependent features within the parts are, but part-dependent features within the assembly aren’t. Whoa. So already, even the history-based modelers concede that thinking of features in an history-based order is not the best approach.

Take a look at Solid Edge with Synchronous Technology. It’s all about the end product. Solid Edge still has the history-based method, if you still choose to use that, but the great thing is that you can choose. You can choose history or Sync, or use them together. This mixed mode is what most people find most useful. Your main geometry is all synchronous, but the detail features like fillets, chamfers, thin wall, etc. go on as ordered features. This gives you the best of both worlds – ultimate editability with sync, and control over details with ordered.

The big advantage of synchronous is that once the geometry exists, it doesn’t matter the order in which it was put down, you just edit it as geometry. You don’t have to try to understand all of your features as a linear progression of dependencies – you just know that they exist and can be altered without violating the rules of history or parent/child.

And when you start working with this way of thinking of things in the assembly, everything becomes much easier to understand, much more powerful, and requiring much less “messing around” to create or destroy the parent/child dependencies that sometimes prevent you from moving forward in history-only schemes.

Synchronous Technology is the overlap of direct edit and “live rules” that drive the design intent according to what you’ve selected – so you can create or edit your design intent on the fly. You can change your design intent without an excavation project on your feature tree. I know you know what I’m talking about. We’ve all done it, and we’ve all cursed the red marks in the tree showing failed features. Wouldn’t it be great to work free from all of that?