Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Parent Chile Relations

0 views
Skip to first unread message

umase...@hotmail.com

unread,
Nov 11, 2006, 7:33:34 PM11/11/06
to
Will someone who is knowledgeable on the subject of Parent Child
Relations, give me a short synopsis on the actual function of it all.
If the subject requires a lengthy explanation , and too involved for
this forum, I will understand if there is little response. If the
basic principle were brushed on, it would be more than appreciated.

I am thanking you , in advance
Uma Semonoff

mjlo...@verizon.net

unread,
Nov 11, 2006, 9:04:07 PM11/11/06
to
Parent child relations can seem a little misleading sometimes, the way
things are represented in the FeatureManager. First, I'm assuming that
you are talking about parent child relations inside a part, not between
parts. It is easiest to understand if you look at it as you build a
part rather than trying to look at a part that is already built and
figure out the relationships.

As you build a part, any time you build a new feature by using other
geometry, you have created a parent /child relationship. The new
feature is dependent on the pre-existing feature, so the new feature is
the child. The only items in the FeatureManager which are not children
of something else are the three basic planes and the origin. Generally
speaking (how many disclaimers do I need to avoid getting flamed),
everything else is dependent on the 3 planes and origin.

The confusing part is that you usually think of Parents as coming
before Children, but in SolidWorks, the way features and sketches are
listed, the feature is a child of the sketch, but the feature is listed
before the sketch. The FeatureManager is not a linear "family tree",
rather it assumes that 3D features are more important than 2D sketches,
so it makes access to the features easier by making them visible.

You can investigate the parent/child relationships in a model by right
clicking on a feature and selecting Parent/Child from the menu. This
lists the parents and the children of the selected feature.

Generally, if you delete or suppress a feature that other features are
dependent on (the feature has children), there will be some effect on
the children, such as they may get deleted, or the sketch may go
dangling or things like that. Examples of things that cause parent
child relations are:

- using the face of a feature to sketch on
- using convert entities on the edges of a feature
- using an extrude "up to" end condition
- dimensioning to the edge of a feature
- dimensioning to the temporary axis created from a cylindrical face.
- any time a face, edge, vertex, etc is used in the definition of a
feature or sketch

The good part of parent child relations is that when you change the
parent, the child updates to match the original instructions with the
new geometry.

The bad part of parent child relations is that when you change the
parent, the child updates to match the original instructions with the
new geometry.

Other levels of parent/child relations include topics like in-context
references (relations between parts in an assembly), one part being
inserted into or otherwise created from another part, also assembly
documents are dependent on part documents, and drawing documents are
dependent on assemblies and parts.

It's not a simple topic, and not something that you can really grasp
adequately without sitting down and using it a bit.There are many
advantages and disadvantages of "parametric history based modeling",
which cannot be approached carelessly. Everyone has a story about a
model that they completely messed up when getting the hang of the
concept.

Many, maybe most people model things in a linear, sequential way such
that there are many "generations" of dependencies, so like that book in
the Bible where "...and abraham begat isaac and isaac begat jacob and
jacob begat esau and esau begat..." that sort of "daisy chain" effect.
This can have a bad effect on performance because all features must
rebuild in sequence. To go with the family tree analogy, this makes for
a very tall, skinny family tree, with few branches.

The alternative, mentioned in a previous thread, is to build a
structure based on a minimum number of sketches (two or three which are
only dependent on the basic planes and origin) to represent locations
and sizes of features, and a set of reference geometry (planes and
axes) which are either dependent on the sketches or basic planes or
both. This structure is referred to as the skeleton. Any sketch after
the skeleton is sketched on one of these planes, and uses the sketches
or basic planes for location and size references. In this scheme, you
avoid making parent/child relations to faces, edges or vertices of
solid geometry. Because everything is related directly back to the
First Generation (basic planes and origin), Second Generation (skeleton
sketches) or Third Generation (planes made from skeleton sketches), the
"family tree" of this method is short and wide.

