PDA

View Full Version : Why are Share Parameters So Selfish



stuntmonkee
2009-09-16, 06:52 PM
OK, I'm drowning in a bit of parameter paradox and thought, maybe if I write it down it will clear up. Then thought maybe I could turn it into a support group ;)

I'm perfectly clear on the whole shared parameter deal (at least I thought), but have recently been chasing my tail a little.

I'm new to this firm, so the difficult part has been trying to seperate what was done with intent, what was done with out knowing any better, and what was done correctly but different than what I would have done.

SO. . .on to the details.

I'm going to pertain this to doors.

1. Medium sized firm started in Revit a short time ago, and had several doors created for them.
2. Large projects, obviously required more doors than what they had available.
3. All the projects use links
4. The firm is just now getting into heavily scheduling the doors
5. Working with a contractor that is requesting additional information out of the model beyond the standard parameters.

This has dropped us into a situation where we have several shared parameter files. Some of those shared parameter files have the same parameter name and have been loaded into door families once from each parameter file. Some of the shared parameter files have been lost, some have never been used, and some just don't make sence. Then to top it off we have a plethera of project parameters.

Example:

By default, each door comes with a "Fire Rating", we all know that, but for some reason when those "several custom doors" were created, a shared parameter of DR Label was added to the family to display the same info. That was done either by request of the firm, or with the intent of being used differently. But where we stand now, they are they same.

So now we have 2 parameters, saying the same thing, in different spots. The bigger problem is that the doors that only have the Fire Rating need the DR Label added so we can fill out the schedules. So I add the DR Label Parameter from the shared parameter file that I think it was same shared parameters file that the other door used, just to find out that it wasn't, meaning it won't schedule with the other information even though its the same exact name. Good Grief.

OK, so now. . . .thats where I stand. My first instinct was to start eliminating the shared parameters that are not family type specific and making them project parameters.

Meaning, for Head/Jamb/Sill details, that is something that changes in each location in each project, so we can create those as a project parameter and not have to worry about which family does or doesnt have a parameter or where it was created from.

My next step (and I think I know the answer already), is to test project parameters with linked files. . . .Pretty sure project parameters can not be scheduled when they are linked. . . .correct?

Which sends me back to having to use Shared Parameters. . . .but!!!!

How do you consolidate and clean up a mess of shared parameters? If you saw the parameters assigned to rooms right now, you would cry.

I feel like I'm standing in a my bedroom when I was 9 years old, the room was a complete mess, Mom told me to clean it up before I could go play, and it's such a wreck that I have no idea where to start.

Ya know?

Thoughts,
Stunts

wmullett
2009-09-16, 07:25 PM
Sounds like you need to have better control over the children ... and I know that is hard to do.

We are working very hard at qualifying families to meet our standards. When we do that, we add our initials in front of the family name. Then - we insist that except when authorized, the user must look for our family first. And we control the library!

Look - it doesn't matter what shared parameter file is used when the family is created. Just that you have one that matches. I would create an office file that is the way you want it. Then you will have to open each offending family and re-assign those parameters. Not fun - especially if you have nested ones. In that case you have to work fronm the host down.

BTW - better to clean up your act now before it gets any worse.

cdatechguy
2009-09-16, 09:09 PM
LOL!!!

Stunt....if you didn't say you are in Phoenix I would swear your talking about me!

Yes, the duplication of some build-in parameters is a pain in the you know what! But was necessity. Think of this way....Fire Rating....its a type parameter for some reason.....works a lot better if its an instance parameter.

As for the multiple shared parameters file....yeah, I try to keep just one file. I had an issue where I had created a lot of doors but set up the wrong info for it....so I recreated and then had two parameters with the same name....one text and one material. Then I had fun because I named the parameters something like door-materal....try using that in an equation. :|

Probably a lot of work.....but get all those families utilizing the same parameter file. I keep the head/sill/etc parameter instance in the family instead of the project because shared parameters stay with the family.....project parameters can be accidentally purged. (happens)

Oh....shared parameters follow the family....so you should load the parameters in the current model, not add them from the parameter file, unless its a parameter tied to title block....why those don't follow the titleblock still irks me.

Room Parameters....lol....your not in Phoenix are you?

stuntmonkee
2009-09-16, 10:13 PM
LOL!!!

Stunt....if you didn't say you are in Phoenix I would swear your talking about me!

Yes, the duplication of some build-in parameters is a pain in the you know what! But was necessity. Think of this way....Fire Rating....its a type parameter for some reason.....works a lot better if its an instance parameter.

As for the multiple shared parameters file....yeah, I try to keep just one file. I had an issue where I had created a lot of doors but set up the wrong info for it....so I recreated and then had two parameters with the same name....one text and one material. Then I had fun because I named the parameters something like door-materal....try using that in an equation. :|

Probably a lot of work.....but get all those families utilizing the same parameter file. I keep the head/sill/etc parameter instance in the family instead of the project because shared parameters stay with the family.....project parameters can be accidentally purged. (happens)

