We have a bunch of models that are using Family Tables that really shouldn't be family tables and we're considering alternatives. Some of the alternative methods we are looking at are:
Does anyone have any best practices, lessons learned, advice, presentations, or documents that they would be willing to share?
We do use Windchill for our PDM/PLM solution, so that will need to be considered as well.
We avoid family tables if all possible, Windchill and family tables have a tendency to cause issues sometimes especially for CAD driven BOM's. We have tons of legacy family tables and I break them up on as needed basis, especially when the instances are at different revisions.
The method is to checkout the whole family table into a workspace, then bring up in session the generic and instances you want to make standalone, this is very important!. Then delete those instances out of family table. Save the family table. Then in the workspace you will see the instances are not part of the family table, but now standalone parts. Check the whole family table and standalone parts back in.
Downside, other users will see those old instances "out of date" in their workspaces. They will not be able to update, they have to delete the old instances out of workspace and add the new standalone parts back in. Or just start a new workspace and bring in everything fresh again which is a cleaner method.
We have been breaking up family tables when we can as well. I agree with you that there are numerous issues with Windchill and Family Tables. Like you said we have a lot of legacy data that needs to be dealt with too.
Some of the family tables were created for good reasons, even if misguided. I think we could really help drive the adoption if there were a good proven alternative to the family table instead of just breaking them up into separate models. Like inheritance features / models for example.
I know we run into issues when people don't revise the entire family, drawings, and WTParts at the same time, then the associations become a mess.
Especially when the family table of a component is partially revised up, and goes into an assembly family table, and one instance of the assembly calls for the new component revision, and another instance calls for the old component revision. You cant have both in the same workspace and so you are stuck.
An easy mistake to make, especially when you don't work with family tables all that often. Thats why I think some of our models really shouldn't be family tables, but use other methods.
One of the things I learned early with family tables was to keep it simple.
Don't do nested family tables.
Use a family table where one value may need to be changed; length of a bolt, maybe a diameter. Think of why you may need a different instance and limit the family table to that choice. You may change the length of a screw/bolt to get 2 threads beyond the mating nut face. Changing diameter is seldom done, but may be for strength reasons. If you have multiple material types, they could be in the instances, too. While this may sound like a complicated file, set it all up as a single level.
Do NOT let everyone have access to the Generic models! Limit the editing to a select few librarians.
Put the family tables in your Windchill Part Library for control. Set Windchill so all files in the Part Library come into a designer's workspace as Read Only.
Avoid Family Table assemblies unless you have thought out the full design up front. I did one of a plastic wire tray with a lid that was held on with studs and thumb nuts. The number of studs/nuts varied depending on the length of the part. The width and height of the tray were also variables. All component parts were in their own family tables. While it worked well for the first 8 assemblies, after that the number of columns to edit for a new instance became unwieldy. so we broke the assembly family table to individuals but left the components as instances. We reasoned that we would not be replacing one assembly for another that often, if at all.
The prior system admin here, who set up Windchill did not like Family Tables so there were few when I arrived other than sheet metal flat patterns. I have since added some for things like 1-1/2" stainless steel tubing that we cut into any number of lengths (28 last count). We have also done other tube diameters. Some that are individual files, 1" has 138 file, are not in a family table since it is just as hard to convert an individual part to an instance as it is to turn an instance into an individual file. There are a few other things in family tables but the common theme is different lengths.
I would love to move hardware into family tables but there are just too many to do. We did use Part Solutions and their modeling is terrible! We stopped using that when we went to Wildfire 4. Every feature has new datum planes that may duplicate an existing one. I am replacing them as we edit the file for other reasons. The also have about 3Xs the number of parameters in a sketch than is needed to define the shape and half of those are reference dimensions. Delete all of that junk.
Are you using As-Stored for retrieving models? Otherwise I don't see a way to require specific versions that could conflict. I can understand where users stamp on each other's work and make incompatible models where one version used to work, but a later version doesn't. That happens all too frequently.
It is confusing, and seems to only come into play when you have a component family table going into an assembly family table. For example if I have a model, COMPONENT.PRT with three instances and iterate (Check out, Modify, Check In) one of those instances, the generic and one instance is a different version.
This is fine by itself, and even when assembled into a regular assembly. (Until you try to switch component instances in the assembly.)
However, the trouble starts when you have an assembly family, ASSEMBLY.ASM with three instances that use the instances from the component. Now you have a mess.
Looking at the original problem, I'd suggest explode states for showing mechanisms in multiple positions. If necessary, they can work with simplified reps to show only the parts of the mechanisms desired without affecting anything outside the assembly. Unlike flexible models there is no noticeable regeneration, so the regen can't go wrong or get skipped, something I've seen a few times for simple flexible model based alterations. Downside is manually creating the motion of the mechanism. AFAIK it doesn't create a hidden family table the way that assembly features and flexible parts do, but it also can't alter part feature sizes.
The common bad thing about simplified reps, explode states, and flexible parts, is there is not a unique identifiable name to apply to a BOM, whether by Repeat Region or model tree. Worse, because of the laxity in the flexible component process, I could change a fastener from one size to an entirely different size, but it would only be noticeable by the icon in the model tree. Windchill would not notice that the screw was the wrong size and neither would a Repeat Region.
That said, flexible parts can be pretty good. I've used them in conjuction with measurements so that the parts automatically fit. My favorite was a swivel-foot that used an angle measurement to meet a part subject to tilting, with a runner up in suppressing components in jack-screw kits for connectors to skip hardware that is discarded depending on usage.
A cool item for family tables is to combine it with Groups. Put all the items that work together into a group and the Group can be added as a feature (not a group, but feature type) in the table. For more complex items, Pro/Program can be driven from a parameter in a table to influence regeneration with IF/ENDIF segments. These two items can be used to reduce hundreds of columns to just the few that are required to actually distinguish the differences.
I've used Inheritance for casting/machining. It works well enough for that. Unlike a similar process for family tables, it provides a fire-wall between the two, which can slow development work, but does allow multiple versions of machining -after- the casting model is released/otherwise locked down. And it keeps the machining versions from interfering with each other. Unlike family tables, any common changes must be done independently with the risk they will not match.
The mentioned circumstance is a flaw in that Windchill doesn't update the 2.4 instances to point at the 2.5 generic.
I've long thought that Windchill development has less grasp of Creo than they should have. There is only -1- generic file at any iteration/rev/version (IRV?) and no other information about the CAD in the instances is anywhere else. PTC fouled up by allowing instances to ever have a different IRV than their related generic and may have made it less workable by not updating the links when the generic is revised and the instances aren't.
Given that, it's easy: just roll all the instances with the generic. Doing otherwise is a self-inflicted problem that should never have been allowed to occur.
I am absolutely aware that some companies have IRV control ideas that conflict with the way family tables work.
People who have to manage under this have my sympathy, but such a system gets no pity from me. If I asked these same companies how they manage to control individual sheets in MS Excel Workbooks or pages in an MS Word document in their PDM systems in a way that would get the same results they expect for family tables, they'd give blank stares, even though the concept is identical - one file describes a multitude of separable parts (page 3 of a report or the Nov Schedule sheet can be printed all by itself.) They don't expect their PDM system to manage those pages/sheets that way in spite of the fact that in the olden days, multi-sheet drawings had individual sheet/page revisions, and (OMG!) some people carried that format over to (OMG!) Word documents.
When not to use family tables? When the items aren't a family. Like assembling all the components into a gigantic assembly and using family tables to select just those components for some assemblies.
But when they are a family they are hugely valuable. Find out a part is mis-modeled and the 100 instances need a new parameter or just a feature? Change the generic, Verify. Done. Broken up/individual? Open each one. Make the change. Check to see if the change was right. Oops - distracted and missed a few? Even small tables can be 10 times more productive than individual parts. Have 100 family tables of 50 parts each and need a change? Welcome to tooling through 5000 parts.
I agree! Family Tables are a fine tool to use, when used properly.
Our problem is that we took that tool and started using it for things that it really shouldn't be used for. So I want to see if we can take some of those edge cases and apply a different tool and get better results.
Hello Marc DeBower
thx for this topic, it´s realy interesting. Some basic operations from my point of view.
Where l will use Family table? (FT)
1. Make some dimmension diferent (length of screw, washer thickeness etc.)
2. Change string parameter value (drawing number, note etc.)
3. Suppress feater (hole at the end of bolt = YES/NO)
Where l can use FT and what are alternativies?
1) Make assembly settings. (part YES/NO)
A) - use simply representations (cheap solution)
- possibility to use graphic or geometry rep = less hardware demand
- more flexible than FT
B) - use Creo option modeler (costly solution)
2) Unbend sheetmetal part (bend back = YES/NO)
A) - l like thise trick Creo 2.0 Sheetmetal - Simplified Reps for flat pattern drawings
Have some other ideas, but don´t have more time
These all work fine untill you revise the whole family table together to same revision, always.
If not then the problem starts and family table sucks..