Category Archives: Structure

Revit Structure topics

Structural Framing Tags: Level vs. Sloped

When using the beam annotation (Annotate tab, shown below) tool to quickly tag many structural framing elements, there are a couple quick tips that are good to remember.

First, note that there are two tabs: one for level beams and one for sloped beams, see the image below.  In all honesty, I cannot think of too many situations where one would want completely different tags on level versus sloped beams, but the option is there.  So, if this tool is used and tags don’t show up, check that the correct tab was utilized.  Also note that if a tag is assigned to a level beam and then later that beam is sloped (or vice versa), the tag will remain the same.

The other items to note are under the “Placement” options in the dialog shown above.  There are several options available, so make sure to select the appropriate one, otherwise tags can be overwritten, missed, etc.

Top of Footing Tag Work Around

A way to tag the top of footing elevation is a question that comes up often.  Below is a procedure that I came up with a year or so ago.  I wrote an article for AUGIWorld last year on this issue as well.  This is a condensed version of the article, feel free to follow the link to read the full version.  One item to note here is that conditional formatting broke in the 2013 release – so use 2012 to create the schedules, and then upgrade, and hope the problem is fixed in 2014.

Step One: Create a Shared Parameter

Create a shared parameter for the top of footing elevation that will appear in the foundation tag.  Add the the parameter as a project parameter and apply it to structural foundations.  There are two reasons to use a project parameter here: first, using a project parameter will avoid the need to edit all of the structural foundation families (and re-editing them if updates occur), and second, elevations of elements are not available until they are inserted into a project, so there is little benefit to putting an elevation parameter into a family.

Step Two: Create a Foundation Tag

Create a new, or modify an existing, foundation tag that references the new top of footing elevation parameter.  Ultimately the elevation parameter will have to be input manually, so once the new tag is created and loaded into a project (or into a project template), one could choose to go no further in this process.   However, the remaining steps will add intelligence and improve upon this process such that the elevations are more easily managed.

Step Three: One More Shared Parameter

In order to avoid manually entering and managing them, the top of footing elevations will be calculated using the bottom elevation and the foundation thickness.  This calculation will be carried out in a schedule.  Unfortunately, the thickness parameter in the out of the box isolated footings is not a shared parameter, so it cannot be scheduled (wall footings and foundation slabs do not have this problem).  As a result, one more shared parameter is required.  Regrettably, this parameter has to be added to each family; simply replace the existing thickness parameter with the new thickness shared parameter.  This will have to be completed in every isolated foundation family.

Step Four: Schedule the Foundations

Create a schedule that includes all of the structural foundations.  Depending on the complexity of the project, some filters may be necessary to show only the desired footings.  Which fields to include is at the discretion of each user, but at the very least include footing type, elevation at the bottom, the new top of footing parameter, and all applicable thickness parameters (each of the foundation families have their own thickness parameter).  For simplicity, this process will only be concerned with one of the foundation families, the isolated foundation; however, it is possible to include and manage all of the structural foundation families in one schedule.

Step Five: Add a Calculated Value

Add a calculated value that will report the actual top of footing elevations for each footing.  Please note that the bottom elevation parameter is based on the project coordinates, so if elevation zero is not the same in both the shared and project coordinates, then this will have to be incorporated in to the calculated value.  In this example, this has been handled by adding a parameter called “Datum” and setting it to the proper elevation.  Setting the datum value can be achieved quickly by altering the sorting/grouping settings to group all of the footings into one row and then changing the value all at once.

To calculate the actual top of footing elevation, add the foundation thickness to the elevation at the bottom, and then add the datum value, if applicable.  The calculated parameter is illustrated in Figure 1.

Figure 1 – Calculated Parameter with Datum

With adding the calculated value, the accurate top of footing elevation will appear in the schedule next to the top of footing shared parameter that needs to be manually input.  A Revit user could then simply input the proper value to match the calculated value and the elevation would then appear in the foundation tag.  A suggestion here would be to group the foundations by their calculated top of footing elevations, and then input all of the values, thus only requiring that a user type any common elevations once.

Ending the process at this step would provide a simplified way to manually enter all of the top of footing elevations, but it would not entirely solve the issue that the footings may move and the elevations will have to be managed.  Yes, having the accurate elevation immediately available will aid in the management process, but it could be even easier.

Step Six: Add a Check Value

Add another calculated value to the schedule that is called “check”.  Make this value be the difference between the manually input value and the calculated elevation value.  Finally, use conditional formatting to turn the input elevation cell red if the “check” cell is not equal to zero, see figures 2 and 3.

Figure 2 – “Check”

 

Figure 3 – Conditional Formatting

 The “Check” column can be a hidden field, if so desired, since including this step causes any incorrect values (not the check value) in the schedule to turn red, thus making it extremely easy to identify and to edit the incorrect values.

