Revit Implementation: Workflow Tricks
As an office begins the transition to Autodesk® Revit®, full immersion is typically rooted in learning the toolset and working methodologies, with standardization and office-wide management taking a backseat to "getting functional." When the dust settles, Implementation Managers find themselves looking for the handles to make the office function as a unified machine. Aaron Maller of The Beck Group, in Dallas, Texas, has spent five years working in Revit implementation and standardization and knows how to manage the office seamlessly, with a few simple workflow tricks.
Where is my CUI File?
Anyone with years of supporting AutoCAD® or AutoCAD® Architecture has an intimate relationship with the CUI file editor. We know it is where we can push changes to our users, update UI configurations, alter keyboard shortcuts, file pathing locations, and so on.
[media1}
Figure 1: AutoCAD Architecture CUI Editor
Something similar exists in Revit, although not as editable, and not as transparent in location or functionality. Prior to 2012, we referred to it as the Revit.ini file—a text document residing in the Program Files directory that was written by the program when options, settings, and paths were changed. For years, power users have grown accustomed to editing the Revit.ini file manually and burying it in the root directory of their Revit deployment, which would populate the machines being deployed to with the correct configuration settings.
Figure 2: Revit.ini file (2011)
While it still exists, the Revit.ini file protocol underwent serious changes that may throw many implementers for a loop as they prepare to deploy Revit 2012. First, Revit.ini no longer resides in the Program Files directory. Users who aren't aware of this change may drop it in the root directory of their deployment and discover (after deploying) that the stock Revit.ini file is used. In an effort to better support Remote computing applications and roaming profiles, Revit moved the Revit.ini file to a location in the Users directory (Win7), or the Documents and Settings/Username directory (pre-Vista). What this means, however, is that the location for the Revit.ini file may not exist until that user has logged onto the machine already. How this is handled is through a new file called "inifile.xml." This document exists in a number of places, but for our deployment I edited and replaced the one at: [AdminImage]/x64/RAC2012. (The same rules apply for all three verticals.) Bonus: With this new configuration, this one XML file serves as the installation configuration file for all three verticals, even using different templates and different file paths. (At The Beck Group we use all three Revit Platforms.) If you are accustomed to having a GUI for editing configurations, editing the XML may feel daunting at first. The downside of this workflow is you won’t know if part of your XML is faulty until you launch Revit and have unexpected results.
TIP: If you don’t feel comfortable editing the XML directly, Autodesk has released a Deployment Utility to help with this:
http://usa.autodesk.com/adsk/servlet/ps/dl/item?siteID=123112&id=17169612&linkID=12828318
Figure 3: inifile.xml file (2012)
On the surface, this file may look like abstract code. These lines, however, are at the core of Office Standardization and Management. This file contains controls for all of the following and more. Highlighting and Selection Colors, Paths and file locations for: Project Template, Content Libraries, Content Templates, CAD Import and Export Layer settings, "Places" Directory Locations, Custom Rendering Material libraries, Lookup Tables, Warning message suppression, User Interface settings, Help file setup, and Content search locations. With the new XML setup, you can also locate different templates and different options for the different verticals of Revit, saving you from having to write an XML for each product.
No one was more up in arms about trying to manage an office with 2012 and XML than I was, to be sure. The perceived ease of use (or difficulty) of Revit lies in how accessible the right solutions are, and how inaccessible the wrong ones are. For me, this means having paths that work correctly when the user clicks on them, an Office Library that automatically shows up, and settings that don’t need adjustment by every user. With the move to XML, this was daunting. So, a few notes and samples from the XML file:
But I Don't Write Code!
What we once wrote in the Revit.ini file as:
[Directories]
FamilyTemplatePath=\\office network\Revit\2012\Beck Family Templates
DataLibraryLocations=Families=\\office network\Revit\2012\Beck Family Content (3d), Detail Comp=\\office network\Revit\2012\Beck Detail Components (2d), Model Groups=\\office network\Revit\2012\Beck Model Assemblies, Drafting Details=\\office network\Revit\2012\Beck Drafted Details, Material Images=\\office network\Revit\Beck Material Maps
ProjectPath=C:\Temp
Now gets written in the inifile.XML as this instead:
<Section Name="Directories">
<Data Key="FamilyTemplatePath"><![CDATA[\\office network\Revit\2012\Beck Family Templates]]></Data>
<Data Key="DataLibraryLocations"><![CDATA[Families=\\office network\Revit\2012\Beck Family Content (3d), Detail Comp=\\office network\Revit\2012\Beck Detail Components (2d), Model Groups=\\office network\Revit\2012\Beck Model Assemblies, Drafting Details=\\office network\Revit\2012\Beck Drafted Details, Material Images=\\office network\Revit\Beck Material Maps, DALFS Jobs=\\dalfs\Architecture\Job_Files]]></Data>
<Data Key="ProjectPath"><![CDATA[C:\Temp]]> </Data>
It gets tricky, just as it did with the old INI file. Some multi-entry fields are separated by commas, some by "pipes," and some require the full [CDATA] tag at each entry. A longer and more in depth discussion of all of these specific entries can be read at RevitForum.org, where a core group of users were conducting Trial and Error while hashing this out. Things that are often overlooked that I would be sure to include as part of any good implementation strategy:
Places. In the XML these are the locations considered "Data Library Locations," but they show up in all of the Open, Load, and Link dialogs in Revit. I include one for the Modeled Content, one for Detail Components, one for Standard Drafted Details, one for modeled assemblies (RVT files for Insert > Load as Group), as well as one that leads to the offices Job Directories.
Figure 4: Places directory (2012)
One minor defect that can set you back hours (and gigabytes of space, if you aren't aware) is that in 2012, the deployment configuration cannot disable the Out of the Box Content Download and Install on its own. Sure, there is a checkbox that you can deselect to "skip content instant," but it will still ping the Autodesk server and download it all, onto the local machine. If you don't use the Autodesk content at all (even if you do, it’s probably on your network), you’ll want to defeat the content installation. This is in another XML file called: master.rac.xml, master.rst.xml, or master.rme.xml. Basically, you want to wipe out everything in the file that says Content Packs. Doing this drops your entire installation time to under 15 minutes.
Speaking of Pathing Files...
Where do you want all of those files to live? I've had the benefit of implementing several offices making the transition to Revit, and I've found a pretty simple system that works quite well. A few rules of thumb:
1. Separate them by Revit Version. We have a parent "Revit" directory, and then each year’s release is a subdirectory. Revit\2012, and Revit\2011. Why? Inevitably, some projects will get left in last year’s version, with unwilling consultants who cannot upgrade, and so on. Only carrying one library (and having to upgrade it every year) causes headaches. There are some files, however, that aren’t version-specific. You will want an absolute path for these when projects get upgraded and you still need access to them: Rendering Material bitmaps, IES files, RPC files. These we keep in our parent Revit directory, in a version neutral zone.
Figure 5: Revit directory
2. Separate Office from Autodesk Content. If you are in an office that still makes use of the Autodesk Content, keep them in separated subdirectories of "Autodesk Content" and "Office Content." That way, you have a quicker road when upgrading to the newer library when new versions come out, without having to sift through directories of old content. This will also help you when you copy your directory next year, to upgrade it to 2013.
3. Location Location Location. Now is a great time to mention that many of us have multiple geographical locations. The Beck Group has Revit in six locations, running off four servers. Depending on your office’s infrastructure, you have one of two possibilities: Distributed File System, and Not. If you are on DFS, much of the library is a non-issue in most of the locations, as they pre-populate everywhere. If you aren't on DFS, I recommend making sure each locale has a similar folder structure and build the exact same "Revit/2012" directory on their server. That way, you are one Sync program away from having everything populate around the globe overnight.
4. Templates and Configuration Files. This is a great time to mention that all of the files Revit uses as References (text files, etc.) ought to be stored right in with your content and your template. Why? Through either DFS or Sync, you already have those directories syncing. This means that with a very simple "Find and Replace" edit in your XML file "Replace THIS_location/ with THAT_location/" you have XML files ready to go for each office. Again, for DFS this is a non-issue. This is also a simplicity issue. Do your users currently know where the office Shared Parameter text file is? If not, how can content get created and manipulated consistently?
The Content Itself
Opinions vary widely on what is "acceptable" as far as content is concerned, but I have found there is actually a decent return on making sure all of your content is built in house. An arduous task, you might say, but let’s go back to the discussion regarding an Office Standard Shared Parameter text file. When you adjust the "cabinet height" in two different families, are you certain they are referencing the same location in the piece of content? Are all of the parameters you need to schedule and quantify either Hardcoded or Shared Parameters, so you can schedule them? What about drawer heights? Even if you pilfer content from other locations, taking the 15 minutes per family necessary to replace all of the parameters with your office Shared Parameters means your content can get much more intelligent, much faster.
Nested Brick Quoin Family (The Beck Group – 2012)
It also means that since you have given that family its due diligence, making subsequent changes to family (and nested family) variants is also a much more intelligent process. This means models can get built faster (nested with parameters tied together, and you know the parameters) and that they can report a better "I" in the BIM: better data, and the data can all be scheduled.
Parent Brick Quoin Family – Instance Parameter stretchable (The Beck Group – 2012)
Quoin Schedule of Shared Parameters (The Beck Group – 2012)
The Content Creaiton and the Content Creator
The above are the paramount reason why any solid office wide implementation needs to be managed by a "Gatekeeper." If not one person, than a small and select team to be working through every category: What parameters get used, what family templates get used, who is building the family templates and the standard pieces of content, and so on.
Family Templates should be set up by the Implementation Manager, with the Shared Parameters the office is intending to use and to schedule. The gatekeeper premise doesn't negate the general office staff from building content, but I find it critical that one person or a small team be handling QC/due diligence, on content before it makes it into the office library. Are the formulas functioning correctly, are the parameters correct, are they reporting the way the office likes?
Another tip is to have IT set up a dedicated Domain log-on for that use: Revit doesn't "live link" to the content, but the "Edit Family" button recognizes the "home location" of the originating content, and it’s very easy to save over content accidentally, even when you are the Implementation Manager.
The Content Gatekeeper's function also has to be one that mitigates risk in bringing content from external sources: Free downloads, pay downloads, manufacturers, specification sites—all offering turnkey Revit content for a click. Still, when 14 family types of doors end up in a project, and there are 60 instances that will not schedule (because they do not use your Family Template with Shared Parameters), you will be stuck hacking at the 15 door families to force them to work.
Doors: office-built versus downloaded. Can you expect them to play together?
The Content Dissemination
This begets the following issue. Now that I've built all of this custom content, with all of my Shared Parameters, and all of my validated Parametrics, does anyone in the office know where it is? At the risk of making this a shameless product plug (it isn’t shameless; it isn't my product at all!) remember one thing: perception, for your users, IS reality. A perceived level of complexity and difficulty means Revit is difficult to use. Content Navigation should be in their hands, and instantly.
I have tested and vetted six or seven different solutions, some more complex than others, but at the end of the day, what I wanted was my Design Palette from ACA! I was ecstatic to learn last year that Kiwi Codes (Kiwi Codes Solutions Ltd.) offers an external app that functions in just this very way. Plus, since we are not employing DFS in this office, we simply make the text files that run the Family Browser at the Central location, and they populate out over filesync. The best part? It updates in real time. Once a piece of content is added to the library, it shows up immediately for the staff, without having to constantly send emails "new content added to plumbing fixtures." It will mean wanting to reorganize your library a little bit, but it’s worth the effort. Remember, perceived ease of use means ease of use.
Kiwi Codes Family Browser: lightweight, instant update, searchable, inexpensive.
A Template for Your Office
When it comes time to close down this article, we get to the topic that probably should have consumed the majority of it: The Revit Template, the .rte file. Think of this as your coveted Layer States, your Base file for XREF, your Max Scene ready for import. It defines everything your project could, can, and will be. How much time do you have invested in it? If you follow my blog at www.malleristicrevitation.blogspot.com, you can find the full text of what I believe a good Revit template should have, but ask yourself this question: "Am I doing something that has to be done on every single project in the exact same way?" If the answer is yes, it needs to be done in your Project Template. A complete list of things to include can be found on the blog, but don't be afraid to make them mean and massive. Ours sits currently at a hefty 45MB and I see it only getting bigger. The file needs the information regardless—it’s just a matter of whether you load it in once or someone in your office does it every week.
