Family Table fight, need help!

From my experience the only issue with Family Tablesis unqualified users.

SUMMARY POST:

Hey,

We are having a bit of a tussle at my company over family table usage, and I need some information to back me up. I am trying to make the following arguments:

- Family table generics should only be used to define the instances.

- Wild card values should not be used in the family table.

The people I am discussing this with want to know why! Why shouldn’t I use a generic in an assembly? What harm does it cause?

I will have to admit I couldn’t come up with a really great reason and know there are, so help me out with some great reasons or examples. What say you?

-marc

CAD / PLM Systems Manager

TriMark Corporation

The biggest difference is if you are using a PDM system like PDMLink or Intralink. If you are, then you are correct.

We frown heavily upon using generics as a working part. Why? Anytime you need to make a change to an instance you better make sure you are resetting all values to the originals or you are now making unintended changes to a part. In the PDMLink when it comes to revisions, now you have to revise/iterate the generic when creating/modifying the instances. Makes things a lot of extra work depending on how strict your revision management is where you work.

Wildcards in the table. I think we talked at the last set of TC meetings about PTC giving us a config.pro option defaulted to filling in the table value with the current value upon creation. Very few users there thought we should even be able to allow the wild card.

Just a few thoughts of my own. Sorry if there was some rambling in there, trying to get this done before I have to scram from work today.

Andy

Marc,

You should never use the generic of a family table in an assembly. For simple models you might get away with it but for any complex designs it can me a management nightmare. There are several reasons for this.

1. Feature Management: All features must exist in the generic. You have to manipulate the generic if you want to have new features in the instances. Many times users will suppress and resume features. If you are doing this on the generic and it is used in an assembly what features do you want for that particular version can get confusing.


2. PDMLink management: Many functions require changes to the generic if any instance is changed. If you are using the generic as a component, I am sure that you must have data controls on that version. If an instance needs to change are you willing to roll the revision of the generic as well? This will be required and can cause costly unnecessary revision changes if the generic is used in the assembly.


3. Just a good practice…. When things go wrong with family tables, they go really bad. I spend lots of wasted time trying to clean up others messes. If the generic is used as part of an assembly then it just makes it harder to clean things up. The only time re really break this rule is with sheet metal. We make an instance for the flat pattern but use the generic for all assembly. We could debate all the pro’s and con’s but I would agree that as a general practice, only use instances in the assemblies.

As far as the * goes, I have had a few instances where the generic model was changed and the users did not want the instances to change. Having a * for a value updated all the instances and we manufactured a bunch of wrong parts. It is a lazy way of making things and I wish PTC had not allowed this. If something has a value, add it. Copy and paste is pretty quick. Just one mistake can cost you more than the time it took to make the entries.

Ronald B. Grabau

HP PDE-IT

Roseville, CA

916-785-1888

-

Marc,

I have modeled so many different types of parts & assemblies that I cannot say one way always works or should never be used.

After too many years of this stuff, I have broken most of the rules at one time or another, for good reason, so my first response is generally "it depends".

I don’t see it so much as thou shall not…, it’s important that you think about what you are doing today and what might need to be done later so you are always considering the consequences of the decisions you make.

So think about it and have a good reason for why you approached the problem the way you did.

While I am not an absolutist, I have learned there are better & worse ways to model, here are some of my thoughts.

I prefer to not use the generics downstream, it can get messy when the design changes, and I have run into trouble.

However, for consistent parts, say a screw, I think it’s ok, it just may be harder to track down the generic model name when you want to add an instance for a new length.

It is generally recommended the generic contain all of the features unsuppressed, the instances can suppress & modify them, not doing this can result in stability issues but is not necessarily as big a factor to stability issues as lost feature/assembly/dimension references.

That isn’t always practical, but should always be a goal.

I recommend you add a Group then any variable items after the Group to keep the columns organized and features & their related dimensions together, take the time to move columns around to keep them that way when things change.

Whether or not to allow wildcards to me is something that depends.

If it’s a simple family table and I want to make sure the instances have the same values as the generic, I use the wildcard.

An example is the flat of a sheet metal part with multiple instances, to me not using wildcards makes it more likely to introduce a typo, and possibly communicates design intent – "this needs to be the same as the generic".

However, when the family table is complicated, lots of rows, columns, groups & variable dimensions, I am less trusting of wildcards.

You should also ponder drawing dimensions vs. model dimensions, shown vs. created dimensions and how all that works when making drawings of family tabled parts.

I have had delightful times following someone around who was deleting dimensions in the drawing of one instance only to find the dimensions were deleted in the drawings of the other instances.

Regards,

Walt Weiss

Hi Mark,

The simple possibility that changes may need to be made to the generic as additional instances are added should keep anyone from wanting to put a generic in an assembly.

Also for ease of identification.

Anywhere I have worked prefers the name generic in the generic model and then the family table instances are part numbers.

The same logic goes for the wild card values. Future changes to the generic could cause instance problems.

If the argument is, that the generic is already in an assembly, substitution of family table parts is easy. I agree, without a compelling reason to use them, I would not place them in assemblies.

--

Regards,

Bob Frindt

216-990-8711

Yes, absolutely.

We only use generics in an assembly when we are going to family table the assembly as well, and we try to never use a generic instance of a part or assembly in production. The problem usually starts when someone has a part that they need to create a family table for after the fact. Then the 'generic' may have been used n several assemblies and drawings, and replacing all of them may not be feasible unless you can track them down with PDM.

Christopher F. Gosnell

FPD Company

124 Hidden Valley Road

McMurray, PA 15317

PH:724.941-5540

FX:724.941.8322

www.fpdcompany.com

Using a family-table generic in an assembly is analogous to capturing usage information in a model.

Consider a model of a pin; nothing more than a cylinder with rounded or chamfered ends. Now, let’s add a note to the model that contains usage information that defines every machine where the pin is used. Or, let’s create the pin in the context of an assembly and model it relative to the assembly default coordinate system, which makes the pin useless for other implementations. Adding usage information to a model means that the model, if used elsewhere, must change and that change affects the original implementation of the model.

Generic models are structured to allow for definition of other models (instances) through modification of characteristics of the generic. If a fundamental change to the generic is required because it is being used as part of an assembly, every single instance has to be checked out, verified, and checked back in. That is not the case when modifications are made to instances.

W.C. (Bill) Bowling
Fellow-Engineering Design Process Development

Aerojet Rocketdyne
CAD Services
Office: 818-586-0310
Mobile: 805-501-4875

From my experience the only issue with Family Tablesis unqualified users.

-marc

Seriously, companies need to hire qualified and capable users instead of people who are too lazy or otherwise incapable. There are several "best practices" not being learned or practiced that would eliiminate the belief that such things are needed.

So how does NX handle updating when changes are made if everything is constrained my a location in space?

When parts need to be updated, does one open the assembly, re-apply all the contraints, create new drawings, and then delete all the constraints again?