Shared vs Instance Parameters

[ThinkRevit]

We all know that the main advantage of Shared Parameters is for Scheduling, but does not Sharing Parameters across multiple Families also optimize performance as opposed to two or more Families having their own Type Parameters with the same Name. If this is the case, why not make all Parameters Shared. Are there any advantages to Instance Parameters?

[Steve_Stafford]

You are mixing the concepts, or at least the use of the words.

Instance parameters are (can be) unique for each copy of a family you place in the project
Type parameters are consistent (the same) for each copy of a family you place in the project

A counter top family could use a Type Parameter for depth (30" or 36") so all 36" counter tops are the same depth. The same counter top could use an instance parameter for length so each counter can have a different length even though it is the same kind (type) of family, a 36" counter.

Shared parameters (SP) can be either Instance or Type when applied to a family or project parameter. The SP file is really just a dictionary that contains the definitions for various information that we want to use as a parameter.

It is not unreasonable to be inclined to always create and use a Shared Parameter when you start creating your own content. If you start with what the information "is" and how it is to be used, scheduled or tagged for example then you can start to address how best to deal with it. If you are designing cabinet families and someone expects you to allow them to schedule the width, height and depth then you'll have to use Shared Parameters to make it happen.

Btw, the parameters that Revit lets us schedule automatically are effectively "shared" too, they've just hardwired Revit to know that, like a door's width or height parameter. I call them system parameters because they are defined for us by the "system".

[jsteinhauer]

I'm bringing this thread back to life so hopefully your responses can help my write a intelligent RFI to our client for a variance. Also, I am hoping the in writing this I will solve my own problem.

I am doing an Enhanced Equipment Plan for our client to document much of their existing equipment that will be considered for replacement or directly transferred into our new building. I have a simple box family that I was using to document this equipment, with all of our standard parameters, plus some client requested parameter. Now, the family types are broken out by equipment name, so if i have a microscope, I call it out as "Mircoscope", or a centrifuge as a "Centrifuge". We are now getting to a point where we need to carry the Manufacturer & Model data for these items. Revit has these parameters hard coded into most, if not all, family templates as a Type parameter. This means if I have three different Manufacturers with three different Model numbers, I'll have 9 separate types, all with about 1-5 instances within the project.

Now, we are projecting about 4K items will be added to our model, so a total of about 5.5K equipment items. Should I expect to carry 1-4K different family types in my project browser, or take an alternate route. That being, create two new parameter for "Manufacturer" & "Model" as instance parameters. I see this as the most efficient option for workflow but downstream, will we be shooting ourselves in the foot? I don't like having Duplicate Parameters, cause it gets confusing for someone not up to speed on the project to understand.

So, what are my options? Use the Type, and muscle through it. Create duplicate instance parameters, and muscle through it. Come up with an ingenious solution, that we have not thus though up, and muscle through it.
What do I need to convey to our client, so that they can be happy with the final product, and will use as the baseline for projects in BIM moving forward?
Tell the Client, BIM wasn't meant for this?

Still stumped,
Jeff S.

[Steve_Stafford]

If instance behavior is what works for the generic content then, as you wrote, you need to consider using new Shared Parameters for Manufacturer and Model instead. I'd apply them as a Project Parameter instead of adding the parameter to the families themselves. This would let you assign the information in the project within schedules or the properties palette without editing all the families in the library too. When you create a project parameter you assign it to specific categories and Revit applies it to all the loaded components of that category, making the parameters available to schedules and the properties palette.

[Alfredo Medina]

... what are my options? Use the Type, and muscle through it. Create duplicate instance parameters, and muscle through it. Come up with an ingenious solution, that we have not thus though up, and muscle through it.
...

If I understand correctly, you are going to use a generic box that can represent a great variety of objects. Have you considered gathering all the possible combinations and creating a .csv file in Excel with all the possible variations of this basic box, with their names, dimensions, model, manufacturer, and other parameters? Would that help?

[jsteinhauer]

Loading in Shared Parameters as Project Parameters would be the game plan. No way in, well you know, would I add these to my standard content library.

[jsteinhauer]

If I understand correctly, you are going to use a generic box that can represent a great variety of objects.
Yes, you are 100% correct on your understanding of my current situation.


Have you considered gathering all the possible combinations and creating a .csv file in Excel with all the possible variations of this basic box, with their names, dimensions, model, manufacturer, and other parameters? Would that help?

Yes, I have thought about that, and it would make creating/loading them into the project much easier. We are receiving an .xlsx each week with 'Updates', and that will continue through the end of December. So creating an Type Catalog would be possible, but that doesn't help with loading up the model and managing potentially thousands of different Type definitions.

I'm waiting for Aaron to chime in and ask 'Why bother'. :)

Cheers,
Jeff S.

