Family Table Revision Control Issue

[jfrance]

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.

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[merrill.rosenow]

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.

[dgschaefer]

Several years ago (2007) there was a presentation (attached) at PTC User
on using inheritance features instead of family tables that solved this
problem. You'd create a master part (generic) and then use an
inheritance feature to bring the entire part into a new part (instance).
Within the inheritance feature you can specify variable items, thus
creating different 'instances'.



Because they are tied to a common 'generic' changing the master will
propagate through the 'instances', but because the variable information
is stored in each part, changing an 'instance' does not propagate up to
the 'generic' and then back to all the other 'instances'.



I believe the only loss compared to family tables was ease of
interchangeability.



--

[ptc-1932745]

In Pro-e WF 2-5, and testing in CREO1:



In cases where we are purchasing stock components (Bolts, screws,
washers, etc...) but have individual drawings to spec out the parts, we
are slowly getting away from family tables for a couple of reasons:



1) We are using more vendor CAD models

2) limitations of the family table and complexity.



This is a slow transition, but I am finding that using several
independent models, linked by an Interchange Group is the best
(simplest) solution for now.

I can make one Interchange 'family' that includes flat head, hex head,
socket head, etc... bolts, or flat washers, lock washers, toothed
washers, tabbed washers, etc... and not have to worry about complicated
and nested family tables.



I am considering this approach also for solid modeled milling cutter
assemblies for use in Pro-Man, but have not tested it yet.



I do not use Interlink / Windchill but I would estimate that this would
be simplified as well by limiting the scope of the change to the
individual item, item drawing and possibly the Interchange group only.





Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

[STEVEG]

Has anyone tested to see if an interchange assembly works as advertised in Intralink/PDMLink? I thought at one point someone mentioned it doesn't play well with PDM.

Steve G

[HugoHermans]

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>>

[TomU]

I just finished testing this with PTC tech support. Creo Parametric 2.0 M020 and Windchill 10.0/10.1 do NOT change the behavior of family table instances or generics during check-out/check-in or during revising. The PTC support engineer demonstrated revising instances separately from the generic, revising the generic separately from the instances, checking out, modifying, and checking back in both the generic and select instances without affecting any other instances. We were not able to identify any changes from previous Wildfire / Windchill 9.1 behavior concerning family tables.

Tom U.

[kimndave9]

When such opposite results come up, it is a sign that the problem is not
entirely described.**

In this case, I'm going to guess that the change Jason is dealing with
forces the generic to be marked as changed in a way that forces all the
instances to be marked as changed. I'm leaning towards a
mass-properties calculation. Any other ideas?

It does seem like expectations for the family table are getting
over-extended. The family table core is a model with a list of alternate
configuration names and related configuration variations. There is only
one model and that model has an integral list. Take a dowel pin as an
example. Suppose in Rev A the -1 is .5 inch long and the -2 is 1 inch
long. This is found to be a mistake, and the -1 is changed to .75 inch
in Rev B. How should the system resolve the case of a Rev B -1 with a
Rev A -2?

Dave S.

**Many 1990s Ford/Mazda 626 4cyl had a <60k mile w/automatic
transmission life. Owners would complain about the unreliability of the
Ford/Mazda 626s. Often a comment would pop up and say they had a 626
with 150k and no problems. Only later did it become clear they either
had manual transmissions or the automatic transmissions were attached to
6 cylinders. Details, details.

[TomU]

