Are you new to Revit and starting to create customised content for your models? You have all the pipework and fittings and now you’re onto the annotation tags.
You’ve come to a tag that you need a few different variations, a few instance based yes/no parameters are what you need right?
Well, not quite.
For starters, using instance based parameters to control the visibility of tags is just going to be a pain to manage in your project. Just imagine each time you need to click various options on and off. No thanks.
It’s not a problem you will encounter anyway, as instance parameters aren’t presented to you in the way that you’re expecting them to be. They’re not displayed in the properties dialogue like they are in other families. Lucky for whoever was expected to click hundreds of yes/no checkboxes in your model.
This particular example, the user wanted to set a variation of their family using a family type drop down set as an instance parameter, but there is of course no way to access this once you place the tag into Revit.
The correct way to approach (shown in the image) this is to have parameters set to types in your family and define family types (steps 1 & 2).
Make sure that you set all the relevant parameters for each type, then once in Revit, select the tag type that you want to apply (step 3).
A lot of people ask me if I’ll give them my Iplex floor waste gully family. The answer is always no, not because I don’t want to share, but because I would rather people learn and understand for themselves rather than taking the easy way of “grabbing something from the internet”
I recorded a video on how to create the FWG a long time ago, but after a bit of back and forth discussion on Youtube, I have decided to pull that old video out and record some voice annotation so you can follow along.
I do apologise about the audio quality, I only had my junky work headset to record with.
Yes, this is how I spend my nights in hotels when travelling for work.
So, I’ve been asked maybe 4.. 5 times in the last week or so “How do I batch update Revit family files?” so for those that don’t know how, here is a run down of some of the options available to you
Bulk File Upgrader – US$99
Harry Mattison of Boost Your BIM has written a Bulk File Upgrader program which you can use to upgrade projects, families and templates in bulk. It costs US$99 and has a very simple to use graphical interface which basically consists of selecting the location of files in and files out.
This is a relatively new file upgrade addin that was released just this last week.
The batch file upgrader will scan a user specified folder for project files and family files, upgrade them and save them in the same folder. All backup files are automatically removed afterwards in order not to clutter the folder that is being upgraded.
This application requires minimal input, and works great with multiple library file upgrades. You can grab it from the Autodesk App Store.
CADDaddy Tools – US$12.99
Another alternative is to think about what you want to do in reverse.
James LeVieux sells a great little addin called CADDaddy Tools, it doesn’t upgrade files, but it will export families to a folder location complete with sub-folders that reflect the element category. This is a fantastic solution if you keep all (or most) of your families in your base Revit template. Simply upgrade your Revit template or project and then use the CADDaddy Tools family exporter to export all your newly upgraded families.
You can pick and choose what categories are exported and away you go.
The best part is that CADDaddy Tools is only US$12.99 for the latest version (2017) and gets cheaper for previous releases and for that price, you also get a few other handy tools as well. Once you’ve exported your families, if you have the Revit version as a suffix to your file names, there are a number of free file name utilities out there that you can use you rename your files to reflect the correct version.
Journal File – Free!
If you’re up for something ever so slightly more complicated than the other two options, you can use a Revit journal script. I’ve tested this to work in both Revit 2015 and 2016 and it will bulk upgrade files with ease and what’s better is you can do it for free!
First download this file and extract the contents to the root directory of your family library. I suggest you take a copy of your family library to make the changes to so you don’t lose the previous version of your families.
Run the BatchUpgrade2016.bat file, this will start by cleaning out all of your old family backup files (i.e. family.0001.rfa) and then it will create a list named famlist_rfa.txt
Once you have the famlist_rfa.txt file, simply drag and drop the BatchUpgrade2016.txt file onto the Revit icon on the desktop. Make sure you drag it to the correct icon i.e. Revit 2016.
Now all that’s left to do is watch the magic!
13/10/16 – Script updated for Revit 2017 compatibility. Please re-download the file for the updated script.
At some point, you’re probably going to look like this guy – loading a family and you’ll be struck with the error “Last type in system family “Stacked Wall” cannot be deleted. ” and pulling your hair out.
What makes things more confusing is that the family that you try to load will likely have nothing to do with stacked walls, in fact both times I’ve had the problem has been with title block families.
To fix the problem, you need to open up your journal file which for 2015 is located at
Windows XP: %USERPROFILE%\Local Settings\Application Data\Autodesk\Revit\<Product name and release>\Journals Windows Vista, Windows 7, Windows 8: %LOCALAPPDATA%\Autodesk\Revit\<Product name and release>\Journals
Once in the journal file, search for the term ‘ 0:< DBG_WARN:which is where the information you’re looking for starts. The following is from my journal file:
Jrn.Data “TaskDialogResult” _
, “You are trying to load the family Project-A3 SHEET, which already exists in this project. What do you want to do?”, _
“Overwrite the existing version and its parameter values”, “1002”
‘ 0:< DBG_WARN: Family contains category id -2009630, gstyle type 2, gstyle id 558659. That category id and gstyle type map to a gstyle id of invalidElementId in the project. (In practice, this is most commonly caused by a mismatch between the version number passed to addNewGStyles and the version number in the table in ProjectStyles.cpp, due to an incomplete renumbering of an upgrade.): line 503 of d:\ship\2015_px64\source\revit\revitdb\settings\GStyleElem.cpp.
‘ 0:< DBG_INFO: Write access to host’s DocumentHistory from content doc: line 4573 of d:\ship\2015_px64\source\revit\revitdb\document\Document.cpp.
‘ 0:< Unnecessary nesting;Family\FamilyDocument.cpp;642;FamilyLoad__UpdateReplicasInSmallDoc;N++EB(NB);
‘ 0:< Error posted:
‘ 0:< Last type in system family ‘Basic Wall’ cannot be deleted.
‘ 0:< Error posted:
‘ 0:< Last type in system family ‘Stacked Wall’ cannot be deleted.
In this instance there are 2 item id’s that are listed, you may have quite a few more than just two. Either way what you need to do is open up your family and using select by id tool, select and delete the elements listed as causing the problem.
Once the items are deleted, purge and audit for good measure and load back into your project.
Have you ever come across a project with a keyplan in the titleblock and wondered how to go about managing the keyplan shading? The last thing you want to be doing is clicking every single check box across hundreds of drawings.
In this jumbled mess there are a total of 14 shaded areas on the keyplan. 3 for the basement, 3 for the roof and 8 for ground and first floor. So what is the most efficient way to manage it all?
The answer is integers.
An integer is simply a number that is not a fraction. It is a whole number. In the instance of our keyplan, integers can be used to control the shading for our titleblock by associating those values with an on/of visibility parameter.
In this example, I have used the following number sequences
Basement = 1 – 3 (you could use negatives here)
Ground & first floors = 21 – 28
Roof = 31 – 33
Each of the visibility parameters are then associated with the integer value by simply using the formula KEYPLAN_INT = xwhere x is the value associated with each level and zone. So for example, KEYPLAN_INT = 24 looks like this
But we don’t have to stop there. You would have notice we have two wings on the project that has resulted in the drawings being rotated at 10 degrees, this means on those 3 zones our north point will be different to the rest of the project. We can again use our integer parameter to solve this.
As these rotated views are only on ground and first floor, they are associated with the codes 25, 26 and 27, this means we can control our north point rotation with an and formula nested inside an if formula. The formula that I’ve used is if(and(KEYPLAN_INT > 24, KEYPLAN_INT < 28), 3.091°, 13.091°) so any drawings that have a keyplan integer of greater than 24 and less than 28 will have the north point rotated at 13.091 from north, the remaining drawings will have their north points rotated at 3.091 degrees.
But what about the drawings that we don’t want a northpoint, or a keyplan for that matter? Drawings like schematics, details and drawing lists. The shaded parts of the keyplan already only display if the correct code is used, so we can take advantage of this and simply create another visibility parameter that is associated with the building outline, the additional border line on the titleblock and the north point. In my example I’ve named this parameter NO_KEYPLAN with the formula of not(KEYPLAN_INT = 0). When the integer = 0, everything is switched off.
If you have people that don’t know how to read hydraulics drawings (I’m looking at you Sydney), you can also associate this parameter with Stratman and his sweet 70s style.
So on the left we have an integer value of 24 and on the right, the same titleblock with an integer value of 0.
You can then use your favourite bi-directional Excel option, be it Dynamo, BIMLink or some other alternative, export all the data to excel, set the integers for each sheet, re-import the data and you’re done.
If you have it, BIMLink is a great piece of software with many different uses, from project setup to managing the bi-directional flow of data, through to standards and overall process management.
One of the things I’ve used it for quite a bit is renaming family names and type names bringing family content into line with company naming conventions turning a mess like this
into something clean like this
If you’ve ever ventured down this path, you may have discovered a shortfall in the process due to BIMLink not being able include families in a ‘type link’ with families that don’t actually have a defined type like these ones highlighted below
This suddenly makes the standardisation process a whole lot more time consuming because if you have a lot of families without defined types, there is nothing BIMLink can do to help you. I even spoke with the Ideate team at the Australian Revit Technology Conference recently and they confirmed that this was the case and there wasn’t much they could do to help out as they are limited to what they can do by the Revit API.
I was determined to overcome the issue though, there had to be a way where I didn’t have to manually create a new type for every single family!
My first thought was to export all the families and then use journal files to batch process them, in concept it worked; each file in my list would have a new family type created but unfortunately it would fail after it created the new family type on the families without an existing type – the exact families I was trying to work with. I could continue to process the next file by restarting the batch but mindlessly restarting batch files until all the files were modified wasn’t the solution I was looking for.
In the end the solution was C#. BIMLink might be limited by the API because it is dealing with families within the open model, but I wasn’t limited to that as I’d already exported the family files to my local machine.
I came up with was a somewhat simple C# macro that processes a group of families in a predetermined folder, from there it creates a new family type for each simply named New_Family.
I had initially wanted to create family types named Standard but realised I’d likely run into issues with my macro due to it’s simplicity if I came across a family that already included the Standard type name.
public void ProcessNewTypes()
Autodesk.Revit.ApplicationServices.Application application = this.Application;
string directory = @"C:\INSERT\FILE\LOCATION";
string s = "";
// loop through all files in the directory
foreach (string filename in Directory.GetFiles(directory))
s += "Family Name,Family Type,";
Document doc = application.OpenDocumentFile(filename);
// skip any files that are not family *.rfa files
// create the new family types
using (Transaction t = new Transaction(doc, "Create New Family Type"))
FamilyManager familyManager = doc.FamilyManager;
// this is the new family type name
// commit the changes and save the family *.rfa file
And it was that simple. For me, the macro processed around 350 families in a few seconds.
Once complete, you can reload the families into your template or project file and then process the files through BIMLink as per usual to rename the family and type names.
For any families that already had a determined type and have now ended up with two types, you can simply purge out the New_Family types from the model.
One of the gripes that a lot of hydraulic engineers and modellers have with Revit is the representation of pipework bends in 2D views. It’s something that I fixed up pretty early on, but I’ve come to realise when I come across drawings that look similar to the screenshot below that some may still not know how to fix this.
I’d a quick fix per fitting, the problem will be if you have a lot of fittings to modify, it becomes a long repetitive process.
The first thing that you want to do is to edit the family, and switch to the Ref. Level view, you will be greeted by something that looks like this:
In this instance I am modifying the out of the box Revit family Elbow – Soldered – CU.rfa. If you’re little overwhelmed by what you see on the screen, don’t worry; we’re not touching any of the dimensions or 3D elements. If you need to, you can adjust the scale of the view to change the size of the dimensions, or you can completely turn off the dimensions in Visibility/Graphics (VV / VG shorcuts).
What we are wanting to change is the 2D representation of the fitting, which are model likes of the pipe fitting subcategory. In the screenshot below, I’ve highlighted them in red with the dimensions turn off for clarity.
When modifying the pipe fittings, I like to keep the original linework in the family as a just in case. I usually change the linework to the <Invisible Lines> subcategory or turn the visibility off, you can however remove them if you wish.
To achieve the clean 2D representation that you’re used to, we’re going to create some new linework along with a reference line to control the angle.
First up, find the intersection of the Front/Back and Left/Right reference planes, from the intersection, draw a model line using the Pipe Fitting subcategory on a 45 degree angle (1) and then create an angular dimension between the Front/Back reference plane and your newly created reference line (2)
When you start drawing your line from the intersection of the two reference planes, Revit will automatically lock your line to the intersection point, this is also the point the the fitting is scaled around.
Next, apply the angle parameter to your dimension, the line will snap around to the same direction as the fitting.
You now need to align and lock the endpoint of your line to the reference plane for the outside edge of the fitting.
Now draw the other half of your fitting symbol. You don’t need to apply an angle in this case, just draw the line from the intersection of the Front/Back and Left/Right reference planes to the outer edge of the fitting. Don’t forget to align and lock the line to the outer reference plane.
Once you’re done, flex your fitting within the family editor, changing the diameter and angle. Make sure everything works as expected.
Now load your fitting back into your model or template and check out the difference
For the tee fitting, there is no need to recreate the symbology from scratch, all you really need to do is to remove the ticks by either making them invisible, or changing them to the <Invisible Lines> subcategory.
Lately I have found that a lot of the buzz about Revit is 3rd party add-ins and software. Sure they’re great and save a lot of time in our workflow, but what about making Revit itself do some work for you?
Earlier this week I created a box gutter sump family that replaces an Excel spreadsheet that I used to use.
You simply input the data you would normally enter into a roof drainage calculation sheet into the Revit family, I also added a few more inputs to allow further control over the family. The inputs are
Minimum box gutter depth
Minimum sump depth
Maximum sump depth
From there, all the calculations are built into shared parameters. I decided to use the KG Martin method for sizing (from the CSIRO Experimental Building Notes 1978). Hydraulic designers sizing roof drainage know all too well about h, 2h, Dg and Dmax which were easy to work into the family in a step by step process.
My original effort at creating this family I had devised excessively complicated formulas in an attempt to reduce parameters and what I originally thought to be simplifying the family as a whole. If I had taken advice from my Planning Families post though, I would have started out a little differently. When working through a family, you not only have to take into consideration the 3D elements, but parameters as well. What resulted in an excellent parametric family had absolutely nothing that I could schedule out.
With all the calculations undertaken step by step within shared parameters, I have 17 results I can include within a Revit schedule. The outputs from the family now include data such as:
Catchment flow rate
Calculated maximum flow rate achievable by sump/outlet combination
Depth of sump
h (depth of gutter flow at discharge end)
Dmax (depth of gutter flow at still end)
Dg (Dmax + freeboard)
Gutter high and low points
Td (total gutter depth)
The schedule includes conditional formatting to warn that either the outlet is too small or the sump too shallow/excessively deep. As a further step, I also included a visual warning in the family itself, displaying a text box indicating the error within plan view.
The schedule can then be added to a calculation sheet within the project for design verification purposes.
The data inputs for each sump/outlet can be controlled through the schedule, or the user can double click on the sump within the schedule which will then take them to the family within the project.
The next step is pipe sizing. You would probably know already that Revit does not include a sizing method that specifically applies to stormwater drainage, however I have had some success using the hydronic supply system type with accurate results up to 100l/s which of course uses the data calculated within the family.
For me, being a hydraulic designer and Revit modeller, this family eliminates some double handling in data entry, saving time in modelling and performing calculations. Data entry time is further reduced by creating a fixture tag that pulls the gutter size and sump size from the shared parameters with the family. All for a lazy 90mins development time.