Why I Changed Camps: Part 2

Part 2 is all about the role that the technology played in my switch. Going from a skeptic to a supporter seems like a big jump, but if I explain this right, it will be obvious. The functional differences to me are compelling, especially for the kind of work that the largest group of mid-range CAD users do – machine design, which uses primarily prismatic shapes.

I know there are those of you who still argue that [fill in the blank] is just the best out there, with all the gusto of an Apple/Android catfight. But the statement is usually made without much if any knowledge of the things you are comparing, and rarely with any supporting information. Somehow even CAD programs develop a religious or sports team type of fanaticism such that people react emotionally rather than rationally to claims involving the brand you support.

But the religious devotion has a duality to it. When you’re talking to a Solid Edge supporter, you claim you couldn’t do your job without history-based tools. But when you talk to the guy in the cube behind you, you’re inventing new four-letter words to describe your feelings about rebuild times, rebuild errors, navigating parent/child relationships in the feature tree, and so forth.

“Design intent!” someone shouts out. “Parametrics!!” Yes, yes, pipe down. I hear you. We’ve got all of that covered. People, even people in the media who should know better have posed this as a “parametric vs direct” comparison. But that’s wrong. Solid Edge w/ST does parametrics. We do design intent. We can automate parts, drive part sizes with tables, write equations. Even on imported parts. Yes, even on imported parts.

Solid Edge enables two methods for working: Ordered (which is what we call traditional history-based modeling) and Synchronous (which is direct editing plus a lot of software-based intelligence). Solid Edge has been a history-based modeler since the beginning. This negates at least the “we want history-based CAD” argument. Solid Edge has both. You don’t have to make a choice. You can use either, or both.

What exactly is Synchronous Technology? Synchronous Technology is several things working together:

• direct edit plus
• Steering Wheel (graphical interface controller)
• Live Rules (automatic, controllable, geometric relations)
• Dimensions directly on model
• Face relations (placed manually, persistent or temporary)
• Procedural Features (features that retain some parameters, like pattern, thin wall, hole, fillet)
• Geometry/feature recognition software

Using these tools together enables simple direct edit to be so much more than just pushing and pulling faces around.

In history-based software, you have to use a crystal ball to make a good model that reacts to changes well. You have to look into the future to create design intent, and into the past to use it.

In history-based software, the intelligence is in the data. There is a huge difference in the editability between a “well-modeled part” and a “poorly-modeled part”. How you put the features together determines how they can be edited. This is not true for Synchronous Technology. When using Solid Edge, the intelligence is in the software, and the source of the data doesn’t matter. So your aunt Minabelle might have modeled the part with no knowledge of best practice, or it might be an import from a history-based CAD package, or a native Solid Edge part, or even from a future version of Solid Edge. As long as the parts have the same topology, they will react to editing exactly the same way.

In history-based software, you have to use a crystal ball to make a good model that reacts to changes well. You have to be able to see into the future to create design intent, and into the past to use it. That’s no way to treat your engineering data.

History-based modeling has a lot of shortcomings. I’ve mentioned before that Synchronous helps you avoid those weaknesses. Let’s outline some of the weaknesses, just so you don’t forget.

First, history-based modeling was invented to allow slow computers to solve complex models in pieces, because the computers of 30, 20, even 10 years ago were not fast enough to solve parts and assemblies all at once. So it’s in part just a crutch.

Second, it’s not very intuitive. Remember learning it? It took me a while for the light to go on. There is no real good reason why the features on a part should be associated with some sort of order. You might make sheet metal bends in a particular order, or perform machining operations in an order, but people designing the part aren’t usually the ones specifying the order in which features are machined. And what about castings and plastic parts? There is no logical way or reason to order features. Feature order is a modeling abstraction that has no real world analog

Third, rebuild times. On complex models, rebuild times can become seriously tiresome. Why does the whole part have to rebuild if you only change one of the later features?  Assemblies? In-context assemblies? Ouch. If you make big assemblies or very complex individual parts, you know exactly what I’m talking about. How many sets of best practice rules have you read that recommend you limit or completely avoid in-context design? In-context is sold as one of the strengths of history-based tools, but it is expensive when it comes to rebuild, computer resource hogging, and crash bugs.

