Windows Registry Hack and Model Checker Configurator

Gonna start this post with the ENTER AT YOUR OWN RISK warning.

THIS POST INVOLVES MANUALLY EDITING YOUR REGISTRY AND IF YOU BREAK IT YOU BOUGHT IT. YOUR MILEAGE MAY VARY.

Seriously, if editing the Windows Registry is not your cup of tea, then feel free to skip. I know I said “hack” in the title, but it’s not really a hack. It’s more like a manual tweak.

But “hack” sounds cooler.

I have the privilege of working on the development team for the BIM Interoperability Tools and I love working on software that thousands of users integrated into their workflows. Out of the suite, the Model Checker Configurator is probably my favorite because I get to do some fun “under the hood” things in my Revit models, and can treat the Revit model like a database. Because I am a giant nerd.

What I didn’t like is having to open the Configurator to open my XML checkset file. Who needs all the clicking?! Since it’s an XML file we didn’t want to just take over that file format and claim it for the Configurator in Windows. But I did find a workaround middle ground that I like.

This is where the registry “hacking” comes in.

Add Configurate to XML Right Click Menu

I went into my Windows Registry and made some tweaks that adds “Configurate” to the right-click context menu in any XML file. Obviously, some XML files are not for the Configurator, but for those I just don’t use that option. But for the Model Checker XML checksets, I have a direct access to open that file up in the Configurator.

It’s a pretty easy add, but will depend on what version of the BIM Tools you installed. My examples show it assuming you have 2019 installed, but you can change 2019 to whatever year you have.

Some Background on How the BIM Tools Now Install

Up to the latest major release of the original BIM Interoperability Tools for Revit suite, each tool was installed separately. Now you get them all at once, so you don’t need to install the Configurator separately. It just comes in the box.

Another thing to note is that because you can access the Configurator from the BIM Interoperability Tools ribbon in Revit, and because it is a Windows application and not really a Revit add-in, the Configurator actually gets installed as many times as you have the BIM Tools, so you might have it installed four times. Not an issue, just something to note that you might find the EXE file multiple times. Be sure you point to one you have installed. And be sure you update your registry when you remove the one you are pointing to.

OK, but About That Hack

Right, so it’s pretty straightforward.

1. Open the Registry (I use good old REGEDIT)
2. Navigate to Computer\HKEY_CLASSES_ROOT\xmlfile\shell\
3. Add a new Key and name it “Configurate” (or whatever you want the right-click menu item to say)
4. In that Key, add another new key and name it “command” – this name has to match
5. In command, edit the “Default” item to
   “C:\Program Files (x86)\Autodesk\BIT\2019\Model Checker\RMCConfigurator.exe” “%1”
   Note that I am pointing to the 2019 installed Configurator. If you don’t have that, or if you installed to a different location, point to a RMCConfigurator.exe that you have.
   The %1 is essential, and the quotes are essential as well.

When you are done, it should look something like this:

Then try out right-clicking on an XML and you should now have the option to directly open it up with the Configurator. Yay, saving clicks!

Can You Make This Any Easier for Me?

Yeah, OK. If you trust me (insert evil laugh here) I have exported and zipped up the REG for what you see above. If you aren’t being blocked from potentially malicious files (again, evil laugh) you can grab a copy right here and see if it works for you.

ONE MORE TIME: YOU ARE USING THIS FILE AND DIRECTIONS AT YOUR OWN RISK. I TAKE NO RESPONSIBILITY IN HOW THIS WILL IMPACT YOUR PC.

But it’s pretty easy to remove. Just delete the Configurate key from your registry and you should be back to normal.

Hope this helps save you some time!

The 100 Things Every Revit User Should Know

Back at the old CADD Blog, I just wrapped a series of tips blog posts covering a hodge-podge of tips and tricks for Revit users that I (and many other) have collected over the years. I thought I’d like to collect them all here for easy clicking. Enjoy!

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 1

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 2

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 3

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 4

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 5

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 6

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 7

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 8

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 9

100 THINGS EVERY REVIT USER SHOULD KNOW – PART 10

Revit Model Performance Is Not a Magic Bullet

I get many opportunities to audit and review Revit project models. When I am approached by a company and asked people are invariably looking for that one thing that is slowing their model down. They want a smoking gun and I 100% understand. I like the quick fix, too.

Unfortunately, it’s usually not that simple.

I’m not talking about crashing models or corrupt views. That is often one or a small subset of bad elements that will keep your file from opening correctly (I’m looking at your Detail Groups). I’m talking about the general malaise that seems to creep into some models over time.

I am sad to report that the vast majority of the time, it’s not a single magic bullet, this is death by a thousand cuts that kills a model performance.

