Scheduling Doors and Frames

[dbaldacchino]

Hi folks,

Here's what I'm after. I'd like to see if anyone can shed some light on whether this is possible or if I should just give up :(

We typically have a lot of different frame types. If a window configuration has a door in it, we designate it as a door frame type. So in a large building, you end up with lots of frames containing perhaps a handful of different door panel types.

In Revit, door families have a unique Type mark. If you use the same mark for a different type, you get a warning, which is great. I'm trying to get the same effect for "Frame" types.

I've tried nesting families together (making them shared), but I don't think it's possible to schedule them on the same line (for instance showing door 101 info on the same line, ex: Wood, Flush, 3'-0" width, 7'-0" height, frame type 1, etc). A door family has a frame type parameter, but it's just a text instance parameter. I'm trying to think "assembly"....model the frame and door assembly once and any representation will be consistent in the entire document set (schedules, elevations, legends). I don't want to model a frame & door assembly and then resort to manually assigning frame types, as that's what traditionally leads to mistakes. So I have tried nesting door families consisting of a family for the door panel and another for the frame (similar to the AU2005 Lab BD21-1L by Steve Stafford and David Conant) and then assigning a family type parameter in the host family to be able to select different Panels within the "assembly".

For example, I would create the following assemblies:

a) Door1 with Frame 1
b) Door1 with Frame 2
c) Door2 with Frame 1
d) Door2 with Frame 2

When I use any of these assemblies, I would like to get this info. in the schedule as shown above. If I create a new frame type and assign its Type Mark as Frame 1 or Frame 2, I would want to be warned just like when I create another door type using an existing door type mark. With the nesting method discussed above, this actually happens. My problem is in scheduling though. A frame shows up as a separate row with its Type Mark (which I'd like to see scheduled under the heading "Frame Type"). Doors also show on a separate row with its Type Mark (which I'd like to be scheduled under the heading "Door Type"). Can these two be combined on the schedule as one "assembly"?

I'm thinking that to achieve this, we might need a "Frame" family. And, some special type of schedule that would show Door family parameters and Frame family parameters on the same row.

I'm trying to use Revit as an information management database. I don't want to resort to manual drafting techniques as this would really make no sense (or little sense) in justifying a switch from, say, ADT. Any comments/tips/tricks? Thanks!

[Shaun v Rooyen]

David,

We simply create many door panels to one type of frame.
so:

Frame A = Door Panel 1
Door Panel 2
Door Panel 3.... etc


Frame B = Door Panel 1
Door Panel 2
Door Panel 3.... etc

All the info is stored in the family.

Here is a simple example of how we deal with it.

[dbaldacchino]

Thanks for the example file Zed.

It seems that you guys have a lot more emphasis on the door panel itself. On the other hand, what I'm trying to solve is an emphasis on lots of frames with very few door types. I want to make sure we don't have to spend a lot of time trying to coordinate manually, which is what we traditionally do (and with Revit we shouldn't, right?).

I'm after "assemblies". My problem is that the door family only accounts for one unique Type Mark. To achieve what I'm after, you need two unique type marks....one for the frame and one for the door panel. The door family would perhaps be more of a frame family with nested door families and the user selects a door panel (using family parameters would give the user the option of selecting from available door types from a drop down). The problem is that I cannot schedule this "assembly'" in one row. I hope I'm explaining myself well enough! If anyone doesn't understand what I'm trying to convey, please drop a message so I can perhaps post some material.

Thanks again!!

[Scott D Davis]

In your example:


a) Door1 with Frame 1
b) Door1 with Frame 2
c) Door2 with Frame 1
d) Door2 with Frame 2
Wouldn't the "a" above be tagged with Type Mark A, and "b" tagged with Type Mark B, etc? You say that each door/frame needs to be tagged individually, but wouldn't each 'assembly' get a unique tag?

Trying to understand your situation.....

[dbaldacchino]

I apologize for not being clear enough...I'm finding it hard to put in words!

Ok, in a door family, you have a unique type mark. If you create a new type, insert it in a project and assign the same type mark , you get a warning. So far so good.

If I deal with a lot of different frame types, I would like to have a type mark for frames that would also give me warnings if I create a new type and use an already existing type mark. I guess this would only be achievable if we have a "frame" family (wish list item?). So, I'm thinking I should use the door family more as a frame family and make nested door panels (could be a massing family, generic model family or door family). I can create family parameters in the host family to give the user control over choosing a door panel from a drop down. My problem is mainly in how to schedule the "assembly" (door and frame) in one row on a schedule:

