Master Model Part 5: Best Practice and Horizontal Modeling

Delphi, the former GM division, developed a modeling method called Horizontal Modeling.Browse this PDF on the topic. It essentially says that features of a model should not have relations between them, everything should be controlled by a set of control data.

A couple of years ago, this topic went through a bit of a fad with SolidWorks users. I was one of I think 3 people who presented talks on Horizontal Modeling at SWW 09. My presentation was called “Skeletons in the Closet – Layout, Horizontal, and Wide Tree Modeling”. I unintentionally seemed to disprove the value of Horizontal Modeling for SolidWorks users, with my demonstration backfiring on me. I attended one other presentation on the topic, and it was dreadful. It consisted mainly of a lot of pedantic finger wagging, and at no point did it refer to anything I would have considered to be “Horizontal Modeling”. The topic was probably not done justice with these two presentations, and I do not recall the topic showing up again at SolidWorks World 2010.

There are things we can learn from this process, however contrived it winds up being. First, the reason I think it is called “horizontal” modeling is that the relationships are not “daisy chained” together. The image below shows how most of us have learned to use SolidWorks from day 1. All of the examples, tutorials, official training, demos, and everything told us to build one feature directly on the one before it. This gives you a cascading set of dependencies. So if one feature fails, everything below it fails.

If you were to evaluate this standard SolidWorks way of doing things on its own merits, I don’t think it would receive high marks. History based modeling is one thing, but exacerbating its weaknesses with built-in guarantee of failure makes this a pretty poor modeling technique. It is easy to use, but also extraordinarily prone to cascading failures.  On the other hand, in this Horizontal Modeling idea everything relates back to the control data, and there are no interdependencies. Make relations to the control sketches rather than to model edges or faces. When you have a feature fail, it tends to look more like the image below, and because there are no daisy chained interdependencies, there is no collateral damage.

I’ve written about this topic before, about two years ago, in a 4 part series of which the last part was never written. part1 part2 part3. The missing 4th part turned into that SolidWorks World presentation. As I remember, the denouement of the presentation was where I took a model that had been built as a Horizontal Model, and made a big change at the top of the tree that should have propagated perfectly through the rest of the features. But of course it didn’t. I think the change was to change the sketch plane of the very first feature. Everything was built from reference planes built from a layout sketch, so in theory, changing the sketch plane of the first feature’s sketch should have rotated the part 90 degrees.

The reason for the failure was something I have complained about frequently here. Planes flip normals sometimes. So what? you say. I’ve never heard of a plane normal anyway, so how can they hurt me?   The problem is that if you move a sketch from the XY to the ZY plane, and all other planes are built from the sketch, as some of the planes rotate, they will also flip. Does a 2D theoretical construct like a plane actually have two different sides? You betcha. That’s why if you sketch on a model face that is coincident to the Front plane and extrude, it goes away from the model by default, but if you sketch on the Front plane itself, the extrusion will go into the model. If you look at a model with planes shown and using default SolidWorks settings, one side of the plane is red, and the other is green. You don’t have any control over which side is which, and as as far as I know, there are no features that even reference plane side colors. But that isn’t to say it doesn’t matter.

Planes are not the only things that flip in SolidWorks when edited. Surface trims for several releases were  a huge flipping problem, and recently I’ve had problems with dimensions and blocks flipping when big changes were made. Mates are also well known to flip from time to time.

So if SolidWorks is fundamentally unsuited for extreme Horizontal Modeling, is there any role at all for Horizontal Modeling concepts in SolidWorks best practice?

Yes, I think there is. But you have to pull back what you expect it to do. Changes that you can drive through Horizontal Modeling will have to be limited to size and position changes, not orientation. Orientation is where SolidWorks gets really confused. But in theory, in a perfect CAD system, Horizontal modeling should be able to move or rotate the base sketch and the rest of the model should follow. Since you have to throw out the ability to change the orientation of the part through the base sketch when using SolidWorks, we might as well start using all three standard planes. If the main reasons for using HM technique would be for model stability, then using all of the standard planes should be safe enough. If it is for flexibility, then we are in trouble.

If we believe in the concept of making all features of a single part refer back to a master reference to increase the stability of a model through changes (and I do believe it is the best thing to do), what changes would we have to make to SolidWorks to make that scenario work? If we assume that SolidWorks chucks best practice as an underlying tenet that the software was built around, in favor of ease of use (I also believe this) then how would you have to alter the SW Philosophy to make it work properly with this technique?

Should software have best practice built right into it? Or is the fast-and-loose ease-of-use approach the best option?