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.
I will be presenting two talks, one on Navisworks clash detection and another on documenting MEP models in Revit, as the Singapore BIM mandate keeps marching forward toward the next goal of an FM mandate it’s important to get a handle on tools of the trade and how to make them work for you.
You can register to attend the event on the RTC website here.
Have you ever had a model that you’ve wanted to remove the project/shared parameters from quickly without having to go through the mind numbing process of clicking the series of buttons to remove each individual parameter?
Have a crack at AutoIT, it’s a scripting language that you can either run direct from the editor or compile into *.exe files.
; usually a good idea to put this in so you don't max your CPU
; open your project parameter window and hit go!
ControlClick("Project Parameters", "", "[CLASS:Button;INSTANCE:3]")
ControlClick("Delete Parameter", "", "[CLASS:Button;INSTANCE:1]")
I had a series of about 50 hodge-podge parameters that I wanted to remove and this little script cycled through them in a few seconds. Of course it only really works if you want to get rid of all the parameters in a project or template, but that is exactly what I wanted to do.
Hopefully someone else will find this one useful too.
In Australia and likely elsewhere, a lot of people believe that BIM = Revit, however this is certainly not the case; there are many other software packages out there and if you need to collaborate with these software packages, chances are you will need to use IFC files.
IFC stands for Industry Foundation Class, it is a platform neutral file format that is not controlled by any of the software vendors.
For those that haven’t worked with IFC files before, there are a few things you need to keep in mind before you jump headlong into working on a project where IFC is used for collaboration. I will specifically be talking about my experiences working with IFC outputs from ArchiCAD.
You need time
Depending on the size of the project, the process of importing and IFC file into Revit could take a very long time. IFC imports can be anywhere from almost instant to a few days. You need to make sure that you clearly communicate this not just with your engineering team but with your architecture design team as well.
It’s very important to keep an open line of communication with your architect. Pick up the phone.. or more importantly answer the phone! Don’t let problems go unsolved sitting in someone’s inbox. 5 or 10 minutes spent on the phone with the architect might save hours of time for both of you down the track. They will be able to split large projects into smaller chunks or limit what elements are being exported from ArchiCAD so that the heavy lifting your hardware needs to perform is more manageable.
In all my testing, Revit appears to use 2 cores at most when importing IFC files. If you have a fast multi-core machine, you can set more than one file to import at a time. I highly recommend selecting each instance of Revit that you have open and setting the CPU affinity in task manager. This forces windows to spread the load across your CPU, maybe I’m imagining it but I found that if I didn’t do this all Revit processes seemed to share the same few cores; without doing this my 6 core/12 thread Xeon CPU sat at around 12% utilisation where as if I forced each instance of Revit to use certain cores I could push my CPU usage towards 80% utilisation. The problem you will face though is RAM. On some IFC files even 32gb is not enough.
For the Revit users on the team, push for the use of 2015 or newer; there really is no reason to dilly-dally in the comfort of older versions of the software. Revit 2015 brings to the table more efficient IFC imports through the Link IFC option. It is not a true IFC link, Revit actually converts the file to an RVT on the fly, in my testing using IFC Link instead of the open IFC method saves up to 60% on import times. The first iteration of architecture I received for the most recent project I’ve been working on took just on 3.5hrs to import a 286mb IFC file using Open -> Open IFC where as using Link IFC on the same file took only 24mins.
With some helpful splitting of models by the architecture team you can improve your workflows significantly.
I have worked on two hospital projects authored in ArchiCAD and we split the FF&E from the building fabric. The building fabric was always imported first and the FF&E flowed on afterward. We always requested up to date DWG exports of the floor plans that could be overlayed to reflect the FF&E as well.
You need DWG files
DWG files will play a very important role when working with IFC files, they will allow you to keep up to date quickly with furniture layouts but they’ll also help speed up your model. ArchiCAD seems to be able to handle higher polygon counts far better than Revit can which leads to glorious, highly detailed furniture models, trying to run a model with the 3D furniture models loaded in is going to slow you and your team down to a crawl. You don’t need to coordinate in 3D with a chair, but you may need to know where it is so you can place power and data outlets or other equipment. DWGs are the best way to do this.
Make sure you follow all the usual rules about DWG files. Keep them clean. Link them into their own host model, don’t insert. Never link or load them into your live model where possible. There is an article in the June 2015 AUGI magazine which goes into detail on best practice. Something they suggest that I’ve never tried before is to insert the DWG files into an *.RFA file and then stack the *.RFA files in the host model. If it means that it will be less problematic, go for it.
IFC files do not carry ceiling tile information
Don’t worry though, you asked for DWG files remember? Depending on what you want to show on your plans, you may need to link the DWG at certain heights so that they fall within the view range of your ceiling plan.
Again, follow best practice with linking in DWG files to a host model. Do not locate your RCP DWGs in your working model.
You need to understand coordinates
And you need to understand them well. When working with IFC exports from ArchiCAD, you will be working at the architect’s origin location, not shared coordinates. As much as it has probably been drummed into you to “always use shared coordinates” there is nothing actually wrong with using an origin to origin system.
In fact when importing an IFC file you don’t get a choice of how to bring the file in, Revit will automatically import at origin to origin. This poses a problem if you’re also collaborating with a civil team, but this is pretty easy to overcome, you just need to make sure that it’s part of your workflow.
You can’t host families to an imported IFC
Unless you’re going to draw hundreds or potentially thousands of reference plane, forget about using those face hosted families that you’ve become so accustomed to.
As you’re probably aware, all elements in Revit have a unique identifier, also known as an element id or global unique identifier (GUID). For whatever reason, Revit does not have a consistent way of applying GUIDs to imported IFC elements. This means that today the wall on ground level at grid intersection D5 might have an element id of 654321 and next week, it could be 751155 and as a result your hosted families will become orphaned. Or worse yet, maybe now a different wall from level 10 has picked up that original 654321 identifier and now your data outlets have been automatically moved to that new location by Revit.
At least this was the case in earlier versions of Revit. In newer versions of Revit you simply are not even allowed to host a family on an imported IFC face at all.
My advice would be to develop a suite of unhosted families. IFC is going to become more prevalent in the future especially as some governments around the world are mandating the use of IFC so you’re going to have to deal with it more in the future, you might as well be prepared.
Never ask the architect “Can’t you just do it in Revit?”
Unless you want the architect to ask “Well can’t you just do it in ArchiCAD MEP?” then don’t; and yes in case you were wondering there is an ArchiCAD MEP. Seriously, show a little respect. Sure Revit has a larger market share than ArchiCAD but that is not the point. BIM shouldn’t be and is not restricted to a single piece of software.
At the end of the day it’s not actually that hard to work with IFC files. Sure you have to think about things a little more but that’s OK because how boring would life be if every day was exactly the same? The most important thing if you’re on your way to higher levels of BIM is to make sure you get the rooms imported from the IFC file, that way you can still create MEP spaces and in turn perform all your MEP calcuations quite successfully. Otherwise if you’re still finding your feet in BIM and Revit is primarily a 3D documentation and coordination tool, working with IFC isn’t as hard as you might think it is.
I’m trying to use the same concepts to export all structural columns. The node you used (family types) only exports 1 type at the time.
Do you know if there’s a node that lets me export all types of the column family I use in the project?
The node that you want to use to do this is All Elements of Category which you need to feed with your selection from the Categories node.
I thought I would share an example of how I used this node to generate individual type marks for all the columns on the project based off the family name and the level that the column is located on.
Of course generating the mark parameter from the family name means that you need a fairly solid and consistent naming convention in place. You could also use other type parameters within the family, this is just the method that I chose as an example.
Before we get started, I have used the Revit 2015 Sample Structure Project.RVT file and renamed the family types like so
The overview of this particular example of the Dynamo Script looks something like this, so let’s step through what it is doing.
Getting started, we use our Categories node which we use to select our Structural Columns category. As mentioned earlier we feed that into the All Elements of Category node.
Stepping through the top row, our elements feed into the Element.GetParameterValueByName node, and we’re picking up the Base Level parameter.
We then pass through to the Level.Name parameter which gives us the level name as you see it in the project browser as a string, which in this case is “01 – Entry Level”. Using the String.Split node we split the string in half using a Code Block node and entering ” “; into the code block to denote the space.
Think of this as the same as the Text to Columns command in Excel.
This gives us a list that splits the level name into
“01” “-” “Entry” “Level”
From here, run the data through the List.Transpose node and then finally into the List.GetItemAtIndex node, here we need the row at line 0 so we use a Number node to define the index.
You can alternatively use a Code Block node and enter “0”; as the code which works the same as the Number node.
On the bottom row we are taking our family type name and pulling out the type itself from the string that is returned. Even though when scheduling the Type parameter returns just the type, the string that is actually returned from Dynamo is in the format of Family Type: CRC 450, Family Name: STR_CONCRETE_ROUND_COLUMN.
So following a similar sequence to the top row, we split the string down to what we want which is “CRC 450”, to do this we need to split the string twice; first by the colon ( : ) and then by the comma ( , ). As you can see in the screenshot we need to transpose the list and pull the data at each row twice to get what we’re after.
At the lower right corner there is a number generator. It is simply stepping from 1 to 200 in increments of one. Make sure to run the Number.Sequence node through the List.Transpose otherwise you will cause Dynamo to lock up while generating incredibly long number strings if you feed the sequence directly into the mark parameter.
Finally, we use a Code.Block node to concatenate the data we have pulled into a single string. The code block is simply a+b+c+d; which gives as four variables of the same name that we can feed the rest of our data into.
I have then created another list which consists of the Element ID and the string, we then finish up by selecting our string and populating the mark parameter as per my bi-directional Excel post.
Of course there are other options where you can generate the mark parameter from other type parameters in the family, I just chose to use the type name as the example this time around as I could show how you could break down a long string and the data you need from it.
There has been a problem with printing solid fill that form family symbols in Revit using vector graphics since.. well.. forever.
You might have experienced it yourself in the past, I have found though that it mostly affects electrical documents as they have a high proportion of symbols that use solid fills; maybe you have had an essential GPO print as a non-essential, emergency light symbols not printing correctly or distribution boards showing as control panels.
In the engineering world, these problems can be pretty disastrous, especially during the tendering process. The last thing you want is contractors putting together a price based on incorrect symbols due to prints that just aren’t quite right.
The problem is fairly well documented as well with questionsaskedandblog posts made and everyone just seems to deal with it by responding with “Oh yeh.. You know you should be printing in raster right?” or better yet “Just replace all your hatching with really close lines”
Because afterall, that is what everyone wants to spend the rest of their life doing; drawing a series of lines to emulate a hatch pattern so they can overcome printing problems.
Some people even say that it has been fixed, but I can tell you for certain that working on a project in Revit 2015 the problem is definitely not fixed.
But is it a Revit problem? I’m not so sure. What if I told you that you actually can print your solid fill patterns and print them in vector? You’ll kick yourself when you realise how simple the solution is.
Dots per square inch.
That’s it. The DPI setting you have configured your PDF printer to is the problem. I’ve done a comparisson on some electrical GPO families that I have created between Bluebeam, PDF995 and BioPDF. In each case I printed in 150, 300, 600 and 1200dpi, with the exception of PDF995 where 144dpi was the closest available option to 150.
Basically the root cause is that the filled area you are trying to print is considered to not be printable within the DPI setting you have selected, so it is skipped.
As you can see on these particular symbols, the half shaded GPO symbol that signifies a UPS connected GPO does not print correctly at 150dpi at all, the filled region does not print at all other than the line down the centre which is the fill boundary.
At 300dpi, our symbols actually print pretty well with only a few small glitches in the symbol but nothing to really worry about as you can tell that the symbol is clearly half shaded.
600dpi seems to be the optimum for these particular symbols with clean filled regions, interestingly jumping up to 1200dpi seems to introduce some strange glitches to the fills again, but they only really appear when zoomed right in on the page.
Don’t take my word for it though, give it a try yourself! I have found that although 600dpi seems to be the sweet spot for the families I’ve shown above, it varies from symbol to symbol. Some almost identical GPO symbols created by a colleague still don’t print correctly until 720dpi.
Keep in mind that higher DPI prints will take longer, especially if they’re forced to print in raster mode. Print times due to higher DPI settings or due to raster printing is an argument I’ve had in the past but personally I think the extra time taken to print a correct set of documents is well spent compared to saving a few minutes to deliver drawings that don’t quite hit the mark.
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.
I was having a bit of trouble with a corrupt 2015 Building Design Suite Premium (BDSP) deployment from Microsoft’s System Centre Configuration Manager (SCCM) or Software Centre as the end user would know it.
Unforunately as the story goes, the deployment was installed on my production machine to fix some other issues with Revit 2015; next thing you know almost 2 days of 2015 downtime.
One of the most frustrating parts of the whole process is that although BDSP installs all the software you require in one seamless install package, uninstalling is not as easy. You need to go through and uninstall each program individually, in my instance that was 42 separate uninstalls I had to click though.. in the words of Kimberly Wilkins..
You’ve probably realised by now that mind numbing clicking is not how I roll, so I went on the hunt for a solution, I very quickly stumbled across Mick Pletcher’s post about doing the exact same thing with Building Design Suite Ultimate using a powershell script.
The trick was to get the GUIDs for each part of the 2015 BDSP package as they would be different to Mick’s 2014 example.
You can do this with Windows Powershell, if you don’t have Powershell installed, simply head to Programs and Features in Control Panel and select Turn Windows features on or off scroll down through the list and makes sure that Powershell is checked
Once in Powershell simply type the command wmic product get > c:\installedprograms.txt.
You will have to wait a moment or two depending on how much software you have installed but this will write a *.txt file to your C:\ which will list out all the software that you have installed on your machine.
You can then import the text file to Excel as a fixed width import. It will take a few moments to correctly place each column but once you’re done you should have something resembling this
I sorted the data by the install date, as the BDSP package is installed at the same time. This made it easy to grab the information for the software that I wanted to get rid of. The information that we need is Description and IdentifyingNumber.
I simply put the information that I needed on another sheet and then concatenated the data in Excel so it matched the format required in Mick’s script, I then removed the 2014 BDSU information from the script and replaced it with my 2015 BDSP information.
Now simply save the script as a *.PS1 (that’s a one, not a lowercase L) file, head into Powershell to where the script is saved – I saved mine as C:\2015uninstall.PS1 to run it just type in .\2015uninstall.ps1 and what BDSP uninstall without any further user intervention.
If the script doesn’t run you may need to change some settings in the Group Policy Editor. Head to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Powershell, edit the Turn on Script Execution policy to be enabled and change the execution policy.
The Allow local scripts and remote signed scripts should work, for security just remember to change the setting back to disabled when 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.
Just imagine how much easier this could make your life when setting up a large multi-model, multi-discipline project. You setup a master control file that hosts your levels, grids and now also your scope boxes. Link in that master control file to each of your S+MEP models and pull in consistent scope boxes across the project.