Best Practice - How to Handle Family Tables of Hardware to National Industry Specifications?

[Airfix]

I'm  trying to establish our company's best practices for handling hardware family tables (nuts, bolts, washers inserts, screws) to national standards (NASM, MS, AS etc).  In these cases there can be several thousand part number combinations based on material callouts, finishes, locking features etc.

Often the geometry is the same for each but there is some attribute that is different that causes a change in part number (material, finish, locking feature type etc)

We have typically used family tables but these can quickly become unwieldly when every possible combination is covered.  However we don't typically use every possible combination of parts.  There are usually 3 or 4 bolt diameters we typically use,  5 or 6 different lengths and one or two different materials.

I see a couple of ways of managing these and I was wondering what best practices the  community have come up with.

Possible solutions:

1) Single level family table with all possible combinations in that one family table.

2) Several single level family tables.  1 family table for all cres parts with no locking feature, 1 family table for all cres parts with a locking feature, 1 family table for all mild steel parts with no locking feature, 1 family table for all mild steel parts with a locking feature.

3) Multi level family tables where each part with common geometry has a nested family table with the various combinations of material, locking features or other attributes.

Issues:

1) Can become a very large table quickly and become difficult to manage (excel really helps).  The advantage is that you have one generic model to modify.

2) This is how I've seen it done in the past.  The downside is multiple generics but each table can be quite manageable.  The other downside is you can't easily replace with another instance if you switch to a different table.

3) I'm not familiar with multi-level family tables but it seems like the downside is you still have multiple generics and you also have a massive table to manage.  Again replacement of an instance is likely to be an issue with you wan to to replace across a different generic.

If your company uses other methods please comment below.

Airfix

[Chris3]

We use single level family tables and only include the instances that we commonly use. When they become large sometimes we have split them by material. We did an audit of historical BOMs and dropped the instances that have never been used. When an engineer wants to use one of those instances we make sure it is a true need and then if so we add that instance to the family table.

As an aside we bought our family tables a long time ago from a company that no longer exists. You may want to look into whether or not there are existing libraries available for purchase that meet you needs. I think IHS may have something.

https://ihsmarkit.com/products/3d-cad-industry-standards.html 

[Airfix]

Good ideas.  Because our standard parts are such a mess I like the idea of procuring a set of family tables and making a clean start but that will be for management to decide where to spend their money.

[HamsterNL]

We add a custom parameter "Status" to our fasteners, an integer which indicates if an engineer can use that fastener.

0 = Not available

1 = Available, but not standard

2 = Standard (and thus available)

If the status = 0, then a cosmetic sketch will become visible with the text "NOT AVAILABLE"

If the status = 1, then another cosmetic sketch will become visible with the text "NOT STANDARD"

If the status = 2, then NO cosmetic skeches are visible.

If, at any point, a decision is being made that a certain fastener is no longer standard or available, then we update the status of that fastener in the Family Table. Any project that uses that fastener will now show the cosmetic sketch, an indication that a fastener needs to be replaced with something else.

The status parameter also helps an engineer to quickly place a standard fastener by filtering a Family Table by column (and selecting 2 for the status).

[BenLoosli]

When I created the family tables here, we had some discussions and decided to cover all sizes within a range using Fastenal and McMaster-Carr catalogs for the sizes. We divided the family tables by material and color coded each material in their files. This way you can see if you put a steel washer with a stainless steel bolt. Different material classes were also put into single family tables. I will have 2 family tables for steel hex nuts: SAE J995 Gr5 and SAE J995 Gr 8.