Door name: 101; Size: 3'x7'; Door Material: WD; Door Type: NL; Frame Material: HM; Frame Type :13

I thought maybe of doing a side by side schedule (one for the frame and one for the nested door panel, and sort them the same way so they look like one schedule).

I'm curious about how others deal with this. Traditionally, we manually draw elevations of the frames. And they're never 100% coordinated. So, I'm trying to model each frame type/door type combination so I only have to worry about taking a decision at model level. Then, when I schedule them, I have the correct items, I would have the right frame/door elevations (whether in a legend or an elevation view) and they show correctly in exterior/interior elevations. Right now, a frame type is just a text instance parameter, so there's no warning system to alert a user of a duplicate and you have to draw frames manually and assign a mark manually to them. You're then relying on the user to assign the correct instance parameter (frame type) to "link" to the right frame. Which is what we traditionally do and I'd like to get away from that.

If you do a door family with a frame as a host and a shared door family with a door panel, when you assemble them and put them in a project, each schedules as a separate row in a door schedule and that's what I'm having a problem with. If I make the door family (door panel) as non-shared and nest it, then the schedule only picks the unique Type Mark from the host door family (combined door and frame) and I have no way of picking up the unique Type Mark for the door panel in this case. You could do the reverse (door panel as host door family, frame as shared door family....in that case your type mark would refer to the door panel, but there would not be a way to have a unique parameter show up for the frame).

Hope this is a clearer explanation. If not, I'll try illustrate another way.

[jguycote]

There are so many combinations of doors and frames which are possible that we decided not to try to model them all, unless needed for 3D illustration. Instead, we have a few basic door and frame combinations:(single, double, double egress, double acting doors; wrap-around, flush, inset frames), which mimic 2D drawing. Door dimensions are instance parameters.

Since most projects have groups of similar doors (office doors, storage doors, exit stair doors, etc.) we develop for each project a door Key schedule, where each type of end use gets assigned a style: door elevation, material, finish, fire-rating, and a frame detail, with material, finish, etc. exactly as we would do in manual drafting.

The door schedule is then filled out with the key styles. We have a duplicate door schedule sorted by key style. For each key style, it is easy to spot any mistake, since all doors of a given style should have identical properties.

We find that this method forces us to review each door and thus reduces mistakes, while still being very quick.

[dbaldacchino]

Thanks jguy. Your method sounds just fine, but it does fall short of really putting in the information once in the "virtual" object, which is what true BIM is all about. I'm trying to streamline the process a bit....model the elements in order to facilitate walk-throughs, show rendered elevations with the right materials, doors frames, etc (which is being demanded pretty much on everything nowadays), and to make sure that what is modeled by the designer and project architect, is what gets documented (and thus shows up in schedules, elevations and legends). Any other method has the potential to cause discrepancies between design intent and the documented intent.

In no way am I saying that your method is wrong :) But I think you arrived at that by virtue of what you feel does not need modeling and by virtue of what I'm beginning to believe, is a current limitation of the software. Or it could be a limitation of what I'm understanding, which is why I need to hear other user's opinions!

[Scott D Davis]

I think you can do exactly what you are trying to do, although it takes some set up, and your family files are gonna be large. You will create door panels in the various configurations as generic families, and assign all the type parameters to them for WD, AL, HM, GL, etc. Then you will create the frames as generic families, too, and once again assign all their type properties.

Then in a door familiy started from the template, you will nest many panels and many frame types into one family, and then use on/off parameters to drive the display of the different types. You can create some of the standard "assemblies" for your users ahead of time by creating Types in your door family that will turn on and off the appropriate panels/frames. Others can be created simply by defining a new type in the project.

Each Assembly will schedule the "parts" for you, so the frame and door can have separate "types" in the schedule.

We have done part of this in the attached example. This is one door family with nested panels for Flush, Vision, and Half-glass doors. We did not do the Frames, as we left these as instance-based properties.

We tag the "assembly" by door number, then one tracks down that door number in the schedule to see the door panel type and frame type.

Is this on the right track for you??

[dbaldacchino]

Thanks a lot Scott. It does sound like what I'm after. So you're making the components in Generic Model families and nesting in a Door family. Are you making the generic families shared families or not? From the image you posted, it looks like what I'm trying to get to.

I'm aware that it'll take some time to set up, but I think the end result will be less mistakes and quick modeling. Then I can keep building frame configurations that are parameterized so they can be quickly configured to suit the design, assign their unique frame type and set the door. I'll try some quick examples tonight and post my findings.

