Using formulas to switch out nested families with label parameters

[Anonymous]

Hello, I see this opportunity to lower the number of family types our designers have to sort through quite often but am not sure if or how it can be done.

I model furniture to be used by our designers at my interior systems company and there are slight variations to many of the tables and booths they have to choose from. some of these slight variations include the support type being a core drill or clip down support or a leg being just a leg or a caster. All of these are usually modeled separately and nested into table and booth families. We will then make a type catalog of all the different combinations, with a couple of our type catalogs containing close to 500 different types of the same size table that will have different finish and support options.

See attached picture

What I am trying and would like to do here is have the check boxes control the support family that is nested in this eating counter so that I can write formulas for the check boxes and make all the different configurations of heights and support types as easy and checking the desired box. checkbox formulas are easy enough but I started playing with a formula in the support's label parameter that went something like this: 

if(and([Cored/Clipped], Standard, Privacy Panel) "Support - Cored HC Eating Counter Support : Cored Counter Support + Privacy Panel - Standard Height – NC", "Support - Cored HC Eating Counter Support : Cored Counter Support + Privacy Panel - Counter Height – NC")

I know the formula would be pretty long but that's not an issue for me because it's my job to make these easier to use for my design department but I'm not sure if something like this is even possible. If anybody knows anything about this or if this could possibly be implemented in a future update.. or someone could explain to me why this won't work, my department would appreciate that. I hope I sufficiently explained myself and thank you in advance!

[barthbradley]

You can't control the Family Types Parameter that way. You could directly nest all the families in the host and then use formulas to control which one is visible.

...almost sounds like you need a LOOKUP TABLE.  Know what I mean?    

...The thing is, the Type Catalog is unidirectional. It's just entering predefined values into fields. It's not evaluating any other field contents.   That's what you need here.  That's where I was headed when I mentioned Lookup Table.   I don't know whether or not it's doable though.  

[Anonymous]

I am not familiar with lookup tables. My company has been having all the different support types in their own families since before I was here and they all have unique part numbers specified by their different families, perhaps that is something I can suggest we look into.

[barthbradley]

Are they are using a Type Catalog that define every possible configuration?  

[bin]

I don’t think your if() formula will work here. 

For example, if(and(a=1,b=1,c=1),d=1,d=0) means only when a=1,b=1 and c=1, d=1 ,otherwise d=0. 

For different options of a,b, and c (either 1 or 0) you will need something like if(and(a=1,b=1,c=1),d=1,if(and(a=1,b=1,c=0),d=2,if(and(a=1,b=0,c=1),d=3,if(and(a=1,b=0,c=0),d=4,if(and(.......)))))))) something like this. 

I think it’s too much for a formula. 

Another idea of mine is to have those family in place with individual visibility parameter. Then you can just use some and() condition for them, just like what did under the construction category. 

Only my thought, too early get out of my bed. 

[Anonymous]

Yes, because there are so many different configurations that all need to schedule different part numbers so the type catalog will specify which support to use and the supports can have different finishes, additional cladding, heights, ADA offsets, etc. Aside from the maintenance of updating all the previous families and if we were to hypothetically start doing this now, the number of formulas required to make some of the supports interchangeable to some extend for our design department would slow down the functionality of the families. I'm thinking for example of the eating counter I'm referring to in this post, the support would have a height parameter which would control the top of the support, adjusted by checkboxes for standard height, counter height, and bar height; another height parameter that would control the bottom of the support controlled by check boxes for clipped support or core drill which would set the support 4" into the ground; a visibility, formula controlled for when clip down is selected, for the clip down plate, and a part number formula which would lay out all the specifications the support needs to meet to be a part certain part number, which would be different for all of those options. And that doesn't consider ADA offsets, different finishes - which can't be controlled by formulas, and any number of things that I might not even know about.

[Anonymous]

The issue for using visibility parameters is that the supports are already controlled by visibility parameters to automatically place the supports as the length of a given table changes and to my knowledge you can't assign more than one visibility parameter to anything without giving everything is own visibility parameter controlled by checkboxes controlled by formulas that set up a specific circumstance. If you know what I mean.

[bin]

As English is my second language, I do have issue understanding what you want to do here. If you can provide a simple example or a family file to look into, that would be great.  🙂

[Anonymous]

I have two screens so I was just too lazy to make to snips but I believe you should be able to zoom in on the picture if need be as I was, but this is an example of our type catalog for only one type of cored support (right) and the counter I keep referring to in this post (left). Not all of our type catalogs are this lengthy but it definitely does get a lot bigger. This is why I would prefer a way to do what I was asking about in the initial post, use a formula to change out the nested family types as I don't believe it would ever reach the point where we'd be using a formula to change out 70 different types, for the eating counter, it would just be 8 different supports, only 4 of which would be in the support catalog shown on the right. I hope this is what you were looking for. At this point it doesn't sound like its currently possible so if anybody knew why I can't just enter a conditional if-then statement as text and as long as the quoted text is correct it would insert that result into the label parameter shown in the first shared image, maybe I could look for another way around it or if there isn't really a reason, maybe it could be implemented in the future.

[ToanDN]

Why don't you create all the necessary types and select the correct nested family types for them via labels so that your modelers can pick them?