Windchill and Family Tables

[VladimirPalffy]

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

[BenLoosli]

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.

[slapha]

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.

[GregoryPERASSO]

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

[LewisLawrence · Accepted solution]

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.

[VladimirPalffy]

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

[dschenken]

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.

[VladimirPalffy]

Hello David,

thanks for your great comment. I really appreciate it.

Is always good to know that my old family table models I can still use with new PDM system

Note: I like Family Table function and ProProgram too - it is really powerful for quick modification - model parameterization.

I will wait for another success story with Family Tables from our colleagues around the globe.

Best Regards,

Vladimir

[dschenken]

Another approach - if the desired instance is already in memory, one can open Pro/Program and use Text-based Search/Replace to change the instance name to replace the parts without having to go through the Replace interface. This method of Replacing parts only works for Family Table items.

As well - the Program can dynamically replace instances using lookup_inst ("generic_name", match_mode, etc. which requires family tables.

[LewisLawrence]

Following up on this discussion, I think it is probably worth adding some clarification to my earlier post.

With standard/library parts it is imperative that you have good control over the geometry. These components are used in many assemblies and the last thing you want is for someone to be modifying a standard part instead of completing a revision to all the assemblies to swap out a component (E.G. someone makes a bolt longer and changes its description instead of replacing the short bolt with a longer one in new revisions of all the assemblies. From experience some well-intentioned moron will actually do this if the system lets them). Depending on how you want to introduce new standard parts, applying the necessary controls to family table files is difficult, because to add a new instance you need to be able to modify the generic.

Weatherford do still use family tables, just not for Standard parts. Where they work acceptably in our experience is for showing the same geometry in different configurations/stages of operation. So an assembly will have a family table with instances for Stage 1, Stage 2, Stage 3 allowing those to be easily shown on a drawing. Another valid use case is when you have the same geometry but need different materials/coatings. Crucially with both of these examples the geometry of components is being re-used, so no family table properties are modifying sizes of any one component. Also it is always obviously required to treat the entire family table as one “thing” when making any edits, so users instinctively put all the objects on the change and edit them together.

[VladimirPalffy]

Thanks Lewis for you additional information of using Fam. Table models and assemblies.

Best Regards,

Vladimir

[dschenken]

Lewis,

That's what flexible components are for. No need to change a rev on anything.

My regular experience is people often never changing the parts because, not being family table items, they loose component status in higher simplified reps and explode line references, leaving a lot of extra cleanup work in otherwise unrelated drawings and assemblies for a minor low level sub-assembly change.

At the company I where initially used Pro/E that utilized family table standard parts we did two things - one was to include all reasonable parts at the outset and the other was to keep them in the Admin controlled Library parts Intralink and then Windchill folder. Users weren't allowed to change standard parts. There were family tables I created at rev 13 that are still in use.

[LewisLawrence]

In our case the Creo Assemblies vary greatly between instances in the family table, a lot of down hole products have shear pins that shear/fail based on levels of pressure/force and allow components within the assembly to move/activate and reposition. Similarly some assemblies leave bits of themselves in well, or go in to retrieve others. Each stage has to be shown on a drawing for review and QA purposes, each instance in the family table is a substantially different assembly, not possible with flexible components.

We drive our business from a WTPart with associations to CAD objects and representations, which are all produced "as stored". There is no magic bullet to avoid the situation where changes at a sub assembly level require upstream documentation to be corrected if you need to see those changes in the drawing. Additionally we often drive structure onto the WTPart from CAD, this same structure drives the BOM into ERP and is business critical.

My original statement still stands, any time savings from using family tables are negated by how much additional work they end up creating.

[BillRyan]

Lewis, I'm jealous of your success with reducing the usage of family tables!  There is another big company out there with your same logic.

All, Here are three real world examples in our environment we have experienced just in the past two weeks with family tables and Windchill.  (I see no solution to prevent it in an environment with 1000 development users with in work objects)

1. Admin undo checkout on Family table -> WC Method server impacted -> All user's across the world in Windchill lose performance. (PTC Case was created and logs sent)
2. User working with out of date information in Workspace for 2 weeks -> Update action in WS not updating out of date objects -> PTC Case created -> User upset in Australia because case is not getting answered -> PTC Case escalated(more admins involved) -> Find out another user deleted an instance of a lower level component used in his Assembly -> Fixed where used assembly and able to update workspace. ->  Case closed.
3. User has partially checked out family table instances and somehow didn't check out the generic(Yes, our collector settings have include generic) -> Another user is looking at assemblies in Creo View and notices geometry is not showing up for lower level components -> Find out that WC publisher does not publish correctly with this partially checked out scenario -> undo checkout on the family table -> Republish where used assembly to correct. (Note: this is the third such scenario where I've found the WC publisher fail to publish correctly with the different ways to checkout family tables).

