Family with nested families - use type catalog or lookup table?

[efoxSMI]

Hi.  I'm making a floor-hosted sleeve family with cylindrical shapes and a nested cylindrical shape.  The diameters will all be flexible and I need to make 4 individual sizes that report size, part number, length etc.  Would a lookup table or type catalog be best for this application?  Once I figure this simple one out I'll be making other assemblies that use quite a few more sizes.  Thanks in advance for any advice!

[timlove]

From someone who manages internal content, I prefer a lookup table because people keep doing things to break the type catalog features.   That said, when it comes to products that have part numbers and a great number of variation a type catalog is much easier to update and maintain than lookup tables (you need to open the family and load in an updated table to make any changes).  Type catalogs also make changes per type within a project, so if you have a one off that is using an odd size that you don't ever expect to use again it leaves that capability there.

Our sleeves use lookup tables based on conduit size and type.

Our electrical panel uses a type catalog because there are so many.

[iainsavage · Accepted solution]

If you only have 4 types then you could just create types in the family and avoid the complication of type catalogues or lookup tables.

Be aware that floor hosted families will only work if the floors are in your model - if the floors are in a linked model then the families won't find a host so you might want to consider using face hosted instead.

[andré_martins]

Use lookup table, after you are gonna understand this is a better way.

[iainsavage]

To my mind if you are controlling data by TYPE and particularly if you're going to have a lot of text/identity data depending on type then that is what a type catalogue is designed for.

BUT, type catalogues come into their own if you have many types in a family (say a whole range of radiators or fan coils etc). If you only have four types then you can just create four types directly in the family and save the hassle of a catalogue.

If you're controlling data based on SIZE (e.g. pipe radius/diameter drives other dimensions/data) then that's what lookup tables are designed for BUT you only need this method if the geometric relationships are not straightforward.

Even if they are not straightforward you can use if/then formulas, but if there are a lot of choices then the nesting in the formulas becomes complex and that's when lookup tables come into their own. Again though, if you only have four options then if/then formulas should be managable.

If dimensions are easily defined by formula e.g. dimension "x" is a multiple/ratio/addition/subtraction of pipe radius etc, then you don't need a lookup table.  

I think (not 100% sure) that you can also use a type catalogue AND lookup table(s) in the same family.

Overall though I'd say keep it simple until you need to add more complexity.

[efoxSMI]

This way was much more straightforward than what I was trying before.  I may be doing something wrong though because with the family in a project changing the family type in Properties doesn't apply the parameters of the new type.  Is that normal?

Edit: looking at the family type export txt file it seems like I could just save it as CSV and use it as a lookup table.  Is that correct?

[efoxSMI]

@iainsavageregarding my last reply I figured out the non-changing parameters (actually the internet figured it our for me).  I had my dimensional parameters set to instance instead of type.  Now they are working like I want.

Thanks so much for your thorough explanations!