Tall and Skinny or Short and Wide? The problem with a Tall and Skinny
tree is that a problem in one feature is likely to cascade all the way
to the end. In this model, errors propagate down the tree, (the tree
being built from the top to the bottom) because there is a very high
degree of interdependency. The Short and Wide method centralizes
control in the skeleton features, and minimizes interdependency, so
errors are contained more easily.In this method, solid features do not
show up as the parent of any other feature. This can rebuild faster
because the order of operations is not as important.

Anyway, not many people model short and wide because it requires more
discipline. I generally use a hybrid approach between the two methods,
and usually wish I were more disciplined.

matt

FlowerPot

unread,
Nov 12, 2006, 8:46:27 AM11/12/06
to
Damn, another major blo-hard. And this one is a SW usage cop too! Must
be nice to just sit in judgement all day saying thou shalt do this and
thou shalt not do that. We've got enough preachers here to file for tax
exempt status! Enough judges to make a Court TV show. Enough
self-important blo-hards to go on CNN.

Where do you guys dig up all these stuffed shirts?!?!

Daisy.

--
Posted via a free Usenet account from http://www.teranews.com

TOP

unread,
Nov 12, 2006, 9:10:29 AM11/12/06
to
Parent / Child relationships in SW refers to the fact that each feature
in the SW feature tree is based upon one or more pre-existing features.
Not all of the features in the feature tree, however, provide geometry
data. For example the very first feature in the feature tree of a part
is the document itself which contains information of a global nature
pertaining to the documnent. The second feature, Annotations pertains
to the display of annotations, then there is material, lighting, etc.
Then there is a second group of folders pertaining to the management of
bodies, both solid and surface. These are lists that are affected by
the current history/time state of the model and reflect the state of
existing geometry on which subsequent geometry can be built. Finally we
get to features that define the starting point for all subsequent
geometry. There are four, three planes and an origin. Interestingly the
origin is tied to the front or first plane, but the other two planes
exist independently. These features which will always exist in a part
or assembly provide the basis on which to relate all subsequent
features. The preceding features are always there and cannot be deleted
(except the document itself of course).

When the first user created feature is made it must be related to the
origin and one or more of the three planes. For example if a planar
sketch is made it must itself lie on one of the front, top or right
planes. The curves in the sketch must be related to the origin or to
the other two planes by relations or to the dimension relation. This
sketch might then provide the basis for an extruded feature or a
revolved feature. If an extruded feature, then the direction of
extrusion will be perpendicular to the plane that the sketch was made
in. The sketch and the plane would then be parents of the extrusion. If
the sketch were to be destroyed so would the extrusion because SW
recalculates all the steps to the extrusion each time the model is
regenerated. When the definition of the extrusion is gone, so is the
extrusion. This is called history based modeling and is similar to the
concept of putting a framework in a building. As we saw on 9/11 when
the internal framework of a building is removed, so all that is based
upon it will be removed pretty much in the order it was originally
constructed. A parent then is a feature upon which features are built
and a child is a feature depending on pre-existing features. The word
time is used in this context to refer to a stage in the building
process, i.e., you cannot have the extrusion prior to the sketch being
made because the sketch is the parent of the extrusion feature.

A feature can be based on more than one pre-existing features. A
feature does not have to relate back to the original planes and origin
through all pre-existing features. There are in fact parallels to
creating a SW model and programming. Even the term spaghetti code from
programming has a parellel in SW Parent Child relations. Unfortunately
the one program that can really illustrate this point, AssyGator, is no
longer available.

Matt has given a synopsis of the tools for managing Parent/Chlid
relationships so I won't belabor that point.

Mark Mossberg

unread,
Nov 12, 2006, 3:28:52 PM11/12/06
to
Pot,

Do you actually use Solidworks ? or are you just an A-hole trying to stir up
shit.

Matt's been using it for about a decade, so have I. The information he
supplied was correct. It may have been a bit lengthy, for a newbie (or
incomprehensible for idiots like you), but it was right on.

From googling your posts and responses, you haven't been around long. As to
the content, YOU come off as a self rightous, arrogant, judgemental, BLOW
HARD, in every one I read.

