14-Alexandrite

Solved

Windchill and Family Tables

Forum|Forum|9 years ago
April 21, 2016
5 replies
19264 views

Hi Folks,

today I would like to start a short discussion about Family Table models (standard parts) used in Windchill.

What is your experience? Do you use Family Table models for standard parts in Windchill? ... or do you use only separated objects (one model per one material number)?

I do not want to speak about 5 instances in Generic models - I mean >> from 200 to 500 instances per one Generic part - For example Screw with Hexagon head.

How to manage this huge Generic model and how to add new instance, set state for new object and update existing parts in different workspaces.

I waiting for your positive or negative answers.

Thanks for your comments and ideas.

Best Regards,

Vladimir

Other

Best answer by LewisLawrence

We no longer use family tables for standard parts, in our experience there is little value and the pain of the extra relationships does not provide any benefit, only problems. We spent a lot of effort exploding and removing family tables on legacy standard parts to avoid those problems. My opinion is that they are a legacy hangover from before there were CAD data management tools and they don't fit well with PLM at all. We have been ProE/Creo users since the 90's and Windchill users since 2000, so we are far from naïve.

Clearly they can be made to work, if you are going to use them you have to treat the entire family table as one thing when making edits/revisions, as underneath there is only one file and the "magic" of Creo interprets the same file as different models. If you have relationships to WTParts, then all the WTParts also have to be included in the collection and handled concurrently with the Family table objects. Clearly a nested table mushrooms these relationships exponentially. This means that controlling edits and revisions to family table objects needs a lot of care, there are no easy ways to force controls and business rules to ensure that using the out of the box tools.

At first view they look attractive, "see how easy it is to create more parts similar to this one", but the long term hassle of using them costs you a lot more time than you save.

B

BenLoosli

23-Emerald III

I have found no issues with using Family Table parts in Windchill....IF you follow some rules.

I have had 200+ instances in the generic of a socket head cap screw file.

Multiple lengths, diameters, material and finish can all be in one file.

The biggest advantage to using a family table for standard parts is replacing if you need to make a change.

Keep the family table simple, one level and no nested levels. Might be a little longer to search, but it simplifies the creation and editing of the FT.

Put the FT in your Windchill Parts Library with limited users (Librarians, Admins) who can make changes.

Do NOT change the state of the FT or instances. Set Windchill so all files from the Library are read-only.

If you MUST have released status, set it once and give the Librarians permission to edit released parts. If the Librarians do normal design work, too, make them use a separate login for their Librarian duties.