Oh....shared parameters follow the family....so you should load the parameters in the current model, not add them from the parameter file, unless its a parameter tied to title block....why those don't follow the titleblock still irks me.

Room Parameters....lol....your not in Phoenix are you?

hehe, I am in Phoenix, which has been a bad thing for the last 3 months, but looking forward to the next 9 while most of you enjoy the snow.

Yeah, makes sense on the Fire Rating, not sure why I didnt recognize that. . .but as far as purging. . .I'm pretty sure that a purge wont remove parameters being used in a project? As far as I know you must remove it from the schedule AND tell it to no longer apply to any of the catagories. . .at which point it warns you that you will be erasing any information assigned to it.

Here's the list of why I personaly use shared parameters.

1. You need to tag it
2. You want it to come in to a project with preset information (Standard door elevation, Standard Frame elevation)
3. A yes no parameter that you may want to schedule and effect a parameter in that family (ADA visablility)

But after that, I don't think it is required to be used anymore.

Fire Rating - Varies at each door through out the project (Project Parameter)
Detail information - Project Parameter
Calculated schedule info - must be a project parameter

Really for me, the only kink is when we have a linked file. . . .messes up the whole system. DRAT!

Question : If I a shared parameter has been erased from the parameter file, and then needs to be added to a new family, is there a way to make it work with out removing the parameter from the existing families? I've tried pulling it from a back up version of that shared parameters file and didnt seem to work. Pretty sure the answer is NO, but when you don't have fruits to choose from you have to look at weeds.

Stunts

stuntmonkee
2009-09-16, 10:21 PM
Also, why will Revit allow us to change system family length parameters from type to instant, but not text parameters? Meaning, Height and Width start out as type parameters, and you can change them to instant.

stuntmonkee
2009-09-17, 04:17 PM
Sounds like you need to have better control over the children ... and I know that is hard to do.

We are working very hard at qualifying families to meet our standards. When we do that, we add our initials in front of the family name. Then - we insist that except when authorized, the user must look for our family first. And we control the library!

Look - it doesn't matter what shared parameter file is used when the family is created. Just that you have one that matches. I would create an office file that is the way you want it. Then you will have to open each offending family and re-assign those parameters. Not fun - especially if you have nested ones. In that case you have to work fronm the host down.

BTW - better to clean up your act now before it gets any worse.

Keeping things in check moving forward isn't the tough part, but cleaning up issues in the past is what is becoming difficult. And when you say

"Look - it doesn't matter what shared parameter file is used when the family is created. Just that you have one that matches"

Clarify that a little for me.

Thanks
Stunts

Steve_Stafford
2009-09-17, 04:40 PM
Also, why will Revit allow us to change system family length parameters from type to instant, but not text parameters? Meaning, Height and Width start out as type parameters, and you can change them to instant.

When you apply a parameter (label) to a dimension that uses the stock parameters for width, length, height etc... you can change them from Type to Instance.

Select the dimension string and look at the Options Bar, there is a Check mark for Instance Parameter, check it.

It is a back-door sort of since you can't do it in the Family Types dialog.

Steve_Stafford
2009-09-17, 04:42 PM
..."Look - it doesn't matter what shared parameter file is used when the family is created. Just that you have one that matches"...Clarify that a little for me?If you have the family you can Export its Shared Parameter to your SP file. You can also cut and paste from one SP file to another as long as the GUID value is not the same as another...not likely but you never know. This gives you the same SP for use elsewhere or to replace another incorrectly defined parameter.

cdatechguy
2009-09-17, 04:55 PM
I try to keep the project parameters to a minimum.....ever notice that shared parameters don't show up there but they show up when your creating your schedules and such?

Now with our template I have added quite a few parameters for our Interiors Department. Mainly the Room parameters, and my guess is your office calls out the same things we do. Whether they are a shared parameter or project parameter, doesn't make a difference, as they populate in the same list. The reason I went with shared though is so that the setup of the parameter would be the same for all projects. There would be no error in the name....such as Room_Finish is totally different from Room_finish.

Keeping everything the same is why Shared Parameters are better than Project Parameters....Its like keeping a library of office standards.

stuntmonkee
2009-09-17, 07:49 PM
When you apply a parameter (label) to a dimension that uses the stock parameters for width, length, height etc... you can change them from Type to Instance.

Select the dimension string and look at the Options Bar, there is a Check mark for Instance Parameter, check it.

It is a back-door sort of since you can't do it in the Family Types dialog.

Right, I know you can do that, but you cant do it with the Fire Rating Parameter

stuntmonkee
2009-09-17, 07:50 PM
If you have the family you can Export its Shared Parameter to your SP file. You can also cut and paste from one SP file to another as long as the GUID value is not the same as another...not likely but you never know. This give you the same SP for use elsewhere or to replace another incorrectly defined parameter.

MONEY!

Thanks Steve. . . .been a while!