Size ranges are from the smallest (#0) to 1-1/2" with lengths up to 6". There have been some exceptions and we have added some longer lengths where needed.

You did not mention if you are using a PDM system (WIndchill, etc) or native filing. In Windchill, all family tables are owned by the administrator (me) and in a library, not a product context. This way, the instances come into the user's assemblies as read-only parts and they cannot change them. I also revise ALL instances if I make a change or add new members to a family table. This way there are no multiple versions of generics out there causing conflicts. I also tell my users to sync their workspaces daily, but some do forget.

[Airfix]

BenLoosi,

I like the suggestion about using colors to quickly highlight if you are using a SS fastener with a mild steel washer.

We do use Windchill here but it is like the wild west.  Anybody can modify any family table.  We have multiple fasteners of the same type being modelled individually outside of family tables with different prefixes or post fixes on  the file name. Some are modelled to the max major diameter size, some are to the nominal and some are to the minimum. It's a crazy mess that I'm hoping to clean up because we've been instructed we are going to model based definition.

The way you describe how you handle your fastener tables is how I think we should be doing it.  Only model the parts you typically use.  Have tight control over your family tables and only allow 1 gate keeper and a deputy to modify them.  Split them down material lines if the family tables get too big.

Thanks for the response.

Airfix.

[Patriot_1776]

I echo Ben's statements.

Also, I would NOT use multiple generics.  Yes, it would be nice to break a large table up, but it'll end up with more problems than you solve.  Do NOT use multi-level family tables, Windchill hates them.  I had used flexible parameters on my tables, in case someone wanted to use McMaster-Carr specific part number (to show up a particular way in my BOM table), but I'm finding that using flexible parameters in fasteners is causing some problems, so I'm going to strip that out.  I'll just copy the fastener from now on and change the description for those.  I create large tables by fastener type (i.e. hex socket cap screw), and fill them out as needed from the spec.

You are SUPPOSED to be able to use the material parameter ("PTC_MATERIAL_NAME" if I remember) to change color based on the material, but that has never worked right.

Best of luck!

[BenLoosli]

"You are SUPPOSED to be able to use the material parameter ("PTC_MATERIAL_NAME" if I remember) to change color based on the material, but that has never worked right."

This is why I have each family table specific to a material. I may have 3 or 4 socket head cap screw  family tables, but by limiting them to a material (and color) I don't get into multiple thousand instance files. My largest is about 1600 instances.

[Patriot_1776]

'Sup Ben!

Yeah, I can see doing that.  I've been just putting them in the same table.  I figure (me) having to keep track of multiple family tables just separated by material would be more trouble for me.  Plus, makes swapping out for another material easier (we would just use maybe 1 or 2 grades of stainless and 1 or 2 for regular steel) and I keep HOPING PTC will fix this bug that's been around since...what, 2006?  I separate my tables based on fastener type only (i.e. hex cap screws vs. hex socket cap screws etc.).  Luckily where I work I don't need to use cross-recess pan-heads or other funky screws.

[HamsterNL]

---

@Airfix wrote:

Issues:

1) Can become a very large table quickly and become difficult to manage (excel really helps).  The advantage is that you have one generic model to modify.

2) This is how I've seen it done in the past.  The downside is multiple generics but each table can be quite manageable.  The other downside is you can't easily replace with another instance if you switch to a different table.

3) I'm not familiar with multi-level family tables but it seems like the downside is you still have multiple generics and you also have a massive table to manage.  Again replacement of an instance is likely to be an issue with you wan to to replace across a different generic.

If your company uses other methods please comment below.

Airfix

---

We use solution nr. 2 (multiple single level family tables), and we have overcome issue nr. 2 by placing all our fasteners in single Interchange Assembly and assigning the Component Interface of our fasteners as the Reference Tag.

We have bolts, nuts, washers, plugs, studs, rivets...everything is in that Interchange Assembly...and we can replace any item with any other item without any problems. We have about 50 family parts in this Interchange Assembly.

Yes, we can swap a nut for a plug, or a bolt for a washer...no problems!

The best thing...if there's a need for a new bolt/nut/washer/plug/stud/rivet...we just add it to the Interchange Assembly, and BOOM...that new thing is available for all our users (after they updated the Interchange Assembly in their workspace).

We also drive our fasteners by name (PRO/Program), so we can swap anything out with a simple regenerate.

The only downside is that you have a lot of parts in your workspace (all the bolts, nuts, washers, etc.)...even if you only need one bolt.

Hope this helps!

[Patriot_1776]

Interchange assemblies work, but be aware that it's nothing but a family table behind the scenes, so essentially there's the possibility of Windchill issues same as with multi-level family tables.  Glad it's working for you guys, but me personally, while I might make an interchange assembly to swap one type of screw for another (hex bolt vs hex socket cap screw, I'd never make an interchange assembly to swap a screw for a washer.  You can replace a fastener by an unrelated component for that.

Our guys here complain so much about family tables as it is because they have never been taught how to use them, I'd hate to give them another reason to gripe when suddenly 10,000 fasteners end up in their Workspace!

[HamsterNL]

Thankfully, we have not encountered any problems with Windchill and our fasteners Interchange Assembly (knock on wood!)

The only thing with Family Tables is that (in the past) some users had the habit to REMOVE instances from a Family Table (for whatever reason)...so that's forbidden now 😂