This recent post on Dynamo Nodes shows how a simple Navisworks Search Set can be built by Dynamo running inside of Revit:
Create Navisworks Search Set XML for Element Ids | Dynamo Nodes

In the first release, this node just uses Element Ids to build a long ‘orsearch set, but this basic idea could easily be extended and adapted to more closely connect Revit to Navisworks search workflows through Dynamo.

Here is a Screencast:

As you are probably aware, when moving from Dynamo 0.9 to 0.9.1 you lose backward compatibility… in other words, you can’t open 0.9.1 files in 0.9 or earlier.


Before taking that step up to 0.9.1 and beyond, you may wish to apply a filename suffix to all of your DYN files, so you are reminded of this issue when you open a DYN. I have a single folder with subfolders containing most of my DYN files, and I added the suffix (082) to all of them at once with this method:

Install Advanced Renamer.

Add the Directory that holds all your dyn files:


Then add a suffix to the filename:

Now, you basically have an inplace backup of files. When you open one of these dyns in 0.9.1 or newer, just remember that you should Save As in Dynamo, and then newly saved file will not be open-able in 0.9 or earlier.

At some point in the future you can then remove or upgrade all of these ‘older’ Dynamo files.

Brian Nickel recently sent through a link to the very Elk package for Dynamo, that essentially opens up web geographical data access to Dynamo and thus through to Revit for topography creation and similar.

It was already an established plugin for Grasshopper, but developer Timothy Logan has released a port for Dynamo which can be accessed through the Package Manager.


Elk HKS site:
Elk Mapping Plugin | HKS LINE

Heads-up from:
The Revit Saver: Dynamo – Elk for DynamoBIM by Timothy Logan

Quote from The Revit Saver:
Thank you to Timothy Logan for making Elk available to Dynamo users!

Here are his two videos for how to use the OSM data and Topographical data.

Elk for Dynamo – OSM from Timothy Logan on Vimeo.

Elk for Dynamo – OSM from Timothy Logan on Vimeo.

Some of the links referenced in the above videos:

I had this idea over the holidays… and while it is still in its infancy, I have already received some good feedback along the lines of “this is what people have been looking for…”

I have invited all of the top Dynamo Package developers to be Administrators on DynamoWorks, and as a team I hope we will be able to build up some good, useful, practical content on how to use specific custom nodes in real-world applications.

If you would like to be a co-author, feel free to contact me here or on Twitter, @lukeyjohnson.

Check the site out at:


subtitle: Most Revit hacks ever in one blog post??
Have you ever faced flex duct modelling problems in Revit? Revit fails to generate these in some cases, usually when the spline becomes too tight for the geometry engine to handle.

With a view to finding and correcting this, I built an audit tool that basically goes through these steps:
  • Collects a list of flex ducts in the current model
  • Checks their 3D geometry against what it should be (using a Volume calculation)
  • Reports a list of problem element ids
  • Overrides these elements to red in the current view
  • Isolate the elements in the Current View

It looks something like this:

Having established a list of geometry failure objects, what can we do to fix them? Well, essentially they are failing because the spline curve is too tight for the relevant duct or pipe diameter, so we need to rationalize or ‘smooth’ these curves out until we get to a point that the geometry works again.

So first of all, we need to get the driving points from the Revit MEP element, so that we can start playing with curves. At the same time, we should get start and end tangents, and Diameter too. I created this node in Python for this task:

You can see that I have added conversion input here, because the units coming out of the API were a little weird (back to the old feet units thing). Ok, now that we have points, we have to regenerate the driving curve and then play around with it a bit… it looks a bit like this:

You will notice I try both Nurbs and Polycurves, because sometimes either will fail. Using both seems to be pretty reliable.

Then, with some nice Nurbs curves in hand, we have to try and make some circular-ish sweeps along them. I actually sampled a number of circle profiles by 3 points, and used nurbs surface UV degree of 3, as this seemed to be the most ‘reliable’ form creation for strange paths. However, even this still failed occasionally, so I created some ‘backup’ forms (using only start and end circle profiles), and then I rolled them all together into one (hopefully) reliable ‘no nulls’ list:

Now we can basically take a set of Flex Duct elements (where Revit is failing to generate the right geometry), and smooth out and generate our own Flex Duct ‘form’ in Dynamo. From there, we have a few options to get it back into Revit:

  • ye olde but pretty reliable ImportInstance.ByGeometry or .ByGeometries
  • Dynamo 0.9 users can go with DirectShape
  • you could try beta Spring Nodes FamilyInstance.ByGeometry (thanks to Dimitar Venkov)
  • we can also use Mesh Toolkit to convert to Mesh, make Watertight, and export to file..

