door families and schedules

[mmiles]

Can someone tell me the difference between the instance parameter "mark" and the type parameter "type mark"? And, why cannot I make family types that use a specific type mark, within the family editor?

the help menu states the "type mark"is what I thought is actually the "mark":

"A value to designate the particular door. This value must be unique for each door in a project. Revit Architecture warns you if the number is already used but allows you to continue using it. (You can see the warning using the Review Warnings command. See Reviewing Warning Messages (mk:@MSITStore:C:\Program%20Files\Revit%20Architecture%202009\Program\HelpArchitectureENU.CHM::/WS46b90c3cb2c58caddf503fc9951c5a8-7fe3.htm).) Marks are assigned sequentially. See Creating Sequential Door or Window Tags (mk:@MSITStore:C:\Program%20Files\Revit%20Architecture%202009\Program\HelpArchitectureENU.CHM::/WS46b90c3cb2c58caddf503fc9951c5a8-7f74.htm).

[cliff collins]

If I read the question right:

The "Mark" is the door number. ---i.e. 101A

The "Type Mark" is for the Door Type. ---i.e. Type B

Does this help?

cheers..........

[mmiles]

yes...that is how I interpret things. however, the help menu says differently.

Now, the "mark' is an instance parameter - cool, no problem.
The "type mark" is a type parameter, but I only seem to be able to access that parameter from within the project. In other words, I cannot find a way to establish the type mark while in the family editor, as there doesn't appear to be that parameter among the list of parameters. I am wondering if there is something that i am missing.

[dhurtubise]

Unfortunately Matthew you are right :-(

[mmiles]

hmm....
Okay, what about this: I still want to use the "type mark" as an identifier of the kind of door it is (i.e. Type "B"; a 3 panel door) and I would like to add a numeral to signify the different sizes, or other variables (i.e. Type "B-1"). As I edit the schedule this presents no problems for me, however, if I insert a new door family, regardless of the "type", that instances automatically gets a type mark parameter assigned to it that is sequentially related to the edited object (i.e. type "B-2..."). So what is a good way to define the Types (styles) of doors?

For a variety of reasons related to rough openings, door sizes and the "opening" in the wall controled by "width" and "height" (from the door family templates), and other detailing/construction methods I have resorted to not scheduling the height and width parameters, and have instead opted to name my family types using the dims as a name (36" x 80"). this is okay as a work-around - as I avoid getting complicated with scheduling rough openings, door panel sizes, and clear openings, etc. But I am curious what others do.

[thillhouse]

Along the same discussion... I'm trying to figure out the best way to name or build my door families for documentation in a door schedule. There are two things in the schedule that reference the Door Frame elevation and the door type elevation.
I have a legend that takes the elevation of the door frame and the elevation of the panel and assigns a type to them.
I thought about using the different door panels as a generic family that I can nest in a door family, and then have the frame type be associated with the door family.

The question is what are other people using to document their doors in a schedule.
Right now I have door families that describe the width and height and whether it has a sidelight or 4in head etc (Describing the frame). I also have a type parameter describing the type of panel...Is this the best way? Do I need to have a family for every type of frame, every door size and panel type or can I nest this somehow?

Tim

[Mike Sealander]

We have our door schedule use Width and Height parameters from the family. The trick is make sure your door family uses Width the way you want it to show up in the schedule and on the drawing. So, hollow metal door and frame: Width is panel width. R.O (which we don't supply) might be Width + 2", or whatever.
We also have completely separate families for HM doors with no lites, HM doors with lites, and so on. It doesn't take too much effort to establish those family types, and I see no reason to nest. Our HM frames look alike, and we don't get too bogged down with having drywall frames distinguished graphically from CMU frames. It's easier to pick up those things in standalone details.
One thing we've done is rebuilt wood-framed doors so that their frames (and the opening cut in the family) behave more like HM frames.

[jcoe]

I designed our door families to have a shared parameter "Panel Type". This way when I nest the doors and frames together, I can pre-define the panel type in the family and have it appear in the schedule when loaded into a project. For example, all our flush doors are type A; 1/2 Glazed doors are type B, narrow lights type C, etc... This takes the guess work away from the end user and provides consistency across projects. Just make sure the shared parameter is loaded into your project/ template file and applied to the door schedule.