So what does slow down your model? Here are some things to look at:

• Clean up and remove your linked DWGs.
• Resolve the Warnings that indicate you have two things in the same place.
• Check out your views with individually hidden elements and find a better way to control what does and does not appear.
• Don’t overconstrain. I like that little padlock as much as the next guy, but the more locks you have, the more Revit has to think about.
• Are you using any in-place families? Make them loadable components, especially if you are using them in more than one place.
• If your design is settling down, it’s time to ungroup those arrays.
• Be sure to model judicially. Watch out for over modelling, especially in families. Only model what you need modeled.

Like I said, I wish I had a magic fix, but usually there is a handful of things that get in there and make things just plain slow. Good luck cleaning up and speedy modeling!

 

BILT and Workset1

In the world of the Internet, I definitely waited too long for a BILT NA 2017 recap. Here’s my summary: I went, I talked, I learned a lot, it was awesome. Seriously, it’s a fantastic conference if you have any interest in technology and the design and construction of buildings.

I might have forgotten to put my name on some slides so I updated my tag to match

I am a nerd at heart, and I am one of those nerds that isn’t exactly “at home” in social situations. But I really have to say that one of the best things about BILT is meeting the people and hearing all their great new ideas.

One of those people I got to meet was Amber Young, an engineer at Affiliated Engineers. We’d bump into each other every so often and as happens, the conversation would turn to Revit… you know… like happens EVERYWHERE.

So, I don’t remember exactly what led to this particular point, but we got to talking about Worksets. I am not a fan of them, especially when used for visibility control. They aren’t layers, and they are one of the most “manual” things in Revit. It’s like a folder that you dump elements into, and that’s not what I want to use to group things in my model; I want to use the data INSIDE the elements. So, I always push for a very limited amount of Worksets, but follow the usual lines… maybe make worksets per geographic areas, maybe do an interior vs exterior, maybe have one for FFE, etc.

Amber kind of blew my mind when she dropped this on me: she said they only have ONE WORKSET in their models these days.

One workset?! I was stunned at the gusto of it. Then my mind clicked into a list of a million questions, but unfortunately, we parted almost immediately, heading to different sessions…

• Literally just ONE workset?
• Do you merge Shared Levels and Grids?
• Surely, you must have a workset for links, or DWGs?
• Do you just leave it named “Workset1” (because that is kind of a cool rallying cry)?

I love the beauty of this idea, and I love that someone is trying it out, but I do need my questions answered! Is anyone out there doing this? Who else has been brave enough to throw of the shackles of worksets and cry “no more will I be a locked down to a manual system of organization inside my database!”?

If you are doing this, I’d love to hear from you. I need to know more.

Linking Excel Data Into Navisworks – Part 5 Wrapping Up

Time to put a nice bow on this whole package. We did a full round trip of exporting data from Navisworks, adding some more data, and then bringing it back in to the Navisworks file. Here are some general grab bag thoughts and resources you can use.

This is a really powerful addition to the Navisworks solution. Having the ability to embed straight up data into the model should open a lot of potential opportunities for leveraging existing data in other formats.

The connection to your Excel file is live, as far as I can tell. Every time I made a change in Excel and then saved it, that change was immediately reflected in my Navisworks property (or at least I had to deselect the item and then select it again, and then I saw the new data). One thing to remind you about: watch out for your cell data type on the Excel file. If the column is “General” and you put a number in, Navisworks might add some decimal places to it. And a weird hiccup is when your entire column is all numbers except for a single cell. That cell’s value won’t get applied in Navisworks. It’s like one of those cells defines the data type and if it finds one that doesn’t match, Navisworks ignores it. I don’t have a lot of proof for this theory, but so far it holds up.

These connections can be exported and imported if you set it up once and need to export it around. I imagine you would have to be careful about the ODBC driver settings hopping from one PC to another, but it is an option.

And you can use any other ODBC connection that you want. MSSQL obviously comes to mind, but so does MySQL, and I’m confident many other web based data sources can expose their data through ODBC. Frankly, as a nerd, i’m getting excited about the possibilities.

A quick link here to W3 School’s SQL page, if you want to start diving into refining your SQL statements; there is a lot of power and potential there that you could do when you are building your data links. My example is a very specific one to one link, but you could easily make a connection that populates data for all your windows, or all materials of a specific type. You just need to adjust your SQL statement and make sure the data in your data source fits.

I hope you got some good information out of this series, and if you are using a Navisworks data link to pull in some data that is useful and exciting to you, we would love to hear about it below.

Linking Excel Data Into Navisworks – Part 4 Connecting Excel to Navisworks

