Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
Hi all,
A little background information first:
Our engineering departmentrecently transitioned from WF4/Windchill 9 to Creo/Windchill 10. One of the biggest issues we've run into involves revision controls for family table instances. For simpler components, like screws and washer, we have traditionally utilized a single generic component to drive a family table of part numbers, each with their own drawings. In the past, modifying a single component required the designers to check out the generic component and revise the specified instance only. The rest of the family table remained untouched, and did not need to be revised. Since the transition, CREO/WC requires the user to revise and check out the entire family table to modify any one single instance. Obviously, this is creating an administrative nightmare, as we are now forced to roll revisions on the rest of the parts in the family table,which have not been modified.
Here is my question for those of you who may have encountered similar issues: What is the best practice for handling components like screws and washers? Is it better to keep all parts stand alone? Do you utilize a single drawing for all similar components, simply using tables to display part variances and revising that drawing whenever a change is made?
I'm curious to hear how other people in industry have been using their family tables.
Thanks in advance for your advice and expertise!
Jason France
Design Engineer
Benchmade Knife Co.
Our company has taken the approach that if it is in a family table, it should be close enough in design that if any revision to an instance is made, the entire family and thus its drawing should be revised to reflect the intent as well. If we have nuts, screws, etc.they are all their own independant part with separate drawings. We have been considering how to implement a more parametric system like family tables, but as you pointed out there are a least a couple of issues with such methods.
Hi Doug,
The loss with inheritance features are assemblies! Inheritance features apply only to parts, and we need the same functionality for assemblies 😞
Regards, Hugo.
<< ProE WF5 - PDMLink 9.1 M060>>
Hi all,
Thanks for your great responses! We ultimately decided to break the family tables apart and utilize stand alone part files, except where multiple components are already tabbed on one drawing. This was decided based on inputs found on here, as well as taking into account the preferences of our purchasing and documentation control groups. Despite losing the interchangeability of components in assemblies, we believe this will be the best solution for our company as a whole.
It sounds like new family tables work a bit better than those we were working with, since these were originally created in WF4. I plan on doing some experimentation and seeing whether or not that is true.
Thanks again,
Jason
In Reply to Jonathan Hodgson:
On our install at least, Replace Unrelated is *not* available using ProE
Foundation - AAX does give me this function. Other licence options may
also work, but normally I just choose AAX when I want it.
It's a really good tool when you've got it, though!
Jonathan
What M-Release are you using? On both M100 and M160 as we're using now it's available in Foundation.
This was a mess by PTC as first it was available in Foundation in early M-Releases and then they removed it saying it was a mistake and it was intended to be dependent on AAX...
I can't remember if this was already in WF4 or in WF5 that they changed it back and forth.
Hi Greg.
For what it's worth here's how I would attempt to resolve in PDMLink 10.1. Perhaps it might apply to ILink 10?
From the info page of the generic for v5 pick the Actions->Delete and then collect the instances. Delete the Latest Iterationof the generic and the instances with the same modification time stamp. If successful then Check out v4 of generic and recreate the new instances.
2nd possible workaround: Change config to allow check in of non-latest then try to edit v4 of the generic to add the new instances from v5. Hopefully you can resolve the name conflict after saving the edited v4 generic??? If so then check in edited v4 of the generic and set the option back to disallow check in of non-latest.
Best Regards, Jim
In Reply to Greg Kemner
Last year I used CS4975 to correct some family table issues similar to what you're describing. Worked ok for me but, of course, no guarantees.
https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS4975&posno=7&q=deleted%20instance&nav=ptcproductgroups||||Product+Group||&source=Search