How much $$$$$$$ do you think the above costs a company? Incorrect Data, Upset Users, 3 Admin's time, lost work...I had 3 other call's from user's in the past week related to family tables I could add to above but I think you get the point.  They do not provide value when you look at the big picture. I've created cases in attempts to prevent different scenario's that user's can perform, but the number of different scenarios seem to never end!

[dschenken]

Hi Bill, those are pretty terrible.

Which version of Windchill choked on a family table and how many objects were in it? Seems like PTC should be able to handle 10,000-50,000 undo checkout in one slug without a hiccup. As far as WC is concerned, family table members should just be regular CAD objects, but I don't have access to the Oracle table structure or the SQL that PTC uses, so I am not sure what business logic/operations are applied. Since that's a Windchill problem, it's probably useful for me to put that inquiry into the Windchill forum.

For commonly used parts, the second two would not happen if the family tables were controlled by the Admins.

In particular because Admins know not to randomly delete entries in family tables. Users, on the other hand, seem to think they can edit the names in the table and use that to 'rename' instances. As far as Creo/Windchill is concerned editing the name in the table is no different than deleting the part and creating something new. I've seen unqualified users try that more often than deleting an entry, but clumsy happens. There could be an action on WIndchill that is triggered when a Generic is checked in to verify that the new version has at least the same instances as the previous version did and send an e-mail to the Admin when that is not the case, if it can't shut off the check-in completely. Similar to the originating end by using Modelcheck to ensure the tables are verified when saving.

That third one seems like a failure with the Publisher/check-out settings. It also points out a problem with the way CAD instance parts are viewed by WC and by companies - that instances are somehow magically independent of each other and of the Generic. There should be no ability to check out Instances. Instance should be in lock-step to the Generic. There's only one Generic CAD file, and that file contains all the information about all the instances. Controlling revision of individual instances is like controlling revisions of individual sheets in an Excel Workbook or pages in a Word Document. Most companies gave up individual sheet control on office documents like those created/edited by Excel and Word about 20 years ago. The same should have been true for Generics/Instances. If the policy is to move it all at the same time, then nothing is left behind and no out-of-step problems should occur.

Thinking outside the box - does PTC offer Creo customization tools to remove the ability to create/edit Family tables or other complicated functions on a user-by-user basis? This could be used to prevent unqualified users from making a mess of things. Like a big poster in the wood shop that Bob "No Thumbs" Smith is never allowed to use the band saw?

[BillRyan]

We are in 10.1 going to 10.2.  I don't know the details on the undo checkout issue.

I agree with your logic which is basically what Lewis is saying....don't let anybody in development create family tables.   Development is the group creating every CAD object in our company.  I really think if you took a vote from 10 large companies with Windchill and a collaborative environment that you would have 9 out of the 10 tell you not to create family tables if you had the choice of starting over from scratch.  We are unfortunately too far down the road to take the tool out of the toolbox.  Obviously, there are good use cases for family tables if you have the right business and environment.    

We do have query reports being developed to find partially checked out family tables, family tables not verified and family table instances not residing in the same folder as the generic.  A case was created to identify instances deleted or missing from latest iteration...it was not possible according to PTC.  The strategy we plan for is using these reports to identify the "Bob's" that need trained.   From past experience, it's the new user's in the environemnt that cause all the problems.  I do have plans to upload these to the query report forum once they start working correctly....I want them to only find objects within a specific date range and they are executing on the entire database.

[rakalawadi]

Hi Lewis Lawrence,

I am facing the same problem with Family table as you did. You have mentioned that you have overcome the problem of family table by exploding the family table. Request you to please suggest me the ways to eliminate  / Explode the family table.

Each Generic model contains 23-30 Instance Parts. Our challenge is as instances are version controlled in windchill, we feel that it is risky to delete the family table as the previous iterations will still have link with the Generic and we suspect that it may create "Ghost objects" in future when we modify the design of any exploded part.

Request you to please suggest on the steps on how did you eliminate family table in windchill?.

Eagerly waiting for your response.

Thanks and Regards,

Rajeev

[LewisLawrence]

I have asked a colleague to post and explain how we exploded family tables, someone smarter than me did that.

[BenLoosli]

Here is a PTC article on removing instances from a family table in Windchill.

https://www.ptc.com/en/support/article?n=CS21661&language=en&posno=4&q=removing%20an%20instance%20from%20a%20family%20table&source=search

If not using Windchill, the process is easier:

Open the Instance

Save as the instance to a different folder

Repeat until all instances are saved

Delete the family table generic file

Move the new standalone files to a folder in your search path.

[mdebower]

I ran across this in my feed today:  http://support.ptc.com/appserver/cs/view/solution.jsp?source=subscription&n=CS220794

(You will need an active PTC account to access.