Thinking through door & opening types AND scheduling AND instance vs type parameters, locking parameters, etc.....

Thinking through door & opening types AND scheduling AND instance vs type parameters, locking parameters, etc.....

payingtoomuch
Collaborator Collaborator
225 Views
5 Replies
Message 1 of 6

Thinking through door & opening types AND scheduling AND instance vs type parameters, locking parameters, etc.....

payingtoomuch
Collaborator
Collaborator

Everyone-

Trying to dumb down my door and opening family types.

Here is what I'm dealing with and the types I will find myself using.

Commercial vs Residential

Interior vs Exterior

Masonry vs Drywall Frames

Masonry Setback

Cased/ Not cased and the various casing types

Door sizes

Single vs Door Pairs

Hardware types

Threshold Types

Various Head heights

Various finishes for both doors and frames (paint, stain etc)

Etc.

 

Thinking I could set up my door family types as either all instance parameters, all type parameters, or some combination but not sure how this choice ultimately affects scheduling.

 

With all set to instance parameters I could have a limited amount of families but would need to control more of the scheduled info at each individual door instance.

 

If have set up with "all" (mostly) type parameters, could set up so I have more family types with "preassigned" parameters for the individual family type filtered through naming conventions. In this way would select a door type when I place it initially and would need to match properties or select a different door type if it needs to be changed later.

 

Related is the fact that, for finishes, view window, hardware & threshold types etc it would be easier to think through these choices while looking at a schedule and editing directly there. So, can look at doors in, say, a particular room and decide if it wants to be painted or stained or hardware type or whatever.... because I can see the room type and what it requires.

 

An aside is, for view window types etc.,  not clear on whether the doors would want to be a separate door type..... with say selectable glazing sizes etc. Or fixed glazing size assigned at the family type level.

 

Complicating these decisions a little more is that I have some door types that already have multiple parameter types selectable for any given door. Such as "masonry" vs "drywall" frames and "Interior" vs "Exterior" door/ frame types. So has me questioning whether or not I would want to create separate family types for the various versions of these with the tick boxes preselected OR, have less family types and let instance parameter selections at the family type level determine these particular parameters. How this would affect "select all instances" has some bearing (see below). Or maybe eliminate the "do it all" family type and have completely separate families for the individual frame types and interior vs exterior types etc.

 

So, bottom line is, it seems to me, that at least SOME of the parameters for doors want to be instance parameters and some want to be type parameters.... and thats ok so long as I can come up with a way to have this make sense and schedule properly.

 

Big picture I guess on some level, is that the issue would be that for any given project you want the least amount of door types possible, so one way of helping to get there is to have less ability to choose instance parameters. That way you are kind of "forced" to either create a new door family type, or use an existing family type. So, in essence you select from a list of available choices.... via the family type dropdown. And then its a matter of deciding which parameters it makes sense to have as instance vs type parameters..... But I have no idea at the moment what might make sense here..... where to jump off from.

 

One thing that is kind of throwing me off with making decisions here is that for some of the door family types that I have, if I copy a particular door type, then change one of the door types instance parameter from, say, drywall frame to masonry frame, then right click select all instances, both of the doors are selected as if they are the same doors..... but they are not.... completely different. So, "obviously", I need to make sure that this is not the case as I set this up. Just a little muddy to me what is going on here and could use some help with understanding how this works together. Can someone explain to me how changes you might make to either instance vs shared parameters affects the right click select all instances tool?

 

So, one of the big questions would be, how do you decide which parameters you set up as type vs instance parameters for a "door"? Other family types?

 

Thanks for any insight you can provide

0 Likes
Accepted solutions (2)
226 Views
5 Replies
Replies (5)
Message 2 of 6

Mike.FORM
Advisor
Advisor
Accepted solution

We set up our door families based on the how many leafs (single or double, we also have a few triple and quadruple) then by frame type (butt or wrap) and then the layout of the Sidelights.

 

So we would have a family called "Door - Single - Wrap - Sidelight Latch Side"

 

Then within our family the parameters are organized as follows:

 

Type Parameters

  • width
  • height
  • sidelight 1 width
  • sidelight 2 width
  • transom height (if there is one)
  • frame width
  • frame depth (for butt frame this is user controlled, for wrap frame it is set by a reporting wall thickness parameter and is instance based)
  • shim space
  • door thickness
  • glass thickness
  • undercut
  • Frame Type (this is set using a formula "F6", where f = frame and 6 is the layout)
  • Frame Sub-Type (this is filled out based on the size differences between sidelights and transoms for the Frame Type it is then combined with Frame Type in the schedule so the schedule reads "F6a")
  • sidelight base height

Instance Parameters

  • Door Panel (family type parameter of the nested panel family)
  • push side handle # (integer parameter that controls the nested handle family in the nested door panel family)
  • push side handle type (based on the handle # value this fills out with specific text ie. "LEVER", etc.)
  • pull side handle # (same as push side)
  • pull side handle type (same as push side)
  • new (yes/no parameter)
  • existing (yes/no parameter)
  • frame depth (wrap frame doors only)
  • door material
  • frame material
  • glass material
  • handle material

MikeFORM_0-1763402611526.png

MikeFORM_1-1763403338515.png

 

0 Likes
Message 3 of 6

payingtoomuch
Collaborator
Collaborator

This is awesome Mike! Gives me an excellent jumping off place!

I think I can get through the setting up instance vs type parameters.... but I have very limited knowledge on the whole formula component.

To maybe help get me started this would be a good place....

 

  • "Frame Type (this is set using a formula "F6", where f = frame and 6 is the layout)". How the heck is this a formula? For the "F" part where is the frame type chosen from? Then similarly the "6"? How is that a layout. Is that a type of layout? A configuration of muntins or something? Sorry, really have no clue what you are getting through this formula. Can someone maybe point me to some tutorials that might help me get a kickstart with the whole formula thing as it relates to parameters?

 

0 Likes
Message 4 of 6

payingtoomuch
Collaborator
Collaborator

..... also, i haven't spent much (any?) time thinking about the whole locking component for the various parameters. Is the thinking with the locks that once you name/ create a particular family type of x size etc, that you don't want someone manipulating the dimensions for the particular type.... so you lock those dimensions? I think this would make sense to me.... to avoid having a type name that ends up having incorrect dimensions in the project. That could go south in a hurry.

0 Likes
Message 5 of 6

Mike.FORM
Advisor
Advisor
Accepted solution

The F6a is not a formula, I was just saying that our type is set up like a code which references a legend. F stands for frame, 6 is the type (single door with a single full height sidelight) and then the lower case letter would be the width of the sidelight.

We could schedule the sidelight width but then it just start making the schedule a bit too big if a door has 4 sidelights and they are not all the same size and there is only one instance in the whole project.

 

We have like 20 different standard frame types (combinations of sidelights and transoms) that are always the same so we never want the F# to change for those families.

 

The "Lock" checkbox does not mean anything in regards to the family in the project. that checkbox controls whether or not a labeled dimension will change if you move/drag a ref plane in the family that it is associated too.

 

0 Likes
Message 6 of 6

payingtoomuch
Collaborator
Collaborator

Aha. Makes sense now....  The F6a thing. "Typical" schedule type notations that point to a frame in elevation on the sheet. Thanks for explaining.

On the "lock". I probably knew that last month when I was working in revit. Have been  back to cad for a month now..... so getting my brain back in gear now that I'm working in revit again.

Remembering more as I get back into than in the past when I go back and forth so progress!