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.
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.
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.
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.
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.
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.
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.
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!
"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.
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.