[Scott D Davis]

I should have clarified, in the image I posted, each door is from the same family, but each has its own properties, and each schedules as its own type.

No, ours are not shared families, but we have no reason to "tag" the door and the frame separately.

Ultimately, you could get one door family that has ALL of your office standard types, and switch out the parts. It is doable, but the family will get large and tougher to manage. The parameters need to be linked one the panels and frames are nested together, so that when one flexes the door size, everything responds accordingly.

[dbaldacchino]

The parameters need to be linked one the panels and frames are nested together, so that when one flexes the door size, everything responds accordingly.
I have done that. I used the AU Lab as a guideline and then I modified it to suit my needs. Later tonight I'll post an example. It's a door with a lite in it and you can check whether the frame wraps walls or not, and if not, you specify a frame width and how far the inset is. You also locate the window lite in the door frame and there are some "rules" intended to help control user input.

I think the best I can come close to achieving what I want, is by entering my Frame Type info in the door family's Type Mark and then just adding a shared parameter for Door Type (unfortunately, it's a manual operation that I was trying to get away from). I'll experiment a bit with using a Family Type parameter for the door panels too, to switch them around easily once they're placed in a project. Man I wish there was a frame family!

[dbaldacchino]

Ok, I'm posting two images of something that has been puzzling me and is probably the cause of this thread.

I started a door family to act as host family. I also created three generic model families and turned them to door families. This way I could build a door panel in one, a door frame in another, and the 2d swing in the third, all without a wall within the family. Now, these were nested into the host and then each parameter was connected to a parameter in the host, so that the host would drive everything (pretty much identical to the AU lab).

When you're in the host family, you can select a nested component, go to its properties and change the parameters or connect them to host parameters. One of these is "Type Mark". Now, when you place a door family in a project, you get a warning if you use the same Type Mark for different Types. Yet, if you use the same Type mark for different nested types within a host, you do not get such a warning. Why is that?

Initially I was thinking.....if I drive the frame's Type Mark with a shared parameter from my project (remember, the frame is a door family nested in the host door family), it should warn me if I use the same Type mark for a different frame type. Similarly, if I drive the door Type Mark with a shared parameter from my project (once more, the door panel is a door family nested in the host door family), then it also should give me a warning if I use the same Type Mark for different door panel types. Yet, this doesn't happen. It's as if the Type Mark in nested families doesn't work. The same applies to the Mark...in projects it gives you warnings, but while in the family editor it doesn't (or when it's driven by a shared parameter in a project). Is this a bug or is there logical reasoning for this? If this worked as I predicted, I wouldn't even have started this thread as I would be able to achieve my goals :) See the attached images for screen shots of the properties of two door panel types (nested door family) within the family editor, using the same Type Mark and getting no warnings.

Thanks all for your patience!

[dbaldacchino]

Ok, I've done some tests and I have some more questions. I apologize for being annoying, but I really want to understand how to make this work right for us.

Take a look at the project file. I inserted 4 door types (2 door panels and 2 jamb combinations). Warning: these are crude families that I'm just using to get a concept to work.

The schedule shows the info. I need. Now, take a look at the jpg. "JambSelector" is a type family parameter. "Frame Type_shared" is a shared, text parameter in the family. But this can be modified within the project. Is it possible to make it modifiable only in the family editor, so that when I select the jamb from "JambSelector", the Frame Type_shared shows up greyed out, displaying the info. within the family? It would be great if I could perhaps set up a key schedule that would fill out parameters based on what family gets assigned to JambSelector, but I don't think it works that way.

One more thing....If you go to the schedule and change say, J1 to J3, you get warned that this will be applied to all elements of type P1J1. But, P2J1, which is also using J1, doesn't change. Is there a way to make this work such that when a parameter of a nested type changes, this change occurs throughout the family types?

Thanks all for looking into this.

[greg.mcdowell]

I'm a few months late on this topic but I've been trying to go down the same road you have been and, from what I can tell, it's not possible to do what we're wanting. A door can only have one type mark (though you can nest the panels and frames into them to make creating the different families easier).

What I've done so far (and I've just begun to setup my templates so I'll need a few more doors) is to create two door families (Flush Single with HM Frame and Flush Double with HM Frame) and I've got two types defined in both (2" Jamb - 2" Head and 2" Jamb - 4" Head). The size of the doors are Instance Parameters and default to 3'-0"x7'-0" and pair of 3'-0"x7'-0" respectively. I figure this will account for ninety percent (or more) of the doors we'll need.

