Yearly Archives: 2012

Instance based Family System Parameters

A question came up on how to change a family system parameter from Type based to Instance based.  It made me think of the good old days when we had to start a family, say structural foundation or door family, change it to a generic model family, go into the family types and modify the values from Type to Instance then change the family type back to the original category.  Good news is this changed way back, now all you have to do is select a dimension with this value and toggle the check box in the options bar to Instance.

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

 

New Exciting Release Slated for Late April

Dezi and I haven’t been blogging too much lately because we have been involved in this beta.  It has meant a lot of appointments with professionals, anticipation and excitement.

This release will come in a compact package but will continue to grow in the upcoming years.  Will probably become expensive in future years but we are hoping the product will be worth the costs.

This release does not use the ribbon interface however has an interactive touch interface which is user friendly and pleasant on the eyes and will make you want to keep playing with it.  The 3 dimensional representation seems lifelike.

Some of the features that will be available include super purge, hopefully the auto-sleep feature will work but has been known to be a bit glitchy.  It is said to have an artificial intelligence-like learning capability that is supposed to advance the more it is used.    Many other features will keep us up at night until we figure them out.    User customizable carrying cases can be added as well as  many accessories, but they must be purchased separately and can vary considerable in price.

The product is a direct result from nested family capabilities yet the final naming of the product is still yet to be decided and if you would like to weigh in feel free to add comments to this blog.  If you want to see a sneak peak of the box shot click the link below to see a preview.

BOX SHOT

 

Stacked Walls and Design Options

A client was having an issue working with design options and stacked walls the other day.  When the stacked wall was selected it wouldn’t allow it to become part of a design option.  I started an new file and had the same issue as he was having, however when I went to do it again for this post the issue didn’t happen again, then I realized it had been changed in Revit 2013.  I thought I should post it anyway in case this issue does happen for others still using 2012.

As with any element if the host is going to be apart of the design option then anything hosted to it must be part of that same option.  For instance all doors and windows hosted in a wall must be part of the same design option the wall is in.  Stacked walls are the same, each wall type that make up the stacked wall are hosted to the stacked wall (at least we will say that for this situation), so the stacked wall and all of the individual wall types that make up the stack must be selected in order to become part of a design option.  For this to happen the “Tab” key will need to be used to select the individual wall types.

In Revit 2013 they improved on the entire selection process for adding elements to design options.  Most notably if you select a host element now everything associated with that element will become part of the design option.  No longer do we have to select all the doors, windows, etc they just go.  HUGE improvement for working with design options in my opinion.