This is the last stop on our journey. We have made selection sets in Navisworks, exported a custom list of data to a .CSV file, opened that file and added more data in Excel, and now it’s time to get that new data to connect up to our items in Navisworks.

We need to get a little technical here. To accomplish this connection, Navisworks relies on your Windows’ PC ODBC connection drivers. This is how Windows manages what databases can be opened, and in this case we will be telling Navisworks that our Excel file is a database.

There is no one size fits all solution, but this step is usually the bumpiest. There are different versions of Windows, and different installers for the ODBC connectors out there, so I cannot tell you how to make sure you have the right one. A couple quick tips:

• Be sure that if you use the 32-bit version of office, you use the 32-bit version of the ODBC driver.
• Be sure that if you use the 64-bit version of Office, you use the 64-bit version of the ODBC driver.
• If you are using the One Click version of the Office 2016 install, you need to grab the 2013 verison of the Access Runtime. Why? I don’t have a good answer for you. All I know is that the 2016 version did not work while the 2013 did.

You can check what ODBC drivers you have installed already by going to the ODBC Data Source Administrator window in Windows. The first tab of “User DSN” should have listed the Excel Files if it’s installed properly.

Mine looks like this

You will need to reach out to your IT folks if you need a hand getting the right version installed and setup. Once that’s good to go, hop back in you Navisworks model.

There are two places you can establish this data connection. The first is right on the Home tab and its the DataTools button. This sets up a data connection for any thing you open in Navisworks. This is not the one we will use, but it could be hugely beneficial to you if you want to always have a connection setup.

We are going to use the DataTools tab found in the File Options window that is accessed by clicking File Options on the Project panel on the Home tab. This connection is for this Navisworks file only. The steps are identical to set up the data connection, so learning it here will work for the other one.

The File Options DataTools tab

Here are the basic steps to start to get our Excel data back into our model:

1. Click “New…” to set up a new DataTool Link.
2. Give it an appropriate Name
3. In the ODBC dropdown, find the correct Excel connection
4. Click “Setup…” and then “Select Workbook…” to track down the Excel file then click OK

That’s the first (and easy) part. Now we need some explanation. The SQL String window is where the bulk of the work happens and it’s also the hardest part. If you know SQL, this will be easy. If you don’t, I am going to show you the string I use and try to break it down to make sense.

SELECT * from [Hardware$] WHERE “GUID” = %prop(“Item”, “GUID”)

“SELECT * from [Hardware$]” means simply grab everything on the tab called “Hardware” in my database, which is the Excel file. You have to put the tab name in brackets and end with a $. That’s important. It’s not going to work if you miss that.

“WHERE “GUID”” is starting to match up our elements. The GUID here refers to the column in our Excel file. So you have to make sure that column name and this spelling match EXACTLY.

“= %prop(“Item”, “GUID”)” wraps things up. So we are matching the GUID from the spreadsheet with a property (%prop) of elements in the Navisworks model that lives on the “Item” tab and is called “GUID”).

I know I have GUID twice and that might be confusing, I just need to remember that the first one is from the Excel file and the second one is the item property. Remember, I can name that column in Excel anything I want, so I could name it “MyGUID” and my command would look like this:

SELECT * from [Hardware$] WHERE “MyGUID” = %prop(“Item”, “GUID”)

The final thing I need to do is set up what Fields I want to bring in. This is simply those new columns I created in my Excel file and what I want them called. There is no “new” button here, you just double-click on the blank area to make a new one. I need to make one for both the columns “Hardware” and “KeySet”, but for “KeySet” I will change the Display Name to “Key Set” so it’s a little more readable.

Once everything is setup, my Edit Link window will look like this:

One I click OK, I can then check the box next to my new DataTools Link and if everything is set up correctly, the data will just be aggregated into my model. So, I select a door and find that I now have a new Properties tab called “Hardware” with two new properties on it.

New tab – new data

That’s a lot of reading for today, so we will have a wrap-up epilogue post coming soon with some tips, pointers and links to other resources that can help you expand your knowledge on this.

Linking Excel Data Into Navisworks – Part 3 Editing Data in Excel

Back in Part 2 we were able to export data from the items in our Navisworks model, with the critical step of adding a key to each item, a unique identifier that we can use to round-trip that information back into Navisworks.

In this post we are going to open up the exported .CSV file, add some more data, and make some tweaks that will make our lives easier when we pull this back into Navisworks.

The first step is easy: track down the .CSV file I exported and open it up in Excel. Depending on how your Excel is installed, you can probably just double-click on it to open it up. Once it’s open a quick glance tells me that yes indeed, this is the data I selected to export. Everything is working as expected.

