Skip to main content
C
ckorkuch1-Visitor
1-Visitor
October 20, 2015
Question

Issue with family table instances and assemblies

  • October 20, 2015
  • 4 replies
  • 7514 views

Hey All,

 

PTC Creo Parametric

Release 2.0

Date Code M170

 

I apologize if this is already covered but there is just a mountain of topics around family tables and instances - and none seemed to cover my issue that I could find.  I'm pretty new to creo but have experience with solidworks, inventor, and autoCAD.  I have a part file that has 2 family tables instances.  I also have an assembly that also has its own 2 family tables instances that represent sub-assembly's.  I also have a second assembly that has its own 2 family table instances that represent final assembly's.  Each family table instance of the assembly includes a specific family table instance of the part file and sub assembly file.

 

For example:

 

part1.prt (generic)

part1-01.prt (instance 1)

part1-02.prt (instance 2)

 

subassembly.asm (generic)

subassembly-01.asm (instance 1), includes part1-01.prt

subassembly-02.asm (instance 2), includes part1-02.prt

 

assembly.asm (generic)

assembly-01.asm (instance 1), includes subassembly-01.asm

assembly-02.asm (instance 2), includes subassembly-02.asm

 

I've then created a drawing file for each assembly instance.  Everything looks great, and life is good, I've got what I need done for the day.  Then I close Creo 2.0 and go home.

 

A few days goes by, I open the drawing files to make tweaks, and export to PDF.  Everything again looks great, life is good.

 

One day, I open the assembly file to make some changes - and things go bad.  The once perfectly configured instance references now seem to reference only the generic sub-assembly assembly file.  Placements are broken.  So, I open the sub-assembly assembly file only to find that the once perfectly configured instance references now seem to reference only the generic part file, with placements broken.  I open the drawing file for the assembly and its completely broken.  The part instances, when opened, seem to be fine.

 

I replace the generic part file in the sub-assembly with the correct part family table instance, regenerate, save - and leave open.

 

I then replace the generic sub-assembly assembly file in the assembly with the correct sub assembly family table instance, regenerate, save - and leave open.

 

I open the drawing file for the assembly file and all is good.

 

I make my changes to the assembly that i need in the session, everything links correctly, i export my PDF drawing, I regenerate and save everything open, and close Creo.  But I wonder, will I see the same issue with family table instances in the assembly files?  I open the assembly file again - and again the generic family table instances are shown and placement are broken.

 

What's going on????

 

It appears that every time I open an assembly that includes an instance from a family table assembly or part file, the correct instance isn't loaded and the placement is broken.  The placement issue seems reasonable based on the assembly trying to define a relationship with a component that is no longer in the assembly, but what this means is every time I need to make a change to a part, sub-assembly, or assembly I need to re-define them all and repair their placement.  This doesn't seem reasonable...am I doing something wrong?  To me, it seems that family tables may be broken by the way I'm using them?

 

Chris

4 replies

Dale_Rosema
23-Emerald III
Dale_Rosema23-Emerald III
23-Emerald III
October 20, 2015

When you are creating the constraints, are you pick surfaces that have the same ID for each instance? If not, you could be fighting a battle between you subassemblies where on Tuesday with sub-assy #1 you are pointing to surface #24, but on Wednesday you open sub-assy #2 and it has constraints missing because it is looking for surface #38. On Thursday, you open #1 and it is broken because it is looking for #24.

You have to constrain the parts using things that will be common among the instances. Not sure if this helps, but worth a look.

Thanks, Dale

    C
    ckorkuch1-VisitorAuthor
    1-Visitor
    October 20, 2015

    I do not follow.

    The issue with placement breaking is because the wrong family instance is brought into the model tree of the assembly.  One instance has a radii on an edge, one does not - this changes the reference surface enough where the parts are not completely replaceable with placement intact.  This is not my expectation, because i do not want the wrong instance in the model.  I want to set the placement reference on the correct instance and have it brought into the assembly...if this is the case the placement won't break.

    M
    MartinHanak24-Ruby III
    24-Ruby III
    October 20, 2015

    Chris,

    it is difficult to say what is going on, if I do not have your files.

    My personal rules:

    1.] do not use instance accelerators ... files with .xpr and .xas extensions ... you can disable them by config.pro option ... SAVE_INSTANCE_ACCELERATOR none

         you can delete existing  .xpr and .xas files any time

    2.] if you make any change in model containing family table, then run Verify and save model

    MH

    C
    ckorkuch1-VisitorAuthor
    1-Visitor
    October 20, 2015

    Thanks for answering.  I cannot share the files.

    what problems do the instance accelerators have?  Why are they enabled by default?  Why wouldn't verify happen automatically?  Is there ever a time when you wouldn't want to verify?

    I deleted .xpr and .xas, changed config pro, and went through the same changes and implemented verify then save.  The issue still happened.

    M
    MartinHanak24-Ruby III
    24-Ruby III
    October 21, 2015

    Chris,

    >>> I cannot share the files.

    If you want to find the root of the problem you can create test models and upload them using How to attach file when you Reply to a discussion.

    >>> what problems do the instance accelerators have?

    invalidity (user forgets to update them)

    >>> Why are they enabled by default?

    I do not know. It is current functionality.

    >>> Why wouldn't verify happen automatically?

    I do not know. It is current functionality.

    >>> Is there ever a time when you wouldn't want to verify?

    Verification is necessary when family table model is changed. It is logical from my point of view.

    MH

    K
    kpritchard1-Visitor
    1-Visitor
    October 21, 2015

    The best advice I can give is to construct the assembly.asm (Generic) using part1.prt (generic) and subassembly.asm (generic), using references that are available to all instances both parent and child.  Use the Family Table to define component references to the specific child instances for each parent instance...  don't "assemble them individually".  This is fundamentally different from the Solidworks Configurations approach, if a feature is not in the generic and all instances do not use it as a reference to place any.  Also, consider using Datum Axes, Planes etc for constraints as I find it makes for more stable models. 

    Things are falling apart when you open an instance model that uses different methodology/references for constraint.

    J
    JK_101338891-Visitor
    1-Visitor
    May 23, 2023

    Simply put, when defining constraints in assemblies that involve family tables, you must constrain parts to parts that are also active in that instance.

    L
    ldennis6-Contributor
    6-Contributor
    July 6, 2020

    I realize this is 5 years after you answered the question.... I came across this looking for something else. Were you using the Ref_Model option in the assembly family table? If not, adding the Ref_Model will allow you to specify which external model reference to use.

    Terms & ConditionsCookie settingsAccessibility statement