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.
Okay, so we’re on a roll with practical Dynamo usage. Last week we looked at placing views centrally on our sheets, but what if you didn’t want the view centrally placed? What if you wanted views placed in the same location on all sheets maybe in the top left of the page?
As always with Dyanmo, there is a solution for that. Again we’re going to be using the Rhythm custom node package to get the work done. This method requires one sheet to be used as a template that all the following sheets are based on.
In our example this time around, where we want the view located is in the top left (shown on the left) but by default Dynamo places our views in the bottom left (shown on the right)
This workflow can be easily integrated into our previous graph where we created new sheets in Dynamo using Excel however for this example we’re going to create a standalone graph. For this example though, it’s assumed that this time around though that you already have all the sheets and views required created.
First we start by taking all of our sheets, we do this simply by using Categoriesand then All Elements of Category, after that we get into our Rhythm nodes.
First we get a list of all of the viewports on our sheets using the Sheet.GetViewportsAndViews node. Run the list through a List.Clean node to remove the empty list entries. This leaves us with just the viewport entries.
Meanwhile, we also need to get the viewport from our template sheet. In this instance our template sheet will be drawing H101 which we’ll select using the Sheets node and then we’ll feed that node into the Sheet.GetViewportsAndViews node which are both from the Rhythm package.
And finally we feed our data lists into the Viewport.SetLocationBasedOnOther node, which again is from Rhythm. It’s as simple as that.
For those of you that read through my previous post last week on creating sheets using Dynamo, you might have come to the end of the post only to realise that the views haven’t placed where you want them to be on the sheets.
For example, my sheet with the automatically placed view now looks like this
The first method I’m going to use nodes from both the Rhythm and Lunchbox packages which you can download from your package manager. Simply install the latest version.
The Rhythm package has some super useful tools for a whole range of different actions in Revit, but today we’re going to focus on the nodes that can help us manipulate the location of our views on the sheet.
To get started, we use the Sheet.GetViewportsAndViews node, we want to feed the sheets from our previous steps into this node and the node will give you the viewports, views and schedules as separate outputs. For this exercise, we’re only interested in the viewports. As always, while you’re reading through just click on the images to see them full size.
Next you need to use the Viewport.LocationData node from Rhythm. The outputs from this node are
bBox which returns the minimum (bottom left) and maximum points (top right) of the viewport bounding box. boxCenter which returns the centre point of the viewport bounding box boxOutline which returns the start and end points of each side of the viewport bounding box
For this example, we’re going to use the boxCenter option because we’re going to get tricky with it a bit later on. For those earlier that were wondering what the Use Levels option actually on the nodes, as you can see in my animation it changes the level of the list that we’re working with. Without the Use Levels option you would need to either use GetItemAtIndex or List.Deconstruct to get the data that you want to manipulate.
Next use the Points.DeconstructPoint node from the Lunchbox package, this will deconstruct your point into it’s individual X, Y & Z coordinates.
Now this is where we get too smart for our own good. I want my view to be placed in the middle of the available space on my titleblock. For my particular titleblock I know that the centre point is located at 378, 297 (yours may be different) and we already have the centre of the viewport from our Rhythm node.
To find how far we need to move the viewport, we need to subtract the view X centre value from the sheet X centre and the view Y centre value from the sheet Y centre. The code block is simply values I’ve chosen, you could think of them much like a parameter in a family.
The next step is to move the views. The vector gives the distance in X & Y coordinates that the view needs to be moved, the Vector.ByCoordinates and Element.MoveByVector nodes are both standard nodes within Dynamo.
And finally, the whole thing is tied together by pushing the viewport elements into the Element.MoveByVector node via a List.GetItemAtIndex, from which we’re taking the list elements at index 2.
Now sometimes when I run this script, I’ll see the following “Attempt to modify the model out side of transaction” error.
There is a simple solution to this. Just save your changes in Dynamo, close Dynamo and then re-open. Simply run the script again and everything will work!
An overview of our extension to the original graph from last week, I’ve highlighted the nodes from custom packages to make things a little easier as well, Captain BIMCAD actually called me out on last week’s example for not grouping my nodes!
I was discussing Dynamo workflows with good old Captain BIMCAD the other night and we got to the topic of project setup.
Personally I don’t use Dynamo in my everyday project setup workflow, I use Ideate BIMLink, Omnia Scope Box Synchroniser and Sheet Duplicator but if you don’t have access to this software; especially BIMLink as it’s a bit pricey, Dynamo is definitely a viable option. Here’s how to get it done.
First we need to create a list of sheets in Excel with Name and Number information. Starting with a blank workbook in Excel, create a list with sheet numbers in column A and sheet names in column B.
From here we need to generate new sheets with this Excel data. Don’t forget the File.FromPath node, you can not feed the File Path node directly into the Excel.ReadFromFile node. Note that the name of the sheet in the Excel workbook is case sensitive. You can click on the image to view in full size
The next step is to remove the headers from our Excel file. They’re useful to us as it makes the Excel file more readable, however they need to be removed when used in Dynamo.
To achieve this we’re doing to use 2 nodes, List.FirstItem and List.RestOfItems.
Next we need to transpose our list so that we can feed in our sheet details into the sheet creation node. You can see once we run the list through the List.Transpose node that we now have a list of sheet numbers and a list of sheet names which sets us up for our next step.
Most of the magic happens at the next node which is the Sheet.ByNameNumberTitleBlockAndView node.
For the node to work, we need to input the sheet name, sheet number, the titleblock family which you can see how we achieve this in the next screenshot.
While you’ve been reading, I’ve taken it upon myself to generate some views in our model and add them to our original Excel file.
We can copy what we’ve already created in Dynamo for the sheet names and numbers and we simply take index 2 from the list, giving us the view names. Note that these will be case sensitive.
The next step is to actually find those views in the model to drop onto the sheets. We do this by creating a list of all the views within the model. Take the Categories node and select Views from the drop down, feed this into the All Elements of Category node and then finally feed this into an Element.GetParameterValueByName node. For the parameter name, we want to get the value for the View Name parameter.
From here we need to search the list of view names in Excel with the list of view names in the model. To do this, use an IndexOf node.
When you run this though, you’ll end up with a result of -1 instead of a list of indices. To fix this, change the level of list in the node. To do this, click on the right arrow on the element input of the node, select Use Levels and select @L1. Run the graph again and you’ll see the list of indices.
But what happens if you have a model where you don’t have the views setup yet? In our example we don’t have a view for the cover sheet or site plan yet which is why the view name is represented as null. You can see that the null view names give a -1 index result. If we feed this data into the Sheet.ByNameNumberTitleBlockAndView node as it is, it won’t create the sheets with the null views.
You can still use the same node, but there is a trick to it.
First, grab the Manage.ReplaceNulls node. Feed the list for views into the data section.
Next, create an empty drafting view, I’m just going to leave mine as the default Drafting 1. Feed the ReplaceWith input of the Manage.RemoveNulls node with the string Drafting 1.
Now when we search our views in the model, we’ll have the correct indices returned.
But hold on there a minute! We can’t drop drafting views on multiple sheets, how is this even going to work? To be honest, I’m not quite sure why but if you feed an empty drafting view into the Sheet.ByNameNumberTitleBlockAndView node it will generate an empty sheet. Whatever the reason, that’s a win for us!
Simply feed Manage.ReplaceNulls into the Sheet.ByNameNumberTitleBlockAndView node and we’re done!
If you’ve had automatic run selected, you’ll have a nice set of shiny new sheets created, otherwise simply click run and watch the magic happen.
Blink and you’ll miss it!
The end result. Click the image for the full resolution version.
Last week I wrote about using note block schedules to create specification sheets and I explained how you can use addins such as BIMLink, custom macros or C# addins or Dynamo to get the data out to Excel so that it can be edited by an engineer and then re-imported to Revit from Excel.
Problem is, you don’t have a BIMLink licence, you don’t know how to code in C#, the most accessible method for you to achieve this workflow is Dynamo but you don’t even know where to start; never fear! In this post I explain how to create a bi-directional link between Revit and Excel using Dynamo using the as the note blocks from my previous post as an example.
The export to Excel process is pretty simple, you just need to think about the logical steps that you need to take. You want to select the family you wish to export data from, select the parameters to export, organise them in a list and then write it to the Excel file itself.
To step through the process, first select the family type and push that into an All Elements of Family Type node.
From there we start our first step in taking care of the family unique identifier by using the Element.UniqueId node, this will export the family’s GUID. Simply link the All Elements of Family Type node to this one. You need to export each individual family’s unique identifier as well, if you don’t, as the BIM Troublemaker discovered you may end up importing the wrong data to the wrong family.
Next, you need to select each of the parameters you want to export, for this you need to use the Element.GetParameterValueByName node. Link the All Elements of Family Type node through to this node and you will also need to add a String node which is where you input the name of the parameter. Because I’m using the annotation family from my note block post, the parameters that I will be exporting are NUMBER, NOTE, CATEGORY and REGION. Note that the value that you enter into the string is case sensitive and that you need to repeat this for each parameter you are wanting to export.
Now you need to push the output of each of our Element.GetParameterValueByName nodes through to the List.Create node. This will actually create a list that will run the parameters across the page with each parameter being spread across a row instead of being arranged in columns. If you exported the data to Excel at this point, you would end up with something that looks like this:
However this isn’t how we want to work, we like our data arranged in columns. To do this, use the List.Transpose node which swaps the rows and columns in the created list.
To finish off we need to use the Excel.WriteToFile node in which we pass through a File Path node, a String which names the Excel sheet and a few Numbers which gives the starting row and column of our excel sheet.
The result is a nice, easy to read export of all the data relevant to our note block schedules ready to be modified by an engineer.
At this point you can use the Sort function in Excel to sort your Excel file into a usable list. In this instance I have chosen to sort by Column D and then Column B so that I am sorting first by category and then by note number.
Importing back into Revit from Excel
Once the engineer has finished modifying the Excel sheet, we’re ready to bring the data back into Revit from Excel. This process is slightly more cumbersome but overall not a whole lot more difficult than the export process.
First we need to pick up our Excel file, start with the File Path node that we used before, before we go to the Excel.ReadFromFile node though we need to pass the file path through the File.FromPath node otherwise it will not work. We also need to add a String so we can tell Dynamo which sheet to read. Next, pass the data back through the List.Transpose node to get the data back into a format that Dynamo and Revit are happy to work with.
Remember earlier I mentioned during the export process that to make sure we’re writing the correct information to the correct family we need to index our list and the families by their GUID? Thanks to the BIM Troublemaker, we know how to select each element from our Excel file based on the GUID. First, start with a List.GetItemAtIndex node and connect the List.Transpose node to it. Next, add a Code Block node and enter the text 0; this passes through the number 0 as our row index. Finally, add a Code Block node and insert the code ElementSelector.ByUniqueId(id, true); this is case sensitive, so make sure that you enter it correctly or it will not work!
Finally, we need to push the data through to each parameter for each individual family. To do this, use an Element.SetParameterByName node. We need to feed the ElementSelector Code Block that we created into our node, along with a String node that matches our parameter name, remember this value is case sensitive and finally we need to link up our value via a List.GetItemAtIndex node.
The List.GetItemAtIndex node needs to be told which row to use to pull it’s data from, this is as simple as adding a Number node. Don’t forget though that the first row is at index 0, which is where we are pulling our GUID from, so we want to pull our first series of parameters from the row which is at index 1.
In this instance our index 1 is our number list which you may not need to import this so you could skip this step, but if you do need to populate the number data and you try to feed the parameter from the List.GetItemAtIndex node directly to the Element.SetParameterByName node Revit will throw back an error stating that “The parameter storage type is not a number”. Originally I tried to overcome this by using the node String from Object but this gives a number to 3 decimal places and we don’t want to see this on our specification sheet. The solution in this instance was to first use the Math.RoundDownToPrecision node from the Clockwork package which you can download from within Dynamo itself or from dynamopackages.com. We need to pass a number to the Math.RoundDownToPrecision node to indicate the precision we want, which in this case we want a precision of 1.
The number conversion is the only oddball of the parameters that we’re working with, the rest of the parameters simlpy feed the List.GetItemAtIndex node directly to the Element.SetParameterByName node. Repeat for each parameter that you want to populate.
Part #3 – Understanding Clash Types and Tolerances
One of the most misunderstood parts of Navisworks clash detection is the settings for the clash type and the tolerances. Using the model from my hydraulic pipe sizing article I have put together an example of the different clash detection types at varying tolerances. I’ve added some columns to the model which are progressively offset at 25mm intervals. You can clearly see that there are columns that clash, and columns that do not clash with the drainage pipework.
I’ve then created two selection sets as explained in the 2nd part of my clash detection series, one for columns and one for the drainage pipework. I have then created a series of clash detection rules that clash the columns selection set against the sanitary drainage selection set, the clash reports repeat at different intervals.
For the hard and hard conservative clash reports, I have selected tolerances of 10, 20 and 50mm and for the clearance clash report, I have selected tolerances of 20, 50 and 100mm. When running the clash reports, I get the following results:
As you can see, as you increase the hard clash tolerance, the clashes reduce and as you increase the clearance tolerance, the clashes increase.
Hard clashes are as the name implies – a hard clash but as you adjust the tolerance, the clash is ignored within that tolerance range. Allowing for a 50mm hard tolerance means that two items need to intersect or clash by 51mm or more before they are reported on. The clash shown below has been reported in our 10 and 20mm tolerance reports, but completely ignored in our 50mm report.
There is no denying that this is a clash, yet it’s not reported in the 50mm tolerance test at all.
Clearance clashes are the exact opposite of a hard clash. Clearance clash reports check elements for minimum clearance requirements. In a clearance clash test with a 50mm tolerance, two elements will need to be 50mm apart or closer to be reported as a clash. This is particularly useful when you want to allow additional clearance for pipe, cabletray or duct hangers and brackets that have not been modelled.
As you can see in the reported clash below, the two elements do not intersect at all, yet they are still reported as a clash due to the minimum clearance not being met.
But What if my Elements are smaller than my tolerance?
That’s actually an interesting question and can prove useful or troublesome in clash detection reports. I’ve added a 20mm gas pipe to my example model which in plan intersects with my 15mm cold water droppers that run to each basin. Again, you can clearly see that the newly added gas pipework clashes with the existing cold water pipework.
I’ve in turn created a series of clash tests, this time I have only created hard clash tests with tolerances of 0, 10, 20 and 50mm.
The reports give interesting results. Only the report with a 0mm tolerance has reported any clashes at all. Results like these have the chance to run you into trouble if the clashes can not be resolved on site – say for example a 65mm vent pipe rising inside a 90mm stud wall and a 32mm chilled water pipe running horizontally in the wall cavity; there is no way the two services will ever fit and yet they’re not reported in Navisworks.
These settings though can also be used to your advantage. For example if you have modelled all the hot and cold water pipework to the individual fixtures, you would never be expected to coordinate pipework of that size and how can you when the architect doesn’t model the studs within the walls? Using the tolerances to your advantage you can avoid having essentially false positive clashes reported.
Sets are a big part of clash detection in Navisworks, they can make the difference between a great clash report and one that is a waste of time. Simply clashing one model against another is not going to give you great results in most instances. Say for example you clash an architectural model against an electrical model, that’s all you need to do right? Wrong. Every electrical item that is recessed into either the wall or ceiling will be reported as a clash which this actually isn’t a clash, you end up with a time consuming administration overhead to manually approve clashes that shouldn’t have been reported on in the first place. This post will help you get your head around sets and how to make them work for you.
Selection sets are a group of objects selected either from the view window or from the selection tree window. You can manage sets from the sets window, if your sets window isn’t visible on screen, head to the View tab, and from the Windows button, select Set from the list.
The Sets window allows you to manage your search and selection sets within Navisworks.
Below is a description of each of the buttons in the Sets window.
Save Selection is used to save the current selection.
Save Search is used to save the current search.
New Folder allows you to create a new folder to group sets under.
Duplicate is used to create a copy of the saved items.
The Add Commentis used to add comments to the saved sets.
Delete is used to delet the selected set.
The Sort button is used to arrange the saved sets in alphabetical order.
The Import/Export button is used to import and export the saved sets.
When you run a search in the find items window, the search results will be highlighted in blue in the view window, as well as in the selection tree window.
When you select an object or a group of objects, they will be displayed in the Selection Inspector window along with their properties.
The Show Item button is used to view the selected object in the display window. The display will zoom in on the selected items when you click this button.
The Deselect button is used to remove objects from the selection inspector window.
The Export button will export the selected item to a *.CSV file.
Save Selection allows you to save the selected objects as a selection set.
Quick Properties Definitions allows you to add properties to the selected objects in the view window.
Now that I have explained the functions of each of the window elements, I’ll show you how to put them to use.
Using the Find Items window, you can search for elements based on specific information. In this instance, I have searched for all air terminals located on level 1. The find items window will allow you to search for elements based on the element properties which includes user parameters.
Once I have the correct elements selected based on my search, I can create a selection set in the Selection Inspector.
I now have a selection set named Level 3 – Air Terminals in my Navisworks model.
Following the same method, I have created a selection set of all the lights on level 3. In the next installment, I’ll explain tolerances and how they affect your clash results.
To the average engineer or modeller, Navisworks and clash detection go hand in hand, some people think that they are one and the same. If you’re not familiar with the terminology, clash detection is a process that identifies interference between elements in your model where as Navisworks is an Autodesk product that facilitates automated detection of the interferences between modelled elements. These interferences, or clashes may be between different models or within the same model, they could be between disciplines or within the same discipline.
The concept behind clash detection during the design process is that you can identify and fix problems before construction begins, therefore saving time and money down the track. Provided that it is configured correctly, Navisworks can help to speed up the process and reduce human error during model inspection by running automated clash reports.
The problem with Navisworks however is not everyone knows how to use it effectively. Maybe you’ve been to training with a reseller in the past and you walked out the door still scratching your head. After spending a whole day working on 4D timelining, 3 hours showing you how to animate an automatic door in Simulate and less than an hour spent learning the very basics of clash detection in Manage or maybe you’ve had no training at all? Either way you’re only just barely making your way through your clash detection sessions.
Over my next few articles I will outline a few of the clash detection basics to get you more confident in your adventures into clash detection, I’m not going to claim to solve all your clash detection woes, but whatever your experience, it’s always good to have something to refer back to.
In this first installment, I’ll explain each of the parts of the Clash Detective interface.
The Clash Detective window allows you to specify rules and options for undertaking clash tests. In this window you can view results and generate clash reports.
The Test Panel is where you will find all of your clash tests. The test panel isn’t displayed by default, you need to click on the Add Test button in the clash detective. When you select the Add Test button, a new clash test will be created and added to the test panel.
Under the Rules tab, you can define rules in which Navisworks will use to ignore clashes, by default there are four pre-defined rules shown under the rules tab.
In the lower half of the clash detective window we have a section with a few tabs, the Select tab is the default view in the clash detective window. In this tab you can define the clash test by selecting multiple sets of items at a time. You could clash a whole model against a whole model, however this would be a very inefficient process, instead you can test clashes between different selection sets of elements in the model.
The Selection A and Selection B areas display all the items in a hierarchical list that replicates the selection tree window. You can select objects from these areas that will be tested against each other during a clash test.
Beneath the selection windows are a group of buttons which allow you to change what geometry is clashed in the test.
When Surfaces is selected, surface geometry is included in the clash test. Surfaces is selected by default when you create a new clash test.
When Lines is selected, line geometry is included in the clash test.
WhenPoints is selected, point geometry is included in the clash test
Self Intersect is used to test the selected object against itself for clashes
The Use Current Selection button is used to select objects directly in the scene view for clash tests
The Select in Scene button is used to highlight the elements selected in the clash test. They will appear in blue when selected.
The Results tab is where you view the clash results. This tab is divided into three parts, the Results pane, Display Settings panel and the Items panel. By default the Display Settings and Items panels are hidden. They can be accessed by clicking on the panel title which is highlighted in the image.
The Results area displays a list of clash results in a tabbed format showing the name of the clash, the clash status, the date found and the description of the clash. If the clashes have a saved viewpoint, then the viewpoint icon will be displayed in the viewpoint column as well.
After expanding the Display Settings panel, you are provided with options to change which clash is highlighted, choose not to highlight the clashes at all, dim the other elements within the model so you only see those that are related to the particular clash as well as adjust basic viewpoint and simulation settings.
Hidden at the bottom of the results tab is the Items panel. Once expanded you can view information on the clashing objects. The clash information displayed will depend on the select clash configuration.
Finally, in the Report tab you can adjust options for generating clash reports. The generated report will contain the details of all the clash results for the selected test. The report tab has three sections; Contents, Include Clashes and Output Settings.
In the Contents section, you can select the contents of the report, such as the date found, item numbers, grid locations, coordinates of the clash among others.
The Include Clashes section allows you to filter by new, active, reviewed, approved or resolved clashes.
The Output Settings section allows you to select the output format of your clash reports. It allows you to select either the reports from the current clash test or from all clash tests either as a combined or separated format. You can also choose from HTML, XML or recorded viewpoints as your clash report format.
In the next installment, I’ll build on what I’ve shown today and explain how to create selection sets to get better results from your clash tests.