A closer glance usually adds a touch of confusion. See that first row? What essentially are the column headers? When I first open this file up, all I see are “Element”, “Item”, “Element”, “Item”, and “Item”. Not very useful to let me know what data is what. But, if I go in and stretch the height of that row, I can now see what’s going on: when the data was exported, Navisworks made the headers the Category and Property for easy reference, but it put a line break in between them, making them sitting on top of each other.

Top row looks weird

Top row looks much better

This is the first thing I like to clean up in my Excel file. The line break is not good for data integrity and it can make things confusing when I’m trying to get this data back into my Navisworks model. So I go through and rename the headers, simplifying the name and definitely getting rid of the line breaks. I usually get rid of spaces as well, this also makes the importing of the data simpler. The formatting won’t be read over, so I like to make that top row bold, just for a visual cue that it’s column headings.

New names, no spaces, no line breaks

This is where I start adding my new data. It does’t matter where I put this column, it does matter what I name it. All these columns need to be named something unique. I also follow the no spaces, no breaks naming convention I laid out before. Keeps things simpler later on down the road.

In our example, we are adding hardware information and keyset info to the doors. So I just add two columns, give them good names and then add my data. I can use any of the Excel functions I need to, I can sort by DoorNum if I want, all I need to make sure is that the top row stays at the top, and the data in the row itself stays intact.

New data added

I have had weird things happen with formatting and data types when I bring the new data back into Navisworks, so I will typically just set everything to Text, not General in Excel. That seems to make whatever I write in Excel show up just like it in Navisworks.

Now it’s all good, I do a Save As to save this file as a native Excel format file. You can reconnect with the original .CSV format, but I usually have done something (like making text bold) that the .CSV file doesn’t like, so it’s Excel for me.

And that’s pretty much it. This step is probably the easiest. I do like to emphasize cleaning up those column header names; that will make things a lot easier in the next step.

Speaking of which… now that we have our extra data added in the same row as our elements with the unique identifier, the next post will cover linking the Excel sheet back into Navisworks and getting the data to show up.

Linking Excel Data Into Navisworks – Part 2 Exporting Data

The first article in this series got us through the potentially confusing steps of selecting items in our Navisworks file based on Revit criteria. Now that we have our items selected (either from the Set we made or just because we have them selected) we are ready to move on to the next step; selecting the data to export and exporting it.

Confirming that you have the correct items selected in your Selection Tree, we need to now open up the Selection Inspector. You can right-click on a selected item in the Selection Tree and click “Selection Inspector…” or go to the Home tab and click the little button for it on the Select & Search panel.

There it is! Tiny little button…

Opening the Selection Inspector shows me a preview list of the data I am going to export. By default, Navisworks lists out the Item Name and the Item Type. That’s good information to have, but to be able to correctly export data and attach it to specific individual items, I need a piece of information that is unique to each element. And looking over this list it’s clear there is a lot of overlap in the data.

Nothing unique about each row

I have a couple options here to find something unique. I can get the Revit Element ID which is a unique number that Revit uses to keep track of these things, or I can use the unique number that Navisworks assigns to each element, the GUID (Globally Unique IDentifier). In this case, I am going to export both so you can see how they get added. I only need one ultimately to be able to match the updated data in my Excel with the original item in my Navisworks file.

Clicking the “Quick Properties Definition…” takes me to the Options page that lists out what properties the Selection Inspector refers to. The defaults are Item / Name and Item / Type. Remember that the Navisworks category is essentially the name of the property tab for the item, so if I need to double check the category and the property, I can just select one of the items I am going to export, and look at the tab name and the property name.

For the Navisworks GUID, that’s under Item, and the property is GUID. The Revit Element ID is on the Element tab and the property is ID. So in the dialog box, I click the green plus sign twice to add two more rows and then change the dropdowns as necessary. As soon as I do this I can see the Selection Inspector updating it’s preview to show me the new data.

Since I am working with doors in this example, I probably want the door number as well, to make it easier for me to reference the right door when I am adding the hardware and locking information. That is also Revit information, and it is stored in the Mark property. So I add another row and set the Category and Property to match those.

The new Quick Properties Definitions list

And then clicking OK commits those changes to the data listed in the table.

Selection inspector with unique identifiers

I can repeat the process and add more columns of data. What I need to remember, however, that once I export this data, I cannot change it in Excel and then re-import. This information “lives” in the appended model, not in the Navisworks file. This process can only be used to add more properties to my items, not change information in them. For that I need to go back to the original authoring tool, in this case Revit.

Now that everything looks good I click the Export button (in the upper right) and select Export CSV… and then save my .CSV file where I need it. I called mine “hardware.csv”. The name is not that critical but common sense rules should apply.