In the Type Parameters of each Family I added Shared Parameters for Frame and Panel Mark and set them to a default value.

The only issue I have with the system so far is that if I decided to change the Panel Mark (note that I'm trying to stay away from using the word "Type") of one of these doors, and I've got all 4 in the project then I'll have to make this change 4 times (unless I created a Schedule that would filter it out correctly... hmm, have to look into that). Not ideal but not too bad and certainly better than where we used to be.

But then again... if I've already got the Panel and Frame Marks set to some default, what would be the sense in changing them? Revit will ensure that each time a door is added that this default designation will show up in the schedule so unless I get a picky PM there really shouldn't be any need to change them! (he says with his fingers crossed)

If you were able to come up with a better solution I'd love to hear it.

[dbaldacchino]

Greg, judging from the responses I got for my last post and experience gained over the last months since that post, Revit cannot achieve what I was after. I was trying to use it more parametrically perhaps than it is capable of at the moment. Having said that, I think we've found a good method that works for us. I'll know more about the success (or lack there of!) of this approach in the next couple of weeks.

What we're doign right now is managing all our door types in 8 families.....4 singles and 4 doubles. 2 of the singles and doubles are just used for insertion in curtainwalls/storefronts (frameless doors) and consist of a door panel that is flush and another with a lite (one lite configurable to any size and location you want....so you can get a narrow lite, half glass or full glass door panel). The other set is identical but has frames. Type parameters control the frame material, door panel material, frame head size (4" or 2"), etc. and some instance parameters define the rendering material of the frame, width x height and the 2D & 3D swings.

Each door type has a unique name that tells the user what it is..."DblDoor_Lite : NL_HM_HM_4"head_wrap". Sounds complicated but it's not......The first part is the family name and then the types are added and defined. NL_HM refer to a narrow lite metal door, the next HM tells you the frame is metal with a 4" head and this frame wraps around the wall thickness. This is built into the family and you can uncheck the wrap option and then define a frame depth and location within the wall manually.
This should encourage the user to select the right type of door as the information will be scheduled automatically (shared type parameters contain the scheduled info. and are pre-set). I'll keep you posted about how this works out as we're getting schedules done this week.

[greg.mcdowell]

Sounds like we're on the same path I just need to create some additional panels with lites and decide on a naming convention (I'm hoping to avoid abbreviations as much as possible... brings back too many memories of obscure file naming) and I think we're set.

One thing that I have been thinking about but haven't had a chance to implement is the frame wrap vs. definable depth and location. I've got a couple ideas about how I could achieve that but if you could offer any advice (or even a family I could pull apart <grin>) that would be great.

Also, how are you handling door frames with side-lites? Are you using a curtain wall or a custom frame family? I'm thinking that I'd want to use a family as they would typically be used repeatedly throughout the project and I could place them in a legend.

[dbaldacchino]

Hmmm let's see....I'm in a good mood today so I'll share :)

The attached family is one of my door types. Note which parameters I set as type and instance params. per the previous post. I'm not sure if you'll have problems since I have some shared parameters being used. If you do, I'll attach a shared param. file, just let me know.

As for side lites, I'm modelling them with curtain walls. I just do a frame to accomodate the door (I change one panel to a basic wall the thickness of my frame and insert a door similar to the attached family, but without a frame; just the door panel), a side lite and change the bottom infill to what the wall is if the lite doesn't go to the ground (and take the mullions out). In the future I might make a custom door with integral lite, but for now I'm just using curtainwalls (storefront). I'm not using windows at all in my project. I think they're more for residential perhaps. The do offer the advantage of having an opening with a specific sill and head detail though. You cannot do that with a curtainwall. Perhaps a combination of the two might get you some good results but I have yet to experiment with that.

[mthiessens]

Sorry for the zombie thread, but I am facing this exact issue in trying to set up the door schedule and creating doors for my company.

I've read through every thread I could find on the subject, but none seem to be all that recent.
I figure it will save me a lot of time to just ask if you guys have discovered any new and exciting ways of solving this problem?

[dbaldacchino]

No Problem and welcome to the forums :)

What I posted a year ago in this thread is still applicable. I'm not using shared families and am instead using schedulable parameters and a combination of instance and type parameters (and some shared parameters) to capture the information as we want it. I am of course using nsted families for the door panel, jamb and the 2D swing representation. The family example I attached is very similar to what we're using (there are only subtle, minor differences from our current ones).

[mthiessens]

Thanks for the quick response.

I guess now I'll just have to jump in and see what I can come up with (although the excuse of reading this forum all day as 'research' seems to still be working...)