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.
Thanks Lewis for you additional information of using Fam. Table models and assemblies.
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.
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)
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!
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?
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.
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,
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.
Here is a PTC article on removing instances from a family table in Windchill.
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.