Structural Header - Nested Family For Scheduling

[ianpM59BG]

Hello All - Gonna be a long walk for a short question, but I figure I'll put it all out there since other Structural Engineers might have a better idea on how to approach this whole solution. 

The goal for my firm is to create a Structural Header family. The things we want it to do are:

1. Cut the wall it's inserted in (so that we don't have to trim/cut walls for penetrations)
2. Have Jack Posts and King Posts built in, and selectable to be shown
3. Have the header built in
4. Have the assembly be Taggable
5. Have the assembly be Schedulable

I've messed around with wall-based and face-based families and have had some luck, but they're clunky since they need to be hosted and often try to insert on the level above, rather than the level below (our structural workflow models the framing of the work plane and the walls and posts holding it up below)

The most promising thing I've figured out thus far is to build a custom Curtain Wall Family, with a custom Curtain Panel that holds the posts and Header inside it, see screenshots.

Then, inside the curtain panel I built the header and posts, and a Tag that will output the Curtain Panel Type, # Jack Studs, # King Studs. 

Great so far! I even have the Header size as selectable Structural framing. However, when I schedule the curtain panels to make a Header Schedule, the Header column has the "Family:Type" format and I'd love for it just to display the Type (  (2) 14" LVL, (3) PT 2x12, etc. ).

Is there any way for the schedule to drill into that Nested Family and only retrieve the Type? I know I could make individual Families with just one type that consist of the name of the framing, but when I get to 7 1/4" LVL, etc, I can't save families with that name since there are disallowed characters (/, ", etc). Of course I could do (2) 7.25in LVL, but I'm getting pushback from my managers about that formatting. I'm building these elements for a bunch of folks at my firm who are less Revit Savvy than I am so I'm trying to make it as Super Simple as possible. 

The other option I have, and it would be fine, but less elegant, would be to just have a Type-based Text box for the header, where folks would just put in the size of the framing, but I know people would prefer the drop down menu, and resizing the header in place would be nice for a visual cue in the model space.

So, Again, the question is, when I have a nested component in a Curtain Panel, can I schedule just the Type of the nested component or am I forced to accept the "Family:Type" Output only? If that's the case I'll probably need to have it just be a text box for the Header Size, for ease of use by the other staff members.

[ianpM59BG]

NA? Like Not Applicable? Not Available (the solution I'm looking for)? I'm not getting your meaning, but thanks for the reply!

[ianpM59BG · Accepted solution]

Bueller?

Well, if anyone's ever looking for something like this, I've had some success and we're testing it out in future projects. Here's how I did it. I made a Curtain Panel Family with a nested generic model of a column, and the "curtain panel" itself is the geometry of the header. That way I could build a bunch of different types inside of each curtain panel family.

Now, the tag for the header is a curtain panel tag with Family Name, # Jack Studs, # King Studs, and the schedule shows the headers present in the project, using Family Name, Type Name, #J, #K.

 

This solves the problem in the schedule of typing in the size/name of the header when we start scheduling in a project.

In our standard project template, we've built Curtain walls for all the Curtain Panel families. The curtain panel family is now hosted under a curtain wall of the same name, and when they show up in the Header Schedule the Header choices are all constrained to the choices inside each curtain panel family.

This works pretty well for us, but I'll note that we don't do much analytical structure design in Revit, and I have no idea how I'd make these "walls" behave like framing if we ever needed to. That'll be a bridge we build when we get there.

Anyway, I'll mark this as the solution. Here's hoping it helps someone down the line.