Parent Chile Relations

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

Reply to
umasemonoff
Loading thread data ...

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

Reply to
mjlombard

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.

Reply to
FlowerPot

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.

snipped-for-privacy@hotmail.com wrote:

Reply to
TOP

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

Reply to
Mark Mossberg

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

Reply to
Kman

Pot = A-hole

Reply to
ms

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"

Reply to
Jerry Steiger

I suggest we all just add FlowerPot to our "ignore" lists.

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

John H

Reply to
John H

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.

Reply to
Lee Bazalgette - factorydesign

"Lee Bazalgette - factorydesign" wrote in message news: snipped-for-privacy@despina.uk.clara.net...

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.

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

Reply to
Jerry Steiger

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

Reply to
ed1701

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:

Reply to
Bo

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:

Reply to
Bo

I like the "chicken pox" analogy....gave me a smile!

John H

Reply to
John H

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.

Reply to
mjlombard

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

Reply to
ed1701

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.