Need help with formula for door schedule...

[dgraue]

I am looking for help with a Formula for a Door Schedule. In this project we have created door tags by Type. Therefore, a mechanical room door would be tagged as 06a for example. This type of door occurs in the corridor of the building on Levels 1-5 and in parking levels P1-P3. We will need two schedules here...one for the parking levels and one for the building levels. Traditionally, we tag this door "B06a" in the upper building levels and "P06a" in the parking levels.

I would like to use one door for this, assigning the Type Parameter "06a". Then I would create a door schedule for "Building" and one for "Parking" and filter the levels I want to show in their perspective schedules. But, I do need to put a "B" in front of the mark for ""Building Level" doors and a "P" in front of "Parking Level" doors.

I was thinking I might be able to assign a formula to put a "P" or "B" in a column depending on what level the door is on. Is this crazy? Am I making this too complicated? I want to avoid duplicating the same doors for the sake of differentiating a "P" or "B" in the Type Parameter.

How are others handling this?
DG

[Dimitri Harvalias]

You needn't filter by the type parameter to differentiate between parking and building. You can just create another parameter or, unless they are on the same level, you can sort/filter by level.

[dgraue]

Now that I think about it more, I don't think I have a choice but to duplicate the door if I am going to use a Type Parameter Tag for the door type. When I tag the mechanical room door in the Parking Level the tag needs to read "P06a"...when I tag the mechanical room door on Level 2 the tag needs to read "B06a". And in turn, these "P" and "B" designations need to appear in the schedules too. I really need to assign a prefix to the doors' locations that would appear in the tag and the schedule as they relate to a particular level.

It would seem to me that I need to duplicate the door type in order to get the tags and schedules to read correctly.

[eddy.lermytte]

You can create the two schedules for the Doors by level and filter them choosing for the first one "is at or above" and for the second "is below"

[twiceroadsfool]

Why not use two different parameters for this designation? One as "DOOR LOCATION" (As a P or B), which could be a shared parameter (type), and would be the B or the P, and the other being the Mark value system parameter, which would still afford you the protections of having Revit check for redundancy? Then, you could make a tag that displays < DOOR LOCATION > < MARK> inside the tag, and you could even sort the two schedules by this value.

The one let down here is you cant havre a P01a and a B01a, as they will have the same Mark value... But there are several different methods for dividing up the numerals, if that bothers you...

[Steve_Stafford]

Sorry but I think that you've spent more time trying to avoid creating a new type... :wink: A new type resolves everything except having one extra type that is really identical to the other, small price methinks?

[dgraue]

Why not use two different parameters for this designation? One as "DOOR LOCATION" (As a P or B), which could be a shared parameter (type), and would be the B or the P, and the other being the Mark value system parameter, which would still afford you the protections of having Revit check for redundancy? Then, you could make a tag that displays < DOOR LOCATION > < MARK> inside the tag, and you could even sort the two schedules by this value.

The one let down here is you cant havre a P01a and a B01a, as they will have the same Mark value... But there are several different methods for dividing up the numerals, if that bothers you...

This is similar to the method we used. In our case, the tag was made up of two labels...the first part was an instance parameter and the second label was a type parameter. This allowed us to show the doors by type in the schedule but also allowed us identify this door type in the tag by floor with the instance parameter. This worked well for our needs with plan check.

DG

[twiceroadsfool]

This is similar to the method we used. In our case, the tag was made up of two labels...the first part was an instance parameter and the second label was a type parameter. This allowed us to show the doors by type in the schedule but also allowed us identify this door type in the tag by floor with the instance parameter. This worked well for our needs with plan check.

DG

Well, i dont advocate it, personally. Its a way to accomplish your initial goal, but IMHO it has some high prices. The moment you deviate from the system Mark value, to a Shared Parameter value, you no longer have the Door safeguard of Revit checking to assert that you have not used a door number twice. What ive had people do in this case is simply make the Door Mark value 1024 B. I then alter the door tag so that it wraps text after 4 digits, so in the tag i can still separate the 1024 and the B by a line in the annotation symbol, all the while maintaining the intelligence of the Mark value.

Weve had a couple of projects here where people alltogether replaced the Mark value with two shared parameters, and in every case it caused at least one problem down the line. IMHO, having to sit there and check door numbers one at a time is a problem.

Just something to think about...

[dgraue]

Well, i dont advocate it, personally. Its a way to accomplish your initial goal, but IMHO it has some high prices. The moment you deviate from the system Mark value, to a Shared Parameter value, you no longer have the Door safeguard of Revit checking to assert that you have not used a door number twice. What ive had people do in this case is simply make the Door Mark value 1024 B. I then alter the door tag so that it wraps text after 4 digits, so in the tag i can still separate the 1024 and the B by a line in the annotation symbol, all the while maintaining the intelligence of the Mark value.

Weve had a couple of projects here where people alltogether replaced the Mark value with two shared parameters, and in every case it caused at least one problem down the line. IMHO, having to sit there and check door numbers one at a time is a problem.

Just something to think about...

Tagging doors by type is something this developer client requires on their projects. However, we are not altering the Door Mark so if we need to schedule by Mark later we can simply change the door tag types to display the Mark.

Now, what we find very limiting is trying to use Schedule Keys in our door schedules when there are Groups in the project. When a door type is present in two or more different groups you can not make changes to the schedule key without editing each group, selecting a door and alter the schedule key parameters in the properties for each door. If you try to make changes in the door schedule you get an error requiring you to ungroup in order to proceed. Needless to say, people on the project filled in a good part of the schedule using text manually. This will be a problem later as doors change and the schedules are made up partly of non-associated text.

Will this be addressed in the coming release?

[twiceroadsfool]

Oh, i misunderstood. If youre tagging by type, and not by ID number, then i suppose the method i posted above would work.

As for the groups... It does require you to edit the groups, but once you do, you should only have to change the parameters (for the schedule key) of one door. For instance, for my tenant restroom i have a model group that has the Tenant Restroom Door in the group. I have a schedule key for all of the doors in the project, and one of the DOOR KEY values is "Tenant restroom door." So i Edit Group, select the door, and change the parameter value to the appropriate selection. Then, when i hit finish group, it changes ALL of the tenant restoom doors to that parameter, thus completing the schedule for all of my restroom doors.

The workflow is a bit odd (Edit group, select door, go to schedule, etc...) but once i got it down it works wonders. We have a schedule of about 300 doors, and we didnt have to manually fill in text for anything other than some of the te4xt parameters in the schedule key.