You are correct. I did some checking with another user who was having difficulty with family tables and it turns out the problem actually has to do with bringing pre-WF5 family tables forward into Windchill 9.1 or later. The TAN is 150276 (

[jfrance]

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

[ptc-1932745]

To get interchangeability back, use Interchange Groups. You need a
license for Advanced Assembly, or Tool Design, or some form of NC , I
think.



Christopher F. Gosnell



FPD Company

124 Hidden Valley Road

McMurray, PA 15317

[BrentDrysdale]

Hi Chris,
My understanding is that Replace Unrelated Component was introduced in WF4
and I remember some enhancement for WF5. I found a link on the PTC site
that describes this<but">http://www.ptc.com/appserver/wcms/relnotes/note.jsp?&icg_dbkey=826&im_dbkey=50811>but
that may not work if you don't have
ptc.com login so I have pasted the text below. You are right that to use
the specific Interchange assembly functionality you need AAX but to replace
a part you no longer need AAX.

*Enhancement Details*

*Replace Unrelated Components*

You can replace a component with an unrelated part or subassembly.
Pro/ENGINEER provides the tools to map the references required from both
objects to ensure that there is no feature failure due to missing
references.

*Product Information*

*Product*

PTC Creo Parametric<">http://www.ptc.com/appserver/wcms/relnotes/index.jsp?show=y&version=4075&product=403>

*Product / Module*

PTC Creo Parametric<">http://www.ptc.com/appserver/wcms/relnotes/index.jsp?show=y&version=4075&module=403>

*Version*

Wildfire 4.0<">http://www.ptc.com/appserver/wcms/relnotes/index.jsp?show=y&version=4075&product=403>

*Product Functional Area*

Assembly<">http://www.ptc.com/appserver/wcms/relnotes/index.jsp?show=y&version=4075&product=403&functional=2928>

*User Interface Location*

Edit > Replace

*Processes, Initiatives, and Best Practices*

*Benefits and Description*

You can replace a part or assembly component at any assembly level and the
target component and all its children are automatically replaced. From the
Replace dialog box, you can map references from one object to the other.
Using a table, you can highlighted and color-code reference tag for each
target and source. Advanced and more granular reference definitions are
also available.

Enhancements include:

- A method to map the assembly references between a model in an assembly
and the model that is to replace it
- A prompt for you to confirm that the assembly references are mapped
correctly before the model is replaced
- The option to manually change the mapped references, if necessary
- Failure resolution procedures if the reference mapping method fails
- Mapping table storage so that you can automatically replace multiple
occurrences of the same model

You can automatically find pairs of references between the outgoing
component and the replacement component. There are several pairing rules:

- Same Name—Automatically pairs objects with the same name and type.
- Component Interfaces—Searches for the interfaces with the same names
and then examines each definition. If the same reference types are used in
each interface then these can be mapped automatically.
- Same History—Searches the replacement model for any external
references to the original model. If found, these references are
automatically paired.
- Same Parameters—Automatically pairs parameters with the same name and
type.

After autotagging, autoselection, or manual selection, a pairing table is
created. You can store the pairing table in the current assembly or, *if
you have an AAX license*, you may create a new interchange assembly. Both
methods have advantages and disadvantages.

Storing a pairing table in the context of the current assembly:

- Advantage: Models used for replacement are not modified.
- Disadvantage: During subsequent replacements on other assemblies, you
must search and find the appropriate assemblies that define tags for
outgoing and incoming components. This may be time-consuming.

Storing a pairing table as a separate interchange assembly *(please note,
this requires an AAX license)* :

- Advantage: You can easily find all interchange assemblies in which
this component is located.
- Advantage: All possible candidates are offered for replacement.
- Disadvantage: It modifies the models (unwanted with library parts).


Hope this helps.
Regards,

*Brent Drysdale*
*Senior Design Engineer*
Tait Communications

[JonathanHodgson]

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

[RogerCrill]

Jon,

About 2 years ago the new maintenance releases were to have a
modification to the licensing for Unrelated Components. If you had a
model copied from what you are replacing (surface ids are identical),
you didn't need AAX. Once you access the reference table you need the
license.



If you make a series of parts by copying from a master they will change
out as easily as changing family table instances. That is assuming you
don't make changes that replace the surfaces required for assembly.



Roger Crill

Sr. CAD Administrator

Manitowoc Cranes
T 920.683.6554

F 920.683.6277
"Integrity, Commitment to Stakeholders, and
Passion for Excellence"

[magnus.salomons]

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.

[JonathanHodgson]

Hi Magnus,



We're running WF4, M220.



Regards,

Jonathan

[gkemner]

Happy New Year!

I have a family table part, washer.prt.4 that had several instances deleted from the table along with several new instances added to the table and then checked in so that it is now washer.prt.5 in commonspace.

However I still need the instances that got deleted from washer.prt.4

I logged in as org admin but Intralink will not allow me to delete washer.prt.5 since that would delete the new instances that were created with the .5 version. It also will not allow me to add the missing instances back into the .5 version family table do to file naming conflict (since those instances already exist in the .4 version and are in commonspace.) Performing an update or synchronize does not fix the file naming conflict.

I seem to be stuck... Any thoughts???

Intralink 10.0

Thanks!

[DonSenchuk]

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.

[jellis]

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