family table of a skeleton to drive multiple components

[AE_9609989]

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?

[tbraxton]

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. 

[AE_9609989]

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]

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.

[AE_9609989]

Since the intent is to have three rails that have profile cuts that are different sizes, but the same shape.  Wouldn't the declared notebook parameters only be able to hold a single value at a time, meaning that I would still need a family table to vary the notebook parameters in order to create three uniquely sized profile cuts, right? (assuming that notebook parameters can even be controlled in a family table)

You're not missing anything, the rails are identical, I was using the opportunity to experiment with the mirror component command because I've had some odd behavior where mirrored parts that are asymmetric have mirrored into an incorrect orientation. I suspect it has something to do with how the original part is assembled since datum planes in creo have distinct front and back sides.  Mirrored components try to replicate the exact assembly sequence of the part being mirrored, causing one of the new location mates to flip orientation usually.  The result can be a part that was created by mirroring, but isn't symmetric around the plane used to create the mirror.

We had a notebook parameter puzzle here in the office yesterday actually.  An older model had a declared notebook associated with it.  We wanted to remove the declared parameters, so we undeclared the notebook, removed the references from the reference viewer in order to isolate the notebook itself.  Then we opened the list of parameters and tried to delete some of them. But when we tried this we got a notification from creo that the parameter was being referenced by the notebook file itself.

example error notation: "cannot delete parameter (parameter name), it is being referenced by (notebook file name)"

Any insight to why creo would be describing a self-referenced parameter in the notebook file itself?

[tbraxton]

This geometry example for the rail profile is so simple that a top down approach may not be faster than modeling the rails directly for 3 sizes. There are almost always options for how to capture design intent so you will need to assess what works best for you.

If you want to use a notebook to drive 3 sizes of rails you can do it from a single notebook. Lets call them 5, 10, 15 mm profiles for this discussion. You create the notebook to define the profile dims of interest for the 5mm size.

1) Create a generic rail design part (this part is for use in Creo to generate rail models for production)

2) Declare the notebook to the rail design part and use parameters to size the rail design part for 5 mm

3) Save a copy of the rail design part and name it 5 mm rail

4) Undeclare the layout from the 5 mm rail part

Modify the notebook parameter values for the 10 mm size

Repeat steps 2-4 above to get the 10mm rail model

Repeat for 15 mm rail

The same resultant models could also be realized by creating the 5 mm rail model and then just save a copy for each size and modify the profile dims to scale it up for all sizes. This assumes you can create relations that define the size of the rails based on the profile dims.  For this simple geometry this is probably the way to go. I typically use notebooks when I need to control many parameters across more than one model.

Regarding your notebook puzzle, check to see if the parameter is used in a note, relation, or table in the notebook itself. Any use of the parameter will prevent deletion. Unfortunately no search tools are available in notebook to run a where used query to make this easy.

[AE_9609989]

Ah,  it never occurred to me to declare the notebook and save a copy of the part before undeclaring the notebook. That almost gives you a sort of iteration design process.  I've seen something similar in our drawing templates where when you open a new drawing a pop up dialog comes up that asks you to type in a value that will be written to a parameter.  We use it for things like the name of the part, material, designed by.  Those sorts of things.

Then the mystery deepens. The notebook in question is a blank sheet, we removed all the tables from the sheet, no relations were specified, and no notes were included in the notebook. There are no part drawings that could reference the parameter either.  The notebook came from windchill, and was associated with a stock part model.  When we tried to undeclare the notebook from the model, creo told us that this was unnecessary because the notebook wasn't declared in the first place. This is supported by the fact that the none of the associated models pulled into the workplace use the parameter.  Still, we were able to find references to the notebook that we manually broke.  Even with all this, the parameter is still being referenced by the notebook itself and cannot be deleted.