I'm opening up this issue to my clever readers out there to either enlighten me or corroborate my situation. Imagine a structural support that we'll refer to as a pipe support. If it helps, something like this:
I'm referring to the green "column" and "beam" with the tabs at the ends of the beam to counter potential "roll-off" in a seismic situation. The obvious way to make a family for this is to nest a column and beam family, use a Family Type parameter to swap between sizes when they are placed in the project. I write obvious because it would be nice to be able to use the standard framing families and types to choose the relevant form and configuration.
Everything is pretty straightforward until I attempt to change the type. The length of the Beam resists being constrained if I change the Type. I've managed to get it to work but it tends to break as soon as the beam size is changed.
The puzzler is... has anyone been able to get nested beams to behave when managing the "in-use" type with a Family Type parameter?
Working around the issue, a couple solutions come to mind.
If the Structural Framing beams are not used I can get it to work easily so that suggests a conflict with the category behavior (the structural framing template). If I build my own beams and columns using the same profiles and type catalogs it will work. Unfortunately that means we'd end up with "different" beams/columns than the other "real" beams and columns when we think of schedules.
The other solution might be to use the API to get the information that the user needs to supply and let the API create a custom family from the parts and build/insert on-the-fly. Like the Frame Generator extension does for Revit Structure.
Comments?
I'm referring to the green "column" and "beam" with the tabs at the ends of the beam to counter potential "roll-off" in a seismic situation. The obvious way to make a family for this is to nest a column and beam family, use a Family Type parameter to swap between sizes when they are placed in the project. I write obvious because it would be nice to be able to use the standard framing families and types to choose the relevant form and configuration.
Everything is pretty straightforward until I attempt to change the type. The length of the Beam resists being constrained if I change the Type. I've managed to get it to work but it tends to break as soon as the beam size is changed.
The puzzler is... has anyone been able to get nested beams to behave when managing the "in-use" type with a Family Type parameter?
Working around the issue, a couple solutions come to mind.
If the Structural Framing beams are not used I can get it to work easily so that suggests a conflict with the category behavior (the structural framing template). If I build my own beams and columns using the same profiles and type catalogs it will work. Unfortunately that means we'd end up with "different" beams/columns than the other "real" beams and columns when we think of schedules.
The other solution might be to use the API to get the information that the user needs to supply and let the API create a custom family from the parts and build/insert on-the-fly. Like the Frame Generator extension does for Revit Structure.
Comments?
18 comments:
I have had a terrible time trying to nest structural framing families, and actually abandoned the idea. Try and constrain the endpoints of beam to reference planes in order to drive the length. It will break every time.
I can constrain the length of a beam okay, it breaks when I change types.
It's important to realize that beams have multiple references to consider; the nodes that represents the first and second "pick points" during placement and then the reference planes for the solid geometry (technically their are two sweeps, one each for medium and fine detail level).
It's necessary to constrain them both carefully in order to flex their length.
Unfortunately it breaks when I try to change type.
I've had problems with the same. Partially due to the numerous references which you mention. However I try it seems like there is always something that breaks (i.e. Steve's type break).
Let us know if you ever come up with a good solution. All the ones I have are messy.
Huh still could get it to work. Even if I constrain the start and end point in the coarse view and the start and end of the medium/fine view.
The secrect is to rebuild a new set of references outside the constraint length boundaries.
Then realign the length with it's own set of references, that then can be reset.
We use this for girt, purlin layouts and a number of other area's where beam systems are inadequate for large and complex framing rollouts.
Adam Sheather.
Hi Adam,
Are you saying that it is necessary to alter the stock content to do this? If so does it impact "normal" usage of the family(ies)?
Altering the content is what I'm hoping to avoid. Maybe unavoidable but if the stock content can continue to function elsewhere normally that is at least a palatable workaround until "good" families and "bad" families try to mix somehow when a project is shared?
Thanks!
No Luke, that value is "inaccessible". I already sought after that approach. In some cases irreconcilable constraints that won't flex in the family WILL in the project setting.
In this case the family type WILL work in the project but the length will be ignored, rendering the length of the beam wrong when you change the type.
End result...the same unworkable beam even though there is no "error" message shown.
Hey Steve
No you can get around that by modifying the templates for the content generator atleast that's what we do, there are about 20 templates or so but it's quick and applies to all content. Plus 1 or 2 templates suit all just need a name change and profiles.
You change the beam to access centre or one or both sides. You can't control the length on import but you can post import if you require the analytical model. we replace that with actual length.
Adam
Sorry I did forget to add that this all made irrelevant if you use the complex beam and trusses in the content generator instead. The other option applies if you want a 2 pic point family nested element.
Okay you know the scene in Jurassic Park where the Mathematician is explaining Chaos Theory to the other doctor? She does the "over-my-head" thing with her hand and arm? That's me...
By content generator are you referring to the Frame Generator extension? Where are these templates you are referring to?
Might need you to "slow-down" for me! :)
I see the Content Generator extension but don't see how I can use it to make the pipe support form unless you are saying I need to build the form as a template for it to use? Still not sure how to access that stuff, nothing in the help file to explain it.
If you edit the family of the OOTB UB framing family and look at it on Ref. Level, it is quite a bit different to the Structural Framing - Beams and Braces template file. The OOTB Family has extra parameters called "End Extension Calculation" I'm not sure whether to 'save as' the OOTB family, or start with the template.
The UB Universal Beam and the W-Wide Flange (the one I've been using) families are essentially the "same" as they have the same parameters you describe. The Beam and Braces template doesn't have those...
I don't recall the reason for the "funky" extra reference planes exactly but I believe they are their to deal with the setback of the symbolic line work and to provide the separate control of the 3d geometry as well as to support the coping concept. They need to be able to flex independently.
The OOTB beams are a nightmare, I have never figured out exactly how they actually work, the constraints don't seem to be logical
Typically I have used lined based families for this type of nesting, but when shared you end up with essentially duplicate families. Which is acceptable in this case I think because it would be a separate package of steelwork
I came up with a workaround which would work in 2012. You could just make the beam at its longest length, and host a void component which you could flex to cut the beam back to size, unfortunately it would have to be a nested void family. Could be an option if you desperately need to use the OOTB beams. It wont cut back the symbolic linework though either
Hey Steve I didn't make the last anonymous comment. Correct they do need to flex. I am talking about the content generator in the Revit Extensions, not the frame generator the one where you can go shopping for your profiles. They are built off a number of templates to all local standards, we modifiy these as it's easier then modifying a million types.
You need to setup and fake some options to get the parameters to match up. You could then load these as needed into the family as long as it has a pre-existing label. You would still need to open and edit I would image rather then loading every possible type into the pipe support in the first place.
Adam
Hi Steve
Unless I've misunderstood something fundamental here, I think you maybe need to consider this from a different perspective. From what you've said, you don't want to create a new steel beam family, essentially in order to utilise a single source of 'real world' information. However, in reality, the actual single source is the type catalogue, not the family. The OOTB steelwork families leave a lot to be desired. We rebuilt the lot again from the ground up, with an emphasis on a more holistic approach to them as a set of families. This resulted in much more consistent model information. In addition to the geometric parameters, we use two shared parameters, 'Section Name' & 'Section Type'. These are only used in steelwork families and allow these as a 'set' of to be isolated in the model. It means that instead of having a 'Structural Framing Schedule' or a 'Structural Column Schedule' that list by Family and Type, we use a 'Multi-Category Schedule' that lists by these 'Section Name' & 'Section Type' shared parameters. So regardless of the Revit Family Category, the single source of information, the type catalogue, is being consistently presented. A 'Universal Beam' (if your from the UK for example) can be a 'Structural Column', 'Structural Framing', 'Generic Model' etc Revit family category, they simply act as a conduit to the model for that single source 'real world' information, the type catalogue
With regards to the modelling issues, I think this is down to the fact that the beams extend from opposite ends and the start/end extension parameters are pushing back against each other
Sorry, late to the party....I have played around in the past with truss families to do miscellaneous steel. The reason I like them is because they act very much like curtainwalls from a modelling point of view: you have grids and dress them up with framing families without messing with parameters. Might be worth a try as an approach.
On my side I work with puzzle families. A cloned library of structural members that helps me automate the procces of creating more complex assemblies. See example here: http://bimerworld.blogspot.ca/2013/06/creating-smart-bridgings-in-revit.html
Post a Comment