Export CSV

This is the file we will be adding our new data to in the next post. You need to keep in mind that once I exported the .CSV file, the information in that file is now completely detached from the data in my Navisworks model: it is a snapshot in time. SO any updates that are made to the data in the Navisworks model after this export will not be reflected in this .CSV file. I will need to generate another one whenever any changes are made to the appended files.

Stay tuned for Part 3! We will crack open the new .CSV file, add some data and talk about some good tweaks to make to what’s in there already.

Linking Excel Data Into Navisworks – Part 1 Selecting Elements

Let’s work with collecting some information from an appended Revit model in Navisworks. For my example, I need to add hardware and keying information to all of my doors. This data could be easily collected in Revit itself, but there are a lot of owners out there who don’t have or use Revit; there is no need to edit the model on that level, so we are leveraging Navisworks to add data to our models from a format that is easy to use, namely Excel.

A Navisworks model is a bit of a chameleon. Depending on what type of other file you append, Navisworks will restructure the data from that file into its format in the Selection Tree. For example, if you bring in a DWG the “Layer” tier in the tree refers to an actual DWG layer, but if you append a Revit model, the Layer in the Navisworks Selection Tree ties itself to a Revit level, and tries to collect everything associated with that level. Understanding that, you need to do a little research before you know at what tree layer you can find the data you are looking for.

In our Revit model door example, the tree structure makes sense, but I see that if I expand the items and select each one, the tree tier with the “Insert Group” icon has the Revit data I want to look for, not the item below that with the “Group” icon.

Not a lot of Revit info here…

Here’s my Revit info!

Finding the items at the right tree tier can be tricky as well. The Find Items function in Navisworks is extremely powerful, but you have to know what tier you are looking for and what data lives in that tier.

However Navisworks breaks the data down, essentially the tabs in the Properties are the first level of selection criteria in Find Items. Then you look for a property on that tab and evaluate the data. That’s how you find your results.

Since I know what selection tree tier I want, and I am looking for all my Revit doors, I notice that the “Element” tab in Properties has the Revit family and category. Bingo.

I build my selection criteria to look at the “Element” Category, looking for the “Category” Property and seeing if that is equal to “Doors”. It is definitely confusing that I am using the same word for two different things, but if you remember that the first one is the Navisworks category and the second is the Revit category, that will hopefully help. Hopefully.

Voila! Albeit, a little confusing…

So once I click “Find All”, Navisworks selects all the items at the “Instanced Group” level, which is the level I want because that level has all the Revit data.

Correct items selected in Selection Tree

Now that I have the right items, I need to create a Set. Navisworks gives me the option to make a Selection Set or a Search Set. The Selection Set is a snapshot of all the items I have currently selected, and a Search Set saves the criteria I used to find those items. I usually do Search Set, because it allows me to refresh my items if any of my appended models change.

Full disclosure – you do NOT need to create a Set for the export and import process. It’s good practice to save one however, in case you need to repeat the export/import process, or if you have fat fingers like I do and you accidentally click and unselect everything you had selected.

Saving either type of Set is really easy, you just open the Sets tab and either click the button for Save Selection or Save Search. Autodesk has a good write-up of what you can do with your sets.

So now you have the elements that you want to export to Excel selected, our next write-up is going to walk us through picking what properties get exported and the export itself.

Linking Excel Data Into Navisworks – Intro

We all know Navisworks mainly as an amazing aggregator of various model formats, but you can also link in data straight to items within the Navisworks file. This might feel like you are editing the data, but you aren’t. It is still simply collecting that data and aligning it, some of that data just happens to be in the form of an Excel file or SQL database.

This is typically handled in some kind of round-trip: you export information from the Navisworks model, you edit or tweak it in Excel or compile into a database, then you link it back in. The reason for this is if you want to connect data to specific elements, you need a key or unique ID for both pieces of software to be able to see and often that key is only in that element. So, you can export data about those elements, including that key, so the external program knows what to match things up with.

We are going to spend a couple posts and focus on exporting some data from a Revit model (in Navisworks) to Excel, making some edits, and then linking it back in. All of this is to enhance the data in your Navisworks model, and any of these steps can be taken as a single activity or part of an overall workflow.

Part 1 will be about collecting the data in Navisworks.

Part 2 will dive into the exporting the information to a format that Excel likes.

Part 3 opens up the Excel file and adds some data and does some tweaks to make it easier for us later on.

Part 4 will cover linking that data back in so we can see it in our Navisworks model.

Part 5 is a wrap-up with some tips and extra resources.

Check back in a few days for Part 1!