Family Table Basics

[meline]

I've come across some basic tips forFamily Table structuringthat I'm looking to understand better. The tip is to "create an instance for each model required e.g. one for casting, one for machining: avoid creating one instance (machining) and then using the generic as the casting instance". This is an approach that I've also seen an experienced ProE modeler use as well.

But can anyone clarify this a bit better for me? I guess my problem is I like to look at thecasting being the top level, or generic, and any of the various machinings then made as instances from this.

If it has to do with initial design intent then I suppose I can see the rational for that.....

Thanks

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[JoshuaHouser]

Hi Michael,
For castings I'm a big proponent of using inheritance features. If you need more information on it, let me know, or you can search the forums for my PTCUser presentation on "Merging away from Family Tables".

[JoshuaHouser]

Hi Michael, here is there presentation on Inheritance features I mentioned. Feel free to let me know if you have questions.

Joshua Houser| Pelco by Schneider Electric |Buildings & Business| United States| MCAD Tools Administrator
Phone: +559-292-1981 ext. 3490| Toll Free: +800-289-9100 ext. 3490&nbs

[lwh]

I think the point is to never use the generic in instances of e.g. an assembly.

The idea behind it is to keep the generic for checking or trying things, thus being able to hide/suppress features without affecting the places where the object is used (drawing or assemblies), even if the changes are saved.

Besides that, You have a clear relationship between instances of hierarchical family tables.

[jellis]

Hello Michael.

It's not a crime to use the generic model in an assembly although the rule-of-thumb has been to not use the generic and use only instances. I think this rule was originated with the intial use of Family Tables. Typically they were models like Hex Hd Cap Screws. The genericwas constructed in a manner that permitted any instance creation with dimensional edits of the features. With a generic/instance like this you would only use instances in next level assemblies. Family table use has grown and sometimes they are over-used.

For us, our sheetmetal models contain a Flat1 instance. We contemplated the "known rule" but asked what benefit are we getting? We didn't want to fill up our data system with anymore instances than we really needed. It is a known fact that generics/instances can be a source of frustration in data managing systems. The result, we use the sheetmetal generic in next level assemblies.

As Joshua replied, Inheritance models are a very goodoption to consider. Find the solution that works best for your situation and be consistant with it's use.

Regards, Jim

[brianlynn]

I believe the reasoning behind this is that your want to show all the
features in the generic, if you can, so that you can work with any feature
in the generic. I have seen cases where this is not possible, but if you
do it one way with the models showing all the features works with, then
you will want to be consistent to make it easier for less advanced users.

An example I can think of is an sheet metal part we create has a drawn
hole in a few instances no holes in others and then in the last few have
just a cut hole. We would not be able to show both the cut hole and the
drawn hole in the same instance and those features are suppressed in the
ones without holes at all. So the generic actually has the drawn hole and
the cut hole in different locations from the actual instances so they can
be seen in the generic, and so we do not want to use the generic in the
drawings or in the assemblies.

Hope that helps explain why some of us make sure to consistently not use
the generic as an instance representative.

Brian S. Lynn
Technical Coordinator, Product Engineering

[kimndave9]

The beauty of the family table is that if the generic is used and later
becomes undesirable in that use, one can easily substitute a suitable
instance for it.

Dave S.

[merrill.rosenow]

I may be missing something, however it seems like we are making this more difficult than it actually is. In my company, we make generics of parts. We then use those generic parts to make generic assemblies. Let us take the example above where some of the instances have a drawn hole, no hole or cut holes. Let us say that for each type of part you will attach a different fastening component. All you would have to do is turn off the fasteners for the instances where they are not required. From a data management prospective, my group has not had difficulty dealing with this.

No, you will not be able to show all of the features if they exist over top of each other, but there is another way around that too. In such cases, we put instances which do a good job showing each different type of feature (drawn hole, no hole or cut hole) on sheets and create a short description. This allows you to clearly show the differences between each type while giving realistic dimensions if that is also required. Note: in the case where features were moved to show what they are, you would not be able to accurately dimension the instance since it has been "faked."