Part II: Building Intelligence into Your Parts
The term Skeleton in Pro/ENGINEER has a different significance than the way it is being used here.
SolidWorks does not have any feature or function named “skeleton.” The term is just being used to
refer to a set of sketches, planes, axes, and reference points used to lay out the major faces and fea-
tures of a part.The SolidWorks Help files, tutorials, and training curricula have encouraged users in some respects to
take a “fast and loose” approach to modeling, which lends itself best to simple models that are not
changed frequently. Little thought is given to the structure of the part; the focus is on the final shape.
The main consideration seems to be the simplest way to do something, or how it could be done rather
than how it should be done. This mentality fit well with the initial several releases of the SolidWorks
software, which at that time was marketed as being simple and fast.The software has progressed immensely since those days. It is now entirely plausible to create complex
castings and plastic parts with many hundreds of features, weaving in and out of surface and solid tech-
niques, multi-bodies, and external references. This is a far cry from the typical tutorial or training part,
which still tend to have fewer than 15 features, half of which may be fillets. With the simpler parts, you
hardly give a thought to parent/child relationships, rebuild times, or the consequences of making
changes that cause a feature to fail, because the whole part can be rebuilt from scratch in ten minutes
anyway.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.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 pro-
cess. Especially as we move into the age of parallel multi-threaded processing, a linear set of com-
mands 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 software has not kept pace with the
sophistication of the software itself, 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 sophis-
ticated, 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 ear-
lier chapters, I have suggested that you make sketch relations to other sketches when possible instead
of model edges for this very reason.Using the skeleton or wide tree approach