You can use parameters to build and format your part descriptions for the BOM. In our case, the name (PTC Common Name) is a brief generic term: WASHER, FLAT or SCREW, CAP, SOCKET HEX HEAD. Use the description field for more detail: 1/4-20 UNC-2A X 2, steel, zinc plated. We add a second description line with a reference to a purchased part number like: (Ref: Fastenal # 125485 or Equiv.).

Always Check-out, modify or add a new instance, verify and check-in the entire FT. Make sure that all instances are verified for each edit session. This may require doing some change that forces all instances to become unverified first.

Do not delete an instance from the FT once the FT has been checked-in. Edit the parameters, but do NOT delete the Number! If the number must be obsoleted, make the values of the parameters something that would Never be possible so the user can see it needs to be replaced.

That is a good start.

S

slapha

15-Moonstone

We have the same Socket Head Cap Screw with 3800 instances, and we regret it.

We try to validate the entire family table every time we add, and of course when we modify something common. That family table takes almost an entire day to validate.

We also have gatekeeper enabled so that keeps us on our toes when trying to check stuff in, so you might have to validate it more than once.

Our new goal is less than 200-300 per table, this is a reasonable size.

This is the plan I put together for some of our large fastener tables. Sort of order of largest criteria to smallest.

Family
- Thread Class
  - Features
    - Material - Plating
      - Dia-Len

So for one of our tables dividing it out came out as follows, into 4 separate family tables.

QTY	Family Threads Dia Len Mat Plate Feat
218	AESC1 C # # GM7 D8 1
220	AESC1 F # # GM7 D8 1
198	AESC1 C # # SE4 A1 1
220	AESC1 F # # SE4 A1 1

The area you run into problems is people like to replace by family table to pick a new size. You can do interchange assemblies but they at least used to bring their own problems. Maybe with IFX in Creo 3.0 that might be reduced if we manage to get all that set up.

The biggest benefit is that replace, and being able to add one by just adding a new row. Though one of our admins favorite way to create a lot of something is to make it with a family table, and break apart the instances once it's made. We haven't done that with fasteners, but I've considered it.

G

GregoryPERASSO

16-Pearl

Hi

Another rules. If you use WTparts and BOMs in windchill with CAD Integration

Do not use the Generic as a "real part" (eg never linked it to a Wtpart). The Generic have to be used as a "pure Design model"

Because if you need to update de FT, or add new instances, it will impact the Wtpart even if not mandatory from a WTpart/BOM management point of view

regards

L

LewisLawrence

Answer

13-Aquamarine

We no longer use family tables for standard parts, in our experience there is little value and the pain of the extra relationships does not provide any benefit, only problems. We spent a lot of effort exploding and removing family tables on legacy standard parts to avoid those problems. My opinion is that they are a legacy hangover from before there were CAD data management tools and they don't fit well with PLM at all. We have been ProE/Creo users since the 90's and Windchill users since 2000, so we are far from naïve.

Clearly they can be made to work, if you are going to use them you have to treat the entire family table as one thing when making edits/revisions, as underneath there is only one file and the "magic" of Creo interprets the same file as different models. If you have relationships to WTParts, then all the WTParts also have to be included in the collection and handled concurrently with the Family table objects. Clearly a nested table mushrooms these relationships exponentially. This means that controlling edits and revisions to family table objects needs a lot of care, there are no easy ways to force controls and business rules to ensure that using the out of the box tools.

At first view they look attractive, "see how easy it is to create more parts similar to this one", but the long term hassle of using them costs you a lot more time than you save.

V

VladimirPalffy

Author

14-Alexandrite

Hi All,

I would like to thank you for your opinions and ideas.

This is my point of view - on the Family table models used with PLM

Family table models
Positives	Negatives
Easy replace - from drop down menu	a lot of models in Workspace
Easy application of changes / shape and dims ( generate new similar part)	overlook
Easy to find similar models	a lot of conflicts - save main asm / updated objects
	model modification - save all instances
	replace in asm - long delay for waiting
	find correct object in the huge list
	long waiting time - upload, download, regeneration
	modify all states for all instances

Whot do you think? I am right

Thanks,

Vladimir

D

dschenken

1-Visitor

Not sure why you need to go through the long list - select by column/parameter gets to the part you actually want and confirms it has the desired characteristics. Probably one can just type the replacement name if that's known ahead of time. I've used some large MIL-SPEC parts tables and never noticed that it took too long.

Not sure why you are getting lots of models in the Workspace. There is only one model, the Generic, in the Workspace. There are going to be instance records in the Workspace view, but only the ones that are added. They only need to be added if the one file that describes all of them is getting a change that affects all of them.

For the Easy column you overlooked that all family table parts are easily verified as being in synch. That is, if the material parameter is changed, all the instances get the same change at the same time. No need to remember which of the dozens to hundreds of files need to be found, checked out, modified, et al. Just grab the generic and make the change - let Windchill do the rest. If it is interrupting the work day, wait until lunch time or quitting time or the inevitable meeting to commit the change. This is more than 'just a new part." This is maintaining the parts already in the system,

What I've seen of the no-Family tables group is that people just grab random STEP files for common hardware from all over the place. It ends up with assemblies where replacing a part requires a huge effort, because even though the Replace dialog can allow the user to match surface references (a task not required for a family) it also means that BOM balloons and note leaders that used to point to geometry on the old part are lost because the -other- STEP file was different. Boom. The few minutes saved by not managing a family table are blown because no one will notice that leader 5 drawing levels up has gone missing when the next change comes, so there will be another engineering change that needs to be created, written, reviewed, released, incorporated, check-printed, checked (again), sent for signatures, reviewed, and released.

Can Windchill play better with family tables? Sure. And a lot of that is preferences configuration to stop Windchill from dragging along items you doesn't care about and table views that are simplified to cutout the vast conversations that the local client feels is required to get the info all up to the latest second for everything. Toggle off the info you don't need and the client will go much faster, making extra instance records inconsequential.