Skip to main content
M
msexton1-Visitor
1-Visitor
June 19, 2013
Question

Updating older versions of Family Table parts in Assemblies

  • June 19, 2013
  • 3 replies
  • 1936 views

Good Moring Everyone



A little background before the question.



WF 5.0 M180 PDMLink 9.1


I just took over Pro/E and PDMLink usage at a company that has been using Pro/E and PDMLink for the past 7 years with no real guidelines, no standards and no one with any real knowledge of programs to help them. Now it’s time to fix the results of their actions.



I have 100’s if not 1000’s of this scenario in the system right now. I believe it was because of mishandling of Family Table Generics and Instances at the switching from WF 4 top WF 5. I have a workspace I am building a Top Level Assembly in I try to add another Installation level assembly to be added to the TLA and I get this warning through the Event Manager



Version4.6ofthisobjectalreadyexistsintheworkspace306500.Overridingthisconflictwouldoverwritetheexistingversionwithdifferentversion3.13.



If I try to add the Installation to the workspace 1<sup>st</sup> then bring the TLA into the workspace I get a message that it will cause the FT to become unstable.



I have also tried adding the Installation with the older versions of the FT to a workspace and updating the FT and again I get a message the FT will become unstable.



Any help will be greatly appricheated. Thanks in advance.


Marshall Sexton
Master Modeler


Good Moring Everyone



A little background before the question.



WF 5.0 M180 PDMLink 9.1


Version4.6ofthisobjectalreadyexistsintheworkspace306500.Overridingthisconflictwouldoverwritetheexistingversionwithdifferentversion3.13.



If I try to add the Installation to the workspace 1<sup> then bring the TLA into the workspace I get a message that it will cause the FT to become unstable.



I have also tried adding the Installation with the older versions of the FT to a workspace and updating the FT and again I get a message the FT will become unstable.



Any help will be greatly appricheated. Thanks in advance.


NABI USA


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.

3 replies

H
HugoHermans12-Amethyst
12-Amethyst
June 20, 2013

Hi Marshall,



Have you already compared the FT's of both iterations? I suppose you will see instances in the older iteration not to be present in the later iteration. If this is the case, both TLA's can not be in the same workspace at the same time, since the workspace can only contain one iteration of the generic. Right?



How to solve this? As far as I know, you can't combine two iterations of FT's into one big new iteration. This way, your problem would be solved. What we do is select one of the two iterations as the preferred one, and modify the TLA's with the wrong instances.



My 2 cents, Hugo.

B
BillRyan16-Pearl
16-Pearl
July 3, 2013

See the attached presentation for a couple scenarios you may run into wth famiy tables in PDMlink. The specific one I believe you need for this case is the "reconnect" solution. If your company combined a couple intralink databases into PDMlink environment, you may see a couple of the other issues in the presentation.



To diagnose the issues and identify the family tables with issues, I selected a top level assembly and used add to workspace with required dependents...in the add to workspace window, go to the advanced tab to see the "messages" which will provide out of date details or conflicts. From there, it's a matter of becoming familiar with PDM link functionality of search and history of the instances.



Best practices for users -



  1. never delete instances

  2. when itererating the generic, always iterate and verify the entire family table before checking in.

  3. teach users to not accept "marked as modified, but untouched" conditions when working with family tables...repair them so the user community is not constantly managing modified objects in the Workspace.


I also inserted an image that summarizes the multiple different failure modes that you can see with family tables in PDMLink environment coming from Intralink. Half of the issues require Admin priveledges and based on my experience can take hours to repair each case as much time has to be spent diagnosing which case you are dealing with first.


Bill Ryan


Peterbilt Motors Company

    C
    CarTorn926301-Visitor
    1-Visitor
    July 12, 2013

    >Version4.6ofthisobjectalreadyexistsintheworkspace306500.Overridingthisconflictwouldoverwritetheexistingversionwithdifferentversion3.13.


    This is a classic example of a family tableinstance being rolled to a higher revision and then set back to anlower revision level.



    Working with the generic alone, you will not see this problem. The problem manifests itself when an assembly containing multiple instances from the same family table is added to the workspace. By default Windchill will attempt to add the generic associated with the highest revision level of one of the instances (generic version 4.6 in this case) and then when it tries to load the generic associated with the highest revision level of the instance that had been rolled back (generic version 3.13 in this case), a conflict occurs.



    To find the offending instance, compare the revision levels of the instances in generic version 4.6 against the generic version 3.13. If there are many instances, it may be easier to export to Excel for the comparison.



    PTC Tech support was very helpful in resolving this issue a couple of years ago in Windchill PDMLink 9.1. At the time, the preferred solution was to export the family table from Windchill and then re-import at a higher revision level. There may be better solutions now.

    Terms & ConditionsAccessibility statement