Company shared parameters instance and type

[annepeter]

Hello everyone,

I'm in the process of setting up our company's shared parameter file. Consolidating all shared parameters we use (from different sources) into a single file for ease of access and avoid a wild growth of said parameters. As well as avoid potential conflicts or errors in the future.

Reason being I made the mistake of creating an IFC shared parameter instead of adding it from the already existing "IFC Shared Parameters-RevitIFCBuiltIn.txt". Which took me some searching and time to clean up.

During the proces of consolidating I came across the "IFC Shared Parameters-RevitIFCBuiltIn-Type.txt". In this file I see the exact same names but appended with [Type] in the name and of course different GUIDS.

This made me wonder if I should have a similar setup for our company's shared parameter file(s) and how others handle this?

Please correct me if I am wrong, but the way I understand it (after reading different posts and forums) is that:

• there is no way to know/see if a specific parameter was intended as instance or type unless it was specified in the name or description
• upon creating/adding a shared parameter to a project or family you get to choose whether they will be instance or type based.
• the instance or type choice is not exported to the shared parameter file.
• if a parameter with that GUID was added to the project as instance but to a family as type at an earlier stage (by myself, by a colleague, by another company we work with or content creators) then the setting inside the project will override the setting in the family.
• above can also create conflicts (or lack of information) upon exchanging models (or IFC files) with others.

Since I am using pre-existing shared parameter files from IFC, the national standard NLRS, and our software supplier as a base for our company's (and only creating new shared parameters if I can't find any pre-existing ones) this is already a daunting job.

Before I double-up on this task I wanted to confirm

Hope someone can help and thanks in advance,

[hmunsell · Accepted solution]

Wow, you’re really gonna have your work cut out for you. There are all sorts of things to consider. On top of the GUID, Shared Parameters, and Parameters in general, are case sensitive, "Volts" and "volts" can be 2 different parameters in the same file.

In order of your questions…..

• Without it being in the name or having a spreadsheet, No
• Yes, you specify its behavior when adding to a project or family
• Correct.
• I believe so ….
• Correct

Shared Parameter are not made as Type or Instance they are just parameters. You assign the Type/instance when loading it into a family or project. In my office, we used to have all sorts of issues with especially with vendor content. There naming conventions differed from our internal naming conventions. When we receive content, the BIM Coordinator is “supposed to” scrub the content and load “our” parameters as needed. This can cause issue though depending on how extensively the parameters are used in formulas, or not. There are several tools out there from different companies that will bulk load shared parameters into families.

I have a different Shared Parameter file for each major discipline (Mech, Arch, Elec, Struct & Process) and then one for Common stuff. Our mechanical department has the most. they took their parameters and made a spreadsheet denoting how they are to be used (see attachment). When adding parameters, they follow that spreadsheet to know how to load them.

[barthbradley]

FWIW:  Rushforth Tools for managing Shared Parameters.  

RushForth Projects

Try it. You might like it. 

...and, no; I'm not a paid spokesperson for the company.  Just a past and satisfied user of the product.  

[annepeter]

Hello,

I did look into Rushforth Projects but at the moment I do not have the option to extend our supplemental packages.

So for now it's manual work.

Thanks for the link.