How to deal with system parameters in family templates??

[Anonymous]

Hello,

I am looking for a solution to deal with exisitng paramters in Generic Model family template. 

I appreciate any answer to any of these questions. 

1- Can I delete these parameters (e.g. manufacturer, model) ? How? 

or

2- Can I make them shared paramaters? How? (Revit does not let me create shared paramteres with the same names)

or

3- Can I make them instance paramters? How?

[L.Maas]

1- No. No deleting or renaming.

2- Most (All?) are shared parameters and can be used for scheduling/tagging.

3- No.

Some templates (e.g casework) have additional built in parameters (e.g height, depth, width). Those are type parameters. Some of those can be converted into instance parameters.

Basically it is not a bad thing. These are parameters that are available in every family. It is typically 'type' kind of information so not instance.

If for some special reason you need something slightly different you can alwasy add your own and name them slightly different (ModelNo instead of Model).

[Keith_Wilkinson]

We tend to append all our parameters with the company initials so there is no confusion as to which are ours and which are somebody elses - it just aids clarity.  This is in line with the ANZRS protocols that we tend to use for family creation.

as to the original question - yep, you're stuck with them I'm afraid.

[Alfredo_Medina]

I don't see the problem. These are useful parameters. They appear in schedules and they describe very essential properties of the family, such as "Model", "Manufacturer", etc.

[Keith_Wilkinson]

I would agree these are typically useful parameters but at the same time I can understand the desire to be in full control and have everything set up and named just how you want it.

[Alfredo_Medina]

Well, yes, I understand that. However, there's nothing we can do about it. There are several templates with built-in parameters which have the "modify" button inactive.

[Anonymous]

Thank you all for your replies. Yes they are useful and I actually want to use them, but as instance parameters. I want to be able to edit them easily from the properties window and treat them as instance, without the need to open the edit type window. 

[Keith_Wilkinson]

Sorry Alfredo, it's just you said you couldn't see the problem.  😉

But problem or not I think everyone, including the OP now will be fully aware that there is nothing that can be done about it. 🙂

[ToanDN]

---

@Anonymous wrote:

Thank you all for your replies. Yes they are useful and I actually want to use them, but as instance parameters. I want to be able to edit them easily from the properties window and treat them as instance, without the need to open the edit type window. 

---

I would question this approach.  Do you really want to repeat entering the same information over and over for the hundreds of same piece of equipment?

[Anonymous]

We don't know yet if we have same information. We want to collect information of assets in existing buildings, we know some parameters would be type parameters (e.g. omniclass#)but we are sure, for a freezer for example, we have many different models and manufacturers in many buildings we manage (built in 1920's, 60's, 90's, 2000's!)and creating types rather than instances would be more time consuming for our process. For this reason, we want to treat them as instances in one or two buildings and if we find that some model and manufacturers are the same across the assets, we make them types then. 

[ToanDN]

Well I guess you need to create different instance parameters then. Make sure to name them differently to avoid confusion later on. Also, once they are created, there is no going back. You have to re-enter the information if you somehow want them to be converted to Type parameters.