Fourth, the feature tree. The list of features is supposed to be history-based, but it isn’t even truly chronological. It’s a mess when you consider sketches and parent/child relations. What about the feature order of a feature with multiple sketches? It’s nearly indecipherable, and unmanageable. Have you ever seen Ed Eaton’s “Trees of Blood” presentation? Read that and then seriously tell me you have a good grasp of parent/child relations.

Fifth, design intent. When building history-based parts, you think you are building the design intent into the order of the features. But you know as well as I do that the design intent itself is what you have to change more often than not. Navigating parent/child relations especially in parts with shared sketches or multiple sketch features is tedious. With Synchronous Technology, you decide what the design intent is at the time of the change, not at the time you build it. This means you never have to decipher parent/child limitations.

When you use sketch relations and dimensions to establish how the part reacts to change, you’ve got controls all over the place. In this sketch, that plane, this extrusion, etc. In Synchronous, you just put your relations directly on the final model. Its soooo much simpler and straight forward.

The bottom line is that if you’re making prismatic parts and you’re not using Synchronous Technology, you’re wasting your time. And yes, that comes from the guy who wrote the SolidWorks Bible.

Now that we’ve reminded ourselves of the weaknesses of history-based modeling, let’s talk about the strengths of history-free Synchronous Technology.

First, we’ve already discussed imported data works like native in Solid Edge. This is because the intelligence is not in the part like in history-based software, the smarts is in the software, so the model only has to be geometrically correct. This eliminates most of the “future version” problem with CAD. If you have BrandX2012, and your buddy has data in BrandX2014, you can’t read his files, or if you do, you have to take imported models, which lose all of their features and history (intelligence). But with Solid Edge, even an imported part can have its existing geometry converted into procedural features like patterns, holes, and so on.

Second, we are driving the model directly with dimensions directly on the model geometry. It’s so simple when you think about it. Why go through a layer of abstraction in the “feature” definition or a sketch, when what you really want to drive is the model itself. You can also create relationships between faces that the model remembers when you make changes. These usually aren’t necessary because it “reads” the relationships inherent in the geometry. Faces that are perpendicular will remain perpendicular through changes unless you want to disable that. Dealing with the geometry directly as geometry is so much easier to think about. No abstract concept, no need to think like a programmer, just work with geometry.

Third, rebuild times are a thing of the past. While some of the synchronous functions can have a slight delay associated with them, it is nothing like the rebuild time that is accumulated for each feature you add. Some history-based software claims it can make direct”like” edits using the Move Face command. But this is a cheap imitation. It adds a feature and rebuild time to the tree, and Move Face fails if adjacent tangent faces are not moved at the same time.

Fourth, Synchronous Technology works even in assemblies. So you can select several faces from different parts and move them all at the same time. You can also move faces from one part up to the face from another part. You can do this without creating an in-context relation, or an external dependency. So you get all the advantages of in-context top-down modeling without any of the frightening side effects. This is one of my favorite advantages of Synchronous Technology.

Fifth, Synchronous Technology enables you to do amazing things with fillets. Even with imported models with fillets, which is a huge road block for history-based models. You can select several fillets and change them together, then pick one and change it separately. You can easily remove fillets from a model, yes, even an imported model. One of my favorite things to do with fillets is to apply them as Ordered features. So the rest of the model is a Synchronous block, but the fillets are applied as history-based features. This helps avoid one limitation of direct modeling when the topology is changed by a face being consumed, that it is difficult to add topology back once it has been removed.

This is getting very long, but what I want to make sure you get from this is that history-based modeling is unnecessarily complex for most parts you model. Modern computers can handle direct edit methods in a way that makes the method more practical than history-based methods. Mixing modes is possible and desirable in certain situations. You can give up the broken relations and dimensions that parent/child schemes cause during changes to a history-based model. I don’t want to disturb anyone’s religious devotion, but if you would take the time to honestly evaluate the amount of headache caused by your history-modeler, and the ease with which Solid Edge can handle those same situations, I think you may find a whole new set of friends.