[Steve_Stafford]

I'd still make several generic families based on similar use so you can reduce the number of types that appear in a single family. They get quite cumbersome. Also make sure people do not use the Edit Family button or right click option if you do use Type Catalogs to establish/manage types (which I recommend). Having worked with a team for a healthcare project doing essentially the same thing it can turn into a major full time effort for at least one person.

[Steve_Stafford]

I was trading a couple emails with Jose Fandos of Andekan (http://www.andekan.com) about Manufacturer and Model being Type parameters. He shared a trick (http://www.andekan.com/blog/2011/11/28/system-parameters-vegas-style-type-or-instance/) in the past showing how to change system parameters from type to instance. We call it the Vegas Trick because were attending Autodesk University in Vegas when the subject came up at the bar (where else?). You didn't say which category you intend to use but on the surface it doesn't look like any categories don't have those two parameters. Jose noticed that in Revit 2013 the category Profile > Split Profile doesn't.

The process looks like this:

Add a value to each parameter
switch to Split Profile
parameters become editable
change to Instance
change back to the correct category
Now you can control them by instance

I've attached a 2013 version of a family that has been altered this way. Might be helpful if you haven't gone down the road too far?

[jsteinhauer]

Steve,

Thank you so much, I am going to try this tomorrow to see if I can get it to work for me. But, I have a feeling that I may have trouble finding a family category without Manufacturer & Model hard coded. :(

Still going to try,
Jeff S.

[Alfredo Medina]

...We call it the Vegas Trick because were attending Autodesk University in Vegas when the subject came up at the bar (where else?). You didn't say which category you intend to use but on the surface it doesn't look like any categories don't have those two parameters. Jose noticed that in Revit 2013 the category Profile > Split Profile doesn't...

Always something good comes out of those bars in Vegas, doesn't it? Interesting trick. Thanks for sharing.
I was not even aware of the existence of a "split profile" category. I guess from now on I will remember about that category only for this trick.

[dkoch]

I'm bringing this thread back to life so hopefully your responses can help my write a intelligent RFI to our client for a variance. Also, I am hoping the in writing this I will solve my own problem.

I am doing an Enhanced Equipment Plan for our client to document much of their existing equipment that will be considered for replacement or directly transferred into our new building. I have a simple box family that I was using to document this equipment, with all of our standard parameters, plus some client requested parameter. Now, the family types are broken out by equipment name, so if i have a microscope, I call it out as "Mircoscope", or a centrifuge as a "Centrifuge". We are now getting to a point where we need to carry the Manufacturer & Model data for these items. Revit has these parameters hard coded into most, if not all, family templates as a Type parameter. This means if I have three different Manufacturers with three different Model numbers, I'll have 9 separate types, all with about 1-5 instances within the project.

I suppose it comes down to what staff you have and how often an identical instance will occur in the same file. First, I assume that when you say three different manufacturers and three different model numbers, you mean that you have three different model numbers for each of three different manufacturers. If you only have one model for each manufacturer, then you only have three types. I also assume that you have 1 to 5 instances of each type, not 1 to 5 total instances (in which case you would not need nine types, either).

Both types have their place, and the example Steve gave of a counter is a perfect example of the best uses of both. Most projects on which I have had the pleasure of working have a limited number of counter depths (many only one, some two or at most three), but many unique instances where the length is whatever fits in the available space. So the counter depth parameter is ideally a type parameter, for which the maker can set up a type for each typcial counter depth. The length parameter, on the other hand, is ideally an instance parameter, unless your designers are a lot more regimented that than ones with whom I have worked.

If you are the only one who can create families for this project. there are plenty of team members who can enter data and the number of instances of a given manufacturer/model are always very small, then it may make sense to go with instance parameters, particularly if the other team members are fast and accurate when placing families.

But if the burden of type creation can be spread around to other team members (including, possibly, some of the placers), then setting up a type for each object and only asking that the user select the right type for a given instance will be far more efficient and accurate, especially if there are multiple instances of each type in the project. Setting up a type catalog can help ease that burden, as Alfredo suggested.

The problem with instance-based parameters is that you have to enter the value(s) for each placement. Are your length, width and height parameters also instance based? If not, are you using one set of dimensions that covers the maximum footprint of all nine possible "types"? For items with little variance from manufacturer to manufacturer, that may be acceptable. If there is only one instance per type, the data entry effort is the same and if both the family maker and the family placer are equally dilligent, it ends up being a wash. As soon as you have multiple instances per type, instance-based parameters become a burden in that the placer has to enter the data multiple times, increasing the odds of an error, or has to spend time trying to find another instance that already has the data that can be copied. I would not want to be either the person entering the data over and over for each instance, nor the person who has to review the resulting schedule to verify that there were no errors in data entry.