I wanted the most ‘Revit’ solution, because after all, this blog is about What Revit Wants! So for me, that was trying to get these forms into a family on the right category. First problem: there is no Flex Duct Family Template available, because that just isn’t allowed… so I had to make one using the IFC roundtrip (with custom IFC mapping files), then saving inplace to a component family, and renaming to RFT.

Now, with the Geometries in one hand, the Flex Duct Family Template in the other, and a wrapper node to run FamilyInstance.ByGeometry once per geometry, let’s see what happens!

Well, initial results from running the node weren’t great, but I noticed that the families were getting generated in the 3D View in Revit, and then disappearing… so I went to Revit and pressed ‘Undo’ and  all my nice new Flex Duct Families re-appeared!


Want to give it a try yourself? Here’s how to use the dyn:

  1. Go to a 3D view and select some Flex Ducts
  2. Open Dynamo, and the definition from link below, and press Run. Confirm there are no ‘failures‘…
  3. This should collect list of Geometry
  4. Connect the two orange boxes, 1) and 2)
  5. Press Run again
  6. This should have made families for you, using a random number as the family name
  7. Press Undo in Revit to make the families ‘reappear’
  8. Close Dynamo and save your project
  9. You may need to open individual families and set the Subcategory to something new so that you can override colours and materials in the Project.

Here’s one instance in the project:

This is the main definition:

This is the project browser list of families:

Needless to say, this workflow comes with as many disclaimers as possible, because we are:

  • using Dynamo before v1 (0.8.2 in my case)
  • using hacked family templates to
  • make component families on categories they shouldn’t exist on with
  • a beta custom node and then
  • working around some weird issues by pressing Undo after running Dynamo
  • etc 🙂

You will need Bakery package (version from around 9 December 2015, and its dependencies) to get all this working. Here are some other required resources for download:
Flex Duct family template and main Dynamo definition

Exporting these families using Navisworks exporter seemed to work ok, as shown here:

Other Prototype Imagery:

I saw a question like this on the forum so I had a quick go at it (see image below). Basically it checks what Family Types are placed against those loaded into the project, and then deletes unplaced component Families using SteamNodes Tool.Eraser:

Post flight family list:

Future versions of this could start looking at system families / types using similar methodology.

Every now and then, you may find that a package upgrade causes some of your nodes to stop working. This may be because nodes have been removed from the package that you were using. You can use the two DYNs here to quickly check for missing dependencies:

Step 1
This will find dependencies from a selected package or definitions folder and export them to Excel:

Step 2
This will read the Excel file back in, and compare with node names in your Packages folder (may take a while):

Both of these dyns can be run in standalone / sandbox mode.

If there are missing nodes, they should appear in the pink box. You could then go to DynamoPackages website, download previous version that had the dyf you want, and then copy the contents of that dyf into your own custom node.

XML files are everywhere. And in the BIM world, we have to deal with a range of different xml file schemas, such as BCF, Navisworks Clash Reports and Viewpoints, and so forth. Hiding inside these XMLs there is some very useful information. For example, BCF files often have Element IDs in the viewpoint.bcfv component, and Navisworks XML files often have point XYZ values. Can we easily get access to this information for use in Dynamo, and then in Revit?

Yes, we can! There were one or two ways to do this in Dynamo before, but here is my take on it…

Dynamo ships with IronPython, which in turn ships with an XML handler called ElementTree. I have created some basic nodes that give us access to ElementTree functions in Dynamo. Along the way, I learnt a bit about encoding and character sets. It turns out that Navisworks often inserts tricky characters into the XML (like the diameter symbol), so as a workaround (for now) I do a string encoding roundtrip to get rid of these problematic characters. In the same node, I create the ElementTree object: this is a special object that essentially represents structured information about the XML data. The initial import looks like this:

Once we have this ElementTree object in hand, we can start to do some interesting things, like:
Iterate through tree to get individual XML elements


and Show a hierarchical representation:

With the individual elements, we can Get Attribute names and values, and the Get the children of those elements:

Obviously, you can immediately do some nice lookups against these lists in Dynamo, depending what information you want. However, on large XMLs this can be quite slow. Happily, ElementTree provides some basic XPATH support, which looks a bit like this:

With the XPATH support and an understanding of the xml hierarchy, I have created a node to do XPATH calls straight to the ElementTree object:

Now that we can ‘snip’ out useful information from the XML, we can do interesting things with it, like make some points:

When it comes to BCF, its a little bit more challenging. I haven’t figured out how to unpack the bcfzip directly to memory (yet), so we have do that manual step first. Once we have a ‘folder’ from the BCFZIP, we can get the bcfv files from inside it and then get information from them, like this:

So, in the latest Bakery package are the nodes needed to read a variety of XML files, get information from them, and do some useful things with that information. It was a learning experience for me, and I hope its useful to you 🙂