Ganged Window Examples

[chughes]

Does anyone have a recommendation for a ganged window family that I can study and dissect? My goal is to have a window family of nested shared windows that will flex shared window types without breaking, with the nested windows able to be swapped out via labels in order to create multiple types.

So far the only reasonably stable option is to have a whole different family for each window version.

Thanks.

[barthbradley]

...explore Family Type Parameters:  

https://knowledge.autodesk.com/support/revit/learn-explore/caas/CloudHelp/cloudhelp/2014/ENU/Revit/f...

https://www.youtube.com/watch?v=myPmGlku4Lg

[RDAOU]

@chughes 

I wouldn't over complicates a door or window family more that it needs to

Having several families (ex: 1 for single hung, a 2nd for Double a 3rd for tipple) is a way better option than having 1 family with nested components to cover all (nested/arrayed and labeled) 

But if it is for the fun of modeling...there are several tutorials you can look at example:

https://youtube.com/playlist?list=PL1jmUPw0cg8KAwOE0jVRXxgFybMo7YMR4

[yes_and_no]

Besides the point here: I used to work for a firm that they only use curtain wall for every window. Talk about scheduling difficulty, I m glad I m out of it...

[ToanDN]

---

@yes_and_no wrote:

Besides the point here: I used to work for a firm that they only use curtain wall for every window. Talk about scheduling difficulty, I m glad I m out of it...

---

A curtain wall for every punch window may not be a great idea but a curtain wall for a ribbon window ain't that all bad.

[chughes]

I continue to try to work this out, but it is baffling how complex this is.

I managed to create a working, ganged window family (yay!).  It works well, so long as all windows are changed to the same type and at the same time.  I have working trim and buck that can be flexed with the changes.

The individual windows are nested into the ganged window family.  This allows me to number and tag each window instance.  Things are looking up!

Create my schedule and all of my nested head heights and sill heights are pure chaos.  Why Revit Why!

The nested reference level is correct ( Level 2 ) but the nested sill height is -16 11-1/4".  I cannot figure out what the nested sill height dimension is referencing, if anything.  Changing the head or sill height of the ganged window does not change or affect the sill height of the nested family.  As a result, the window schedule does not accurately reflect the head or sill heights.  I am about to give up.  The inability to exercise any control over the built-in parameters is extremely frustrating.

I guess the 'Revit' way to create ganged windows would be to bring in individual windows and to create or bring in separate families for bucking, trim, brickmold, etc and resize around the resulting ganged opening.  I am open to suggestions or ideas on how this should be done.

[barthbradley]

So, your itemized schedule is reporting the Shared Nested Families + their Host Family; right?  So, isn't the Host Family's Sill/Head Height the only significant value to report for a mulled together assembly of windows? 

[ToanDN]

See attached Revit 2022 file.

[barthbradley]

I think I understood you wrong.  I see the negative value under Sill Height in your screenshot.  Did you make some Ref. Plane the "Origin" Ref. Plane - such as the Ref. Plane at the top of the Window?  I can see where that would throw off both the Sill and Head Height.  

...love to examine the family if you want to share it.  

[chughes]

Happy to share.  Please see the attached.

I have played around with different origins in the nested family and in the host family.  Changing the origin in the nested family doesn’t seem to affect it in the host family, even though it should.

I agree re:host head height and nested head height would be the same *but* I cannot drive the sill or head height of  the host opening with the nested windows, so that is another hurdle. 

I feel like it all comes down to the inability to directly drive the built-in window parameters for sill and head.

[ToanDN]

---

@chughes wrote:

I feel like it all comes down to the inability to directly drive the built-in window parameters for sill and head.

---

See the example above.  Forego the inbuilt Sill Height and use a Shared parameter for both nested and main families.

[chughes]

I am working through your solution and have a couple of limitations to overcome.  Ideally, all windows are included into a single schedule.  When combining single windows with ganged windows, the scheduling capabilities come apart.  If I add the sill height and head height parameter to the window schedule, the nested window information is still incorrect.

I just want to confirm, there is not a means to lock the built-in 'Sill' reference plane to a parameter or model element in the nested family where the reference plane will flex and follow changes in the nested family?

If I can get the opening cut to follow the window, I think everything will start to work out.  But I cannot figure out how to have the nested family drive the host family (knowing that it generally not the way it should work).

[ToanDN]

As suggested, do not use the built-in Sill Height and Head Height.  Use Shared Sill Height and add a calculated parameter for Head Height = Shared Sill Height + Height.  These parameters can be used for both main assembly windows and shared unit windows.

See updated file.

[chughes]

Thanks for your help, guys.  At this point I am setting it aside as too complex to implement in conjunction with the other windows and schedules.  Too many non-OOTB parameters and nested parameters.  My solution is to use individual windows, align the edges of the frame, and create a separate face-hosted brickmould + window buck family and just host the  brickmould to the face of one of the windows.