You need to learn some manners lady.


Mark


"FlowerPot" <da...@flowerpot.org> wrote in message
news:455718de$0$21152$8826...@free.teranews.com...

Kman

unread,
Nov 12, 2006, 5:10:52 PM11/12/06
to
The information was informative and had something in it for newbie's and
experienced users alike. I don't Plunk many on this newsgroup because I am
of Ed's opinion that even negative posts can be informative. However, your
replies have nothing to do with SolidWorks. The expertise you have
demonstrated thus far is directed at insulting people who share their
knowledge and experience without obligation. What is the purpose of your
contempt?

Kman


"FlowerPot" <da...@flowerpot.org> wrote in message
news:455718de$0$21152$8826...@free.teranews.com...

ms

unread,
Nov 12, 2006, 11:15:14 PM11/12/06
to
"FlowerPot" <da...@flowerpot.org> wrote in message
news:455718de$0$21152$8826...@free.teranews.com...
Pot = A-hole


Jerry Steiger

unread,
Nov 13, 2006, 3:37:38 PM11/13/06
to
"FlowerPot" <da...@flowerpot.org> wrote in message
news:455718de$0$21152$8826...@free.teranews.com...
> Damn, another major blo-hard. And this one is a SW usage cop too! Must be
> nice to just sit in judgement all day saying thou shalt do this and thou
> shalt not do that. We've got enough preachers here to file for tax exempt
> status! Enough judges to make a Court TV show. Enough self-important
> blo-hards to go on CNN.
>
> Where do you guys dig up all these stuffed shirts?!?!


Matt tried to answer the question. I thought he did a good job, as did Paul.
How did your response help the original poster? How did your response help
anyone?

When I was a kid, I was taught "if you don't have something good to say
about someone, don't say anything at all." I have trouble sticking to it,
but it's generally pretty good advice. So far I'm having a really hard time
saying anything at all about you. That's not a problem with Matt or Paul.

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"


John H

unread,
Nov 14, 2006, 6:06:15 AM11/14/06
to
I suggest we all just add FlowerPot to our "ignore" lists.

By the way, are you getting the message yet, FlowerPot?

John H


Lee Bazalgette - factorydesign

unread,
Nov 14, 2006, 10:15:24 AM11/14/06
to
nice explanation - phew, pretty concise too i'd say, considering what an
enormous subject this is.

I'd add a bit about how things appear in the tree: not only is the sketch
shown under the extrude (example) so the 'parent' is under the 'child', but
these days you can completely muddle the tree order by sharing sketches for
multiple items, or drawing a sketch (sketch 1) then modelling a load of
other stuff not using sketch 1 (sketch 1 remains at top of the tree) and
then using sketch 1, suddleny sketch one is at the bottom of the tree! This
isn't best practise by any means, but it is POSSIBLE, so it does happen!

The 'wide' tree is definatly better for stability, but the nature of design
means that it's rarely possible to model everything based on a few initial
sketches and planes - the trouble with parametric modeling is that you can
dragged down a direction where a simple change can become a days work....

uh oh, I'm jibbering, better stop now.


<mjlo...@verizon.net> wrote in message
news:1163297047....@h54g2000cwb.googlegroups.com...

Jerry Steiger

unread,
Nov 14, 2006, 6:13:58 PM11/14/06
to
"Lee Bazalgette - factorydesign" <l...@SPAMfactorydesign.co.uk> wrote in
message news:116351722...@despina.uk.clara.net...

> I'd add a bit about how things appear in the tree: not only is the sketch
> shown under the extrude (example) so the 'parent' is under the 'child',
> but these days you can completely muddle the tree order by sharing
> sketches for multiple items, or drawing a sketch (sketch 1) then modelling
> a load of other stuff not using sketch 1 (sketch 1 remains at top of the
> tree) and then using sketch 1, suddleny sketch one is at the bottom of the
> tree! This isn't best practise by any means, but it is POSSIBLE, so it
> does happen!


