Skip to main content
A
AE_96099891-Visitor
1-Visitor
February 1, 2021
Question

family table of a skeleton to drive multiple components

  • February 1, 2021
  • 1 reply
  • 2912 views

Hello,

I'm modeling a set of rails for a part holding fixture that I'm designing.

I have three different part sizes that I need to accommodate, but the shape of the part does not change.

 

I modeled the rails using a top down methodology referencing a generic skeleton instance.  I thought I would be clever by then making family instances for each of the needed sizes. Since the reference surfaces don't change, only the dimensions.  I figured that in each assembly the rails would update on regeneration to match the skeleton instance.  But this isn't the case, the references are still tied to the generic, and any attempt to re-reference brings up a warning that I have external references that I'm breaking. That must mean that the parts can only be referenced to a single instance of the skeleton at one time, which suggests that I need a family table for each rail as well.

 

That brings me to my question, what's the point of family tables if I have to practically remake the assembly 3 times anyways? I would have better control just making three distinct assemblies and avoiding the hassle. Is there a way that I can drive the two rails from a single skeleton having multiple instances? Or do I absolutely have to have instances of each rail to match the skeleton instances?

1 reply

tbraxton
22-Sapphire II
tbraxton22-Sapphire II
22-Sapphire II
February 1, 2021

I would not generally use a family table of a skeleton model as my first choice to do this but I think it is possible. I am not espousing this as best practice and will wait for comments from others on this approach.

 

The component part table needs to include instructions for which instance of the skeleton to be used in creating the part.

Place the skeleton model into the family table of the component part and specify which instance to use during  regeneration of the component part. It will be a column labeled something like "Reference Model" then you will have the control you want.

 

I think others may chime in here after reading this about nesting family tables this way may cause more trouble than it is worth especially if you are checking this data set into Wind Chill. 

 

 

A
AE_96099891-VisitorAuthor
1-Visitor
February 1, 2021

what would be your first choice, given what you know about my design intent?

I ended up making each rail component and driving the dimensions of an extrusion feature through my family table.

Since each rail was going to be symmetric around a shared part profile, I thought maybe a skeleton might help me out, but I'm sensing the same thing you hinted at.  It's more trouble than it's worth.

tbraxton
22-Sapphire II
tbraxton22-Sapphire II
22-Sapphire II
February 1, 2021

I would tend to lean toward minimizing the dependency chain (# of external references) while still capturing intent.

 

Taking a swag based on the profile geometry in your posted model and knowing you can't use multibody models. I would create a Notebook (.lay file) that  defines the profile dimensions and declare that to one rail model and build the rail using the layout parameters to drive the section. You can also use the layout to define the assembly references of the rail for automatic assembly. The rails look identical, so it is not clear why you have a left and right model unless I am missing something.

 

If the rail needed to be mirrored for the matched set then I would then mirror that rail (mirror the part) to get the matched pair. File-> Save As-> Mirror Part.

 

This way you can use the layout to scale up/down the profile should you need to to create a matched set of rails of any size based on the same architecture.

 

You can undeclare the layout if you want to once the rails are built/configured to minimize external refs.

Terms & ConditionsAccessibility statement