Criteria for Project Parameters vs. Shared Parameters

[jagostinho]

Hello,

I am wondering on what could be a good criteria to device on which type of parameter to create - Project vs. Shared?
I am aware of the differences. But am having a bit of a difficulty trying to distinguish why would I rather use a Project Parameter if I am already using a Shared Parameter file?


Many thanks for the feedback.
J.

[CADastrophe]

Sorry for the delay of response!

Shared Parameters are created and stored in a .txt file. They can be included in most Family Types, and can consequently be driven by formulas. They can be Scheduled in a Project and Tags can report information from a Shared Parameter within an element. A Shared Parameter may also be added to a Project a Project Parameter.

Project Parameters are added to a specific Project, but can easily be migrated to others. Upon creation, such a Parameter may be applied to one or more Categories, and it is consequently added to all elements of those Categories within the Project. Since Project Parameters exist only within the Project, there is no way to drive them with Formulas. Data from these Parameters can be schedule but cannot be reported with a Tag unless it is also a Shared Parameter.

(I know you said that you were aware of the difference, but I was just going over it again for anyone else who happens across this thread.)

It's a matter of what you need to achieve with the Parameter.
Should it need to be included in every or almost every element of the chosen Category?
- Yes? Then using a Project Parameter makes sense.
- No? Maybe adding a Shared Parameter in the specific Families will do.
Does it need to be Tagged?
- Yes? Then it's got to be a Shared Parameter.
- No? Then it can probably do as a Project Parameter.

I have even used a combination of Shared (non-Project) Parameter and Shared Project Parameters. I've added the Shared Project parameter and also added it to specific Families so I can drive it with a formula when convenient.

[Steve_Stafford]

To add to Corey's info...

Project Parameters are most effective when the information stored with them has no direct geometric impact on the families and categories they are associated with. For example if you expect the information to alter a family's size it can't be a Project Parameter, it needs to be established in the family directly.

One example of a Project Parameter could be the horsepower rating of a motor. A family might get larger when its design happens to provide more horsepower but that value alone seldom drives a specific dimension. A manufacturer will provide dimensional parameters for that and HP (horsepower) happens to increase as the capacity of the motor increases. That means if we create a Project Parameter for horsepower it can be applied to mechanical equipment, electrical equipment, generic model and other categories if desired. Every family that belongs to those categories will inherit that parameter without editing a family to add it manually. The project adds it to each family that is loaded.

Shared Parameters are like definitions stored in a dictionary. The Shared Parameter file (dictionary) provides a common single location to store parameter definitions we are likely to reuse. That means project parameters (and Family Parameters) can be created from a Shared Parameter (definition) stored in the dictionary (shared parameter file) or just created and stored in an individual project.

As soon as we want to create a parameter in families, a project AND then tag or schedule the information we must create and use a Shared Parameter.

[jagostinho]

Many thanks for the clarifying replies.
I was lacking to find those clear-cut explanations on the web.