What really makes this last example a pain in the posterior is when you go
to edit sketch 1 after the above changes and the stuff you modeled is not
available for reference in your sketch! You've got to delete the feature you
built from Sketch 1, move it to the end of the list, and then add your
feature again to allow it to reference the "later" features.

ed1...@juno.com

unread,
Nov 14, 2006, 11:37:01 PM11/14/06
to

>
> What really makes this last example a pain in the posterior is when you go
> to edit sketch 1 after the above changes and the stuff you modeled is not
> available for reference in your sketch! You've got to delete the feature you
> built from Sketch 1, move it to the end of the list, and then add your
> feature again to allow it to reference the "later" features.

Yes. Uggh.
I often am tempted to use shared sketches or contour selection , but
it just isn't worth it (except when disciplined - matts 'wide feature
approach').

My main layout sketches, I leave at the top of the tree, then start new
sketches and convert the relevent entities into new sketches. If I
share a sketch (and I do like to share) its only when I am pretty
certain that it won't f*** me in the a** later (pardon my fr***).

Yes, there are tricks to moving absorbed features up the tree where you
want them to be (what I call the feature ladder - I should really get
around to posting that sometime), but even those tricks are spotty
depending on the tree structure.

When, oh when, will we see Pauls flat feature tree? Oh When?
Ed

Bo

unread,
Nov 15, 2006, 9:33:29 AM11/15/06
to
I vote with Matt for WIDE Trees when parts are complex. It keeps me
from pulling my hair out.

Since I design mostly plastic parts, and they can get complex easily,
I've sometimes wound up creating a model where it is just simply
impossible to change a dimension or two to optimize the part or
versions without getting the chicken pox up and down the tree.

Starting over meant creating planes off the primary planes and origin,
and controlling ALL major feature starting points from those initial
planes (& planes at angles from them & the origin) & axes derived from
those plane positions, which help me a lot Dependencies from plane to
plane are solid (If I can use that term; 'stable' if I can't).

Once I redesigned my parts with a W I D E tree setup (as it has been
called), I can now go in and alter an initial plane position or
positions to get a new 'size' part, and everything behaves like James
Dean's hair with Pomade.

Bo

Bo

unread,
Nov 15, 2006, 9:33:38 AM11/15/06
to
I vote with Matt for WIDE Trees when parts are complex. It keeps me
from pulling my hair out.

Since I design mostly plastic parts, and they can get complex easily,
I've sometimes wound up creating a model where it is just simply
impossible to change a dimension or two to optimize the part or
versions without getting the chicken pox up and down the tree.

Starting over meant creating planes off the primary planes and origin,
and controlling ALL major feature starting points from those initial
planes (& planes at angles from them & the origin) & axes derived from
those plane positions, which help me a lot Dependencies from plane to
plane are solid (If I can use that term; 'stable' if I can't).

Once I redesigned my parts with a W I D E tree setup (as it has been
called), I can now go in and alter an initial plane position or
positions to get a new 'size' part, and everything behaves like James
Dean's hair with Pomade.

Bo

Lee Bazalgette - factorydesign wrote:

John H

unread,
Nov 16, 2006, 3:46:32 AM11/16/06
to
I like the "chicken pox" analogy....gave me a smile!

John H


mjlo...@verizon.net

unread,
Nov 26, 2006, 11:08:29 AM11/26/06
to

On Nov 14, 11:37 pm, ed1...@juno.com wrote:
> Yes. Uggh.
> I often am tempted to use shared sketches or contour selection , but
> it just isn't worth it

I agree about contour selection, its just too flaky through sketch
changes, but if you have anything specific about shared sketches, I'd
like to hear it. I find them to be far more reliable than converted
entities or anything else. I think when contour selection first came
out, the resellers showed shared sketches as being a function of
contour selection, and it can be, but shared sketches can also be used
with the normal method of sketching.

ed1...@juno.com

unread,
Nov 27, 2006, 11:44:53 AM11/27/06
to

> but if you have anything specific about shared sketches, I'd
> like to hear it.

I have found them to be quite stable - I just have issues with shared
sketches in the way they get absorbed, making reordering difficult.

0 new messages