SolidWorks 2011 Parts Bible - Matt Lombard [173]
SolidWorks users have traditionally been taught to build each feature linearly, on top of the one that came before. This is the genealogical equivalent of each generation having a single child, and then that child having a single child, and so on. The family tree, or FeatureManager, winds up looking like a long staircase, with each generation related only to the generation immediately before it. In the SolidWorks world, this creates long, linear, daisy-chained relationships between consecutive features. The main downside to this is that when a single feature fails, everything below it also fails.
It turns out that this is not a great idea, especially as the parts begin to get more complex. When each feature is dependent upon the one before it, all the features must be solved in a particular order, and if one feature fails, so do all the features that come after it. This also slows down the rebuilding process. Especially as we move into the age of parallel multi-threaded processing, a linear set of commands or features must be executed in order one after the other, and there is really little room for parallel processes.
The sophistication of the documentation provided with SolidWorks has not kept pace with the sophistication of either the software or its users, which I suppose is why you are reading this book rather than the help files provided with the software. The documentation is still based on the simple scenarios, and the advanced user is left to figure things out on his or her own.
As the software gets more sophisticated, the models created with the software can become more sophisticated, and the methods used to build the models must become more sophisticated, as well. It's time to leave the linear modeling approaches behind.
Rather than using a linear daisy-chain modeling scenario, it is better practice to base features on entities that are less likely to fail or change in such a way that dependent downstream features also fail. In earlier chapters, I have suggested that you make sketch relations to other sketches when possible instead of model edges for this very reason.
Taking that scenario one step further, what if a handful of sketch and plane features were used to centralize control of all of the rest of the features? What if every feature, to the extent possible, related back to these “skeleton” features? Features such as fillets, shell, and draft by design require selections from solid geometry, but other features, such as any feature created from sketches, could be made with only reference to those original skeleton sketches and planes. The parent/child relationship would look very different for a model made in this way. Instead of looking like a long staircase, this tree would look more like a tree that gets wide very quickly. There would be fewer “generations,” but each generation would be more populated. The main upshot of this is that if any feature fails, the dependent features that fail should be minimized.
The first thing to notice is that errors in features at the top of the tree do not cascade down the tree as they do in the “stairstep” model. Second, it is always much easier to find how a model is constructed, because all the reference geometry used to build it is set up in the first few features. This scenario also has the potential to make better use of multi-threaded processing because the logic is less linear and more parallel.
On the DVD
Examine the part on the DVD for Chapter 12 called Chapter 12 Sketleton.sldprt. Roll