Another approach is to make the “check” value a yes/no parameter, instead of length, that tests if the calculated value equals the manually entered value.  The conditional formatting can then be set to turn the inputted value red if the yes/no check parameter returns a “no”.  The yes/no return may be a more straight forward test output, but knowing the total difference between the calculated and the manually entered value may be useful.  Either method will work, but one or the other may be of more use to the user.

Once the schedule is expanded for the other structural foundation values, a calculated value, as well as a separate check field will be required for each structural foundation family.  However, the conditional formatting can include multiple criteria, so simply add a test expression for each foundation family to the inputted top of footing elevation’s conditional formatting.

Step Seven: Use the Schedule

After the schedule is completed, the only remaining step is to use it, and to remember to occasionally check that values are not coming up red.  When the foundations and the tags are originally placed, the elevation field will be blank, so that helps to remind the user to visit the schedule.  Then, as long as the schedule is checked prior to issuing the construction documents, the structural engineer can be confident that the top of footing elevations are accurate.  The schedule also adds a level of automation that will reduce errors.  Figure 4 shows tiled windows of the completed schedule (the check column is shown here, but would typically be a hidden field, as previously noted), and the foundations with their tags.

 

Figure 4 – Completed Schedule and Footings with Tags

 

Brace Framing

A question came to me this week asking how brace framing can be modeled so that the braces are going in the correct location while having the correct analytical relationship to the columns.  In this case the client wanted the “L” angles to be back to back but still be associated with the center-line of the columns.  The L angle OOTB family has parameters built in so that the centroid of the size can be set, these are “X” and “Y” parameters.  The values in these parameters coincide with the values for the centroid, if the type is duplicated and then these values are set to 0′-0″ then they will be modeled from the back side of the L.

Cross-Section Rotation Quirk

I was recently doing a quick little job for a client and in modeling the structure I needed to show a 2×4 wood framing member turned flat, so I used the OOTB 2×4 and set the Cross-Section Rotation to 90 degrees.  The following is what I got.

Since I wanted the top of the framing to align with the level, and the above was the result, I was reminded that the cross-section rotation’s base point is the intersection of the workplane and the Lateral Justification, so I changed the Lateral Justification to ‘Side 1’ and got my desired result.

This got me thinking – what if I had wanted to move the framing more than just a little?  It is a known quirk that the z-direction offset doesn’t work quite right when the cross-section rotation is set to anything other than zero, but I haven’t seen any documentation to explain what is really going on so I thought I would figure it out.

The conclusion is this: assuming the cross-section rotation is set to a value, a, if you enter a value, z, into the z-direction offset, the member will move as follows:

Vertical movement = z*cos(a), where up is positive

Horizontal movement = z*sin(a), where left is positive

I could paste a ton of screen shots here showing a bunch of variations, but I encourage you to go play with these settings and see what happens.  Take particular note of the fact that cross-section rotation values greater than 180 degrees causes positive z-direction offsets to cause movements in the negative directions.

So what is the solution?  I would suggest using the start and end-level offsets for z-direction movement.  However, if there is a reason why that is impossible, or if you just want to test it out, the following equations will produce desired results.

For a desired vertical offset, z, a cross-section rotation, a, and assuming no horizontal movement is desired:

In z-direction offset enter: z / cos(a)

And then move the framing member to the right this amount: z*tan(a)

For a workplane that is not horizontal, the above equations work if vertical is taken to be perpendicular to the workplane and if horizontal is taken to be parallel to the workplane.  To get global horizontal and vertical movements, the angle of the workplane would have to be considered, as would the cross-section orientation (Normal vs Horizontal) since each case would require different equations.  Since this topic seems to be complicated enough, I will not go into any more detail on non-horizontal workplanes.

Given my affinity towards math and families, I would love to be able to incorporate these equations into the framing families (since the equations are valid for a 0 degree rotation too), but of course none of these parameters are available until after the element is loaded into a project, so I will put that on hold for now….but I reserve the right to revisit this idea!

Beams Tied to height of Columns

When Revit 2012 was released there was this new feature on structural beams that didn’t get addressed in any of the “NEW” documentation.  I stumbled across it during a training session and have been using it so much that it has become second nature to me.  This week while using this tool one of my clients saw it and had no clue it was even there.  So I told them that I would blog it so they can have documentation on it.

If you have a a beam connected to a column, similar to what is shown (element types can vary), there is a value in the instance properties of the beam called “Start/End Attachment Type”.   This property can be changed to End Elevation or Distance, by default the value is End Elevation.  End Elevation maintains the value of the beam to the placement level and Distance orients the value to the join location on a column.  So if you are wanting the beams to move up and down with the top (or bottom) of a column then you simply change this value to Distance.

.

.

.

.

Once the value is changed to Distance then you will see two new properties show up for the beam, “Attachment Distance” and “End of Referenced Column”.  Attachment Distance option allows a user to put in a value for an offset of the beam to the top of the column, so that the beam will still move up and down with the column just be that given value away.  End of… allows the beam to be either associated to the Top or Bottom of the column.