RFO Blog: Using Shared Instance Parameters from nested families
Following up on this post, I played around with the family posted there. Snowwyweston was working on a sort of Facility Management family designed to keep track of hard- and software in his office, image 1.
The family exists of two components:
1. The parent family: WORKSTATION_QUERY.rfa.
This family contains a solid box which represents a pc. It has some parameters attached such as the dimensions (off course) and hardware specs. It also contains the nested SOFTWARE family, image 2.
2. Child family: SOFTWARE.rfa.
ThThis family contains a bunch of shared parameters, all instance parameters. These are yes/no parameters defining what software is installed, image 3.
His question was: how do I get the parameters from the nested software component into the parent family? Do I really need to link them all to a new parameter in the host family?
General rule of thumb until recently when using SHARED nested components:
Type parameters can be accessed through the project, instance parameters need to be tied to the parent in the Family Editor. This means you can do either one of two things:
1. Use Type Parameters. Which creates an humungous amount of family types.
2. Recreate all the child parameters in the parent family. This in turn has two disadvantages:
a. It’s a lot of stupid work.
b. It presents you with a totally unusable parent family. The given example is in fact not that hard. Wait until you need to do this with a door family with nested frame, panel, 2d symbols and so on.
My first idea was:
Tie both families together using a Mark parameter of some sort. For instance a text parameter. To do this, open both families. Start with SOFTWARE.rfa. Open the Family Types screen and click “Add”. Now add a Shared Parameter, “WS_code”, which is an Instance Text parameter see image 6. Load SOFTWARE.rfa into WORKSTATION_QUERY.rfa.
Next step: create the same parameter in WORKSTATION_QUERY.rfa: create the shared parameter WS_code. After this, select the nested family SOFTWARE.rfa and tie the WS_code parameters together, image 5. Load the parent family WORKSTATION_QUERY.rfa in your project.
Now create a new Specialty Equipment Schedule. Add the fields as displayed in image 6. Include the Family And Type, WS_code and all software needed.
At first I thought I nailed it. Task completed, take a beer to celebrate. Then I tried to set one of the No-parameters and change it into Yes. No luck there, the parameters aren’t accessible. To be honest, this kind of confused me. I have developed some workflows (regarding calculating the ratio between egress length and clear door width) which uses instance shared parameters from nested components in the project environment. But according to this, and the above rule of thumb, that shouldn’t be possible. So what’s the trick…?
Well, it’s mindblowing simple: you need to manually import the Shared Parameter into the project. To test this, I went to Manage > Project Parameter > Add and added the parameter “3D Max 2012”, see image 7.
See the result in image 8: SOFTWARE.rfa is still not accessible BUT the Parent Family WORKSTATION_QUERY.rfa is!
(btw: the value of the Yes/No parameter is set to . See this blog post to explain about that. For now, note that you’ll need to click it once to “activate” the parameter and once again to set it to “NO”.
This made me wonder, is this just project-based? So I looked up the family in 3D and selected it. To my surprise, the Shared Instance Parameter from SOFTWARE.rfa is now incorporated in the Parent Family WORKSTATION_QUERY.rfa and it’s also accessible through the Properties, image 9.
After this, I opened the family WORKSTATION_QUERY.rfa in the Family Editor. Here, the parameter “3D Max 2012” is still absent, which to me, is just what I would expect. Recapping, there are now TWO ways of using Instance Parameters from Nested Shared Components in a Family:
1. Recreate all Instance Parameters in the Parent Family and link through the parameters.
2. Import the Shared Instance Parameters into your Project.
The beauty of this all is that you don’t need to choose either one of them. You can choose by parameter which method you want to use. Some pointers though:
Method 1: use this when you need to drive the Child through the Parent. For instance when the size of a Child Family depends on features from the Parent Family.
Method 2: use this when the Child Family Parameter is only used to define data, which is the case in this example. Whether a specific software is installed is not defined by anything in the workstation. So you can use this method to keep the Parent Family relatively simple and NOT have a few dozen extra parameters in your Parent Family.
But what’s the benefit of having two methods? Why not simply import the shared parameters in the Parent family? Well, again there are a number of reasons:
1. Useability of the Parent Family. When you look at this Family you’ll notice that both the Parent and the Child Family have a huge amount of parameters in them. Adding the SOFTWARE.rfa parameters to the WORKSTATION_QUERY.rfa would make this rather impossible to use, also because there still is no way to change the order of the parameters listing.
2. When the parameters exist in your Project Template you can very easily setup a Facility Management Template:
a. Create a new template or copy the existing one you have for Design work.
b. Import the shared parameters used in SOFTWARE.rfa.
c. Create an empty Project and link it into the FM Template file. Save this.
d. Set all schedules you created for FM to “include elements from linked files in the Properties > Field tab.
e. Now if you have a project in which you want to do FM, open the template as a new project, Go to the Manage Links screen and use Reload From to assign the correct Project File.
Happy Reviting…
Click here to view the entire blog post.
The family exists of two components:
1. The parent family: WORKSTATION_QUERY.rfa.
This family contains a solid box which represents a pc. It has some parameters attached such as the dimensions (off course) and hardware specs. It also contains the nested SOFTWARE family, image 2.
2. Child family: SOFTWARE.rfa.
ThThis family contains a bunch of shared parameters, all instance parameters. These are yes/no parameters defining what software is installed, image 3.
His question was: how do I get the parameters from the nested software component into the parent family? Do I really need to link them all to a new parameter in the host family?
General rule of thumb until recently when using SHARED nested components:
Type parameters can be accessed through the project, instance parameters need to be tied to the parent in the Family Editor. This means you can do either one of two things:
1. Use Type Parameters. Which creates an humungous amount of family types.
2. Recreate all the child parameters in the parent family. This in turn has two disadvantages:
a. It’s a lot of stupid work.
b. It presents you with a totally unusable parent family. The given example is in fact not that hard. Wait until you need to do this with a door family with nested frame, panel, 2d symbols and so on.
My first idea was:
Tie both families together using a Mark parameter of some sort. For instance a text parameter. To do this, open both families. Start with SOFTWARE.rfa. Open the Family Types screen and click “Add”. Now add a Shared Parameter, “WS_code”, which is an Instance Text parameter see image 6. Load SOFTWARE.rfa into WORKSTATION_QUERY.rfa.
Next step: create the same parameter in WORKSTATION_QUERY.rfa: create the shared parameter WS_code. After this, select the nested family SOFTWARE.rfa and tie the WS_code parameters together, image 5. Load the parent family WORKSTATION_QUERY.rfa in your project.
Now create a new Specialty Equipment Schedule. Add the fields as displayed in image 6. Include the Family And Type, WS_code and all software needed.
At first I thought I nailed it. Task completed, take a beer to celebrate. Then I tried to set one of the No-parameters and change it into Yes. No luck there, the parameters aren’t accessible. To be honest, this kind of confused me. I have developed some workflows (regarding calculating the ratio between egress length and clear door width) which uses instance shared parameters from nested components in the project environment. But according to this, and the above rule of thumb, that shouldn’t be possible. So what’s the trick…?
Well, it’s mindblowing simple: you need to manually import the Shared Parameter into the project. To test this, I went to Manage > Project Parameter > Add and added the parameter “3D Max 2012”, see image 7.
See the result in image 8: SOFTWARE.rfa is still not accessible BUT the Parent Family WORKSTATION_QUERY.rfa is!
(btw: the value of the Yes/No parameter is set to . See this blog post to explain about that. For now, note that you’ll need to click it once to “activate” the parameter and once again to set it to “NO”.
This made me wonder, is this just project-based? So I looked up the family in 3D and selected it. To my surprise, the Shared Instance Parameter from SOFTWARE.rfa is now incorporated in the Parent Family WORKSTATION_QUERY.rfa and it’s also accessible through the Properties, image 9.
After this, I opened the family WORKSTATION_QUERY.rfa in the Family Editor. Here, the parameter “3D Max 2012” is still absent, which to me, is just what I would expect. Recapping, there are now TWO ways of using Instance Parameters from Nested Shared Components in a Family:
1. Recreate all Instance Parameters in the Parent Family and link through the parameters.
2. Import the Shared Instance Parameters into your Project.
The beauty of this all is that you don’t need to choose either one of them. You can choose by parameter which method you want to use. Some pointers though:
Method 1: use this when you need to drive the Child through the Parent. For instance when the size of a Child Family depends on features from the Parent Family.
Method 2: use this when the Child Family Parameter is only used to define data, which is the case in this example. Whether a specific software is installed is not defined by anything in the workstation. So you can use this method to keep the Parent Family relatively simple and NOT have a few dozen extra parameters in your Parent Family.
But what’s the benefit of having two methods? Why not simply import the shared parameters in the Parent family? Well, again there are a number of reasons:
1. Useability of the Parent Family. When you look at this Family you’ll notice that both the Parent and the Child Family have a huge amount of parameters in them. Adding the SOFTWARE.rfa parameters to the WORKSTATION_QUERY.rfa would make this rather impossible to use, also because there still is no way to change the order of the parameters listing.
2. When the parameters exist in your Project Template you can very easily setup a Facility Management Template:
a. Create a new template or copy the existing one you have for Design work.
b. Import the shared parameters used in SOFTWARE.rfa.
c. Create an empty Project and link it into the FM Template file. Save this.
d. Set all schedules you created for FM to “include elements from linked files in the Properties > Field tab.
e. Now if you have a project in which you want to do FM, open the template as a new project, Go to the Manage Links screen and use Reload From to assign the correct Project File.
Happy Reviting…
Click here to view the entire blog post.