First off, what do you mean by this?


Next, step back... and plan your attack. This can all get very convoluted very quickly.

(to jump the gun) you want pay special mind to host, and associated level behaviour with nest children - especially in terms of placement - i.e. what will you do when you want your door-panel to sit higher/lower in the CWP?

Is your CWP.rfa entirely "empty" and purely playing host?
Are you collating your door(set) together first (in a catch-all child family) or constructing your door(set) within the CWP?
From where are you driving parameters (other than the width/height of the CW-grid)? Instance from the CWP, type of the child, a mixture of the both?

Just remember, OOTB: children can't talk up to parents, only parents down to children. So the relationships between the panel and frame need tying through by a means you need to decide on what's best for you. Similarly, with hardware, it's almost always relates to the panel more than the door-entire, but then when factoring undercuts and tolerances (of the panel) you may still want certain elements (like the door handle) to respect a "higher" (controlling) power coming (down) from the CWP parent.

My advice, sketch it out first, don't get too involved in the modelling until you've established base concepts of the working behavior - i.e. will folk using this family swap out a door frame per CWP instance, by CWP type, or would they rather swap out a "doorset" in it's entirety? FWIW, that's how I do mind, but YMMV.

Hi,
The offset looks like this in the project.. I haven't found an explanation for it yet, as you can see it affects only the leaf itself.


I've outlined what I want in a small diagram - Basically to create a number of "standard" types, and make it simple to create new types using the nested families.

I want, for example, a type that looks like this:
Frame B
Leaf A
Handle E
Hinge C

If the user needs for example different hinges, he will simply duplicate the type and swap it out:
Frame B
Leaf A
Handle E
Hinge A

My CWP family is empty (actually, it's a curtain wall door family, is this recommended or would you use the normal CW panel family?)
All my parameters will be defined in the CWP family - here is a short list of them:

Frame Height+Width
Leaf Height+Width (I input offsets from the sides/top/bottom, and want the leaf to flex accordingly)
Leaf Offset from bottom - how far the leaf is from the ground
Handle Height+OffsetFromSide
Hinge Heights (and maybe number of hinges)

In addition to all these, I'll have a few more parameters for simpler things - a simple yes/no for door threshold, type of lock (just a text variable), etc.

I'll upload my door family, would really appreciate if you could take a look!

Thanks a lot!

I'd be more than happy to take a look, but alas, only rocking Revit up to 2017 presently, so can't open it.

Going off your screenshot, it doesn't look like a hosting issue, (yet!) as that would be observed more in the vertical, (typically) - but a locking issue, where you've (not) align-locked the centre of the child door-panel to the centre of the CWP.

Check also you've a properly eq'd width parameter controlling the door-panel.

Darn Revit versions!

I'm not sure I understand locking with nested families - Can I lock them normally? when I change the family, the constraints don't hold up and I get an error, am I missing something?

Perhaps.


Can you flex the width of the panel family without issue? Start there - otherwise you're working on the wonk from the off.


"locking" (of the) nested families is a fairly basic concept, it's all got to do with:
1. their host behaviour (workplane, etc)
2. their origin


The former; is setup by the .rft you start things out with - plus modifications that that might allow.

The latter; is (generally) the intersection of the default ref. planes in an .rft (they declare themselves, and can be switched, in their properties on selection)

RTOTD, use instance parameters in your nested families.

Start here and reverse engineer what you need. Time well spent doing it right.

Hi all, thanks for your input!

SnowyWeston: My families flex as I intend them to, so no problem there. I'm not sure I understood locking.. If I create a GM, and lock it so a reference plane in the host CW door family, it seems to work. However, when I add a label to it, and then change the model, the constraints break and I get an error.

Elton: RTOTD? My acronym knowledge is limited :hide:

Cheinarantha: Right when I began my project, I looked into Twiceroadsfool's doors. They looked perfect for what I need, and my original plan was to use them as a guide. However, they don't seem to work as I expected. This is most likely a mistake on my end - but the CW doors are not scaling properly.

you are not so far from your goal, go ahead!! :thumbsup:, Aaron's doors are great to understand how things must be done!!