schedule

Taking a Return Trip From Revit to Excel Using Dynamo

June 16, 2015Ryan LenihanRevit Families, Revit Generalannotation, clockwork, dynamo, excel, guide, mep, notes, revit, revit schedule, schedule, specification, training

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.

I’ll be using Dynamo 0.80 which can be found on the Dynamo BIM download page.

Exporting from Revit to Excel

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.

And to finish up, our results:

Using Note Blocks for Project Specifications

June 10, 2015Ryan LenihanRevit Families, Revit Generalannotation, mep, revit, revit families, revit mep, revit schedule, schedule

Quite a while ago I was looking for a solution for specification drawings, they crop up from time to time on small jobs when a separate specification document isn’t required.

The problem with these specification drawings though is that the content of the text usually started life in AutoCAD, then it’s imported and roughly tidied up in Revit, it’s usually copied and pasted from one job to the next and you end up with text that is cumbersome to modify and information irrelevant to the current project.

The answer to the problem is note blocks, in my opinion a brilliantly clean solution. The annotations can be placed neatly on a drafting view, the content of the annotations is then scheduled and you end up with a series of schedules that are easily arranged on your specification sheets. Modifying can be as simple as the modeler editing the text within the annotations or the content can be exported using BIMLink, Dynamo, custom C# macros or addins ready to be modified by the engineer and re-imported to Revit.

I was working at another company when I put together a demonstration project, did a short presentation on how it works and was flat out told “No. This solution is too difficult for the average user.” And that was the end of that. We continued trundling on with cumbersome, incorrect and generally backward methods of creating and maintaining specification drawings.

I briefly mentioned this method for specification sheets in a Reddit post and I was asked how this works, so with that glimmer of hope that someone might find it useful, this is how you go about it.

First, start with a generic annotation. This is simply for display on your drafting view and of course to hold the data in for your schedules. Mine simply looks like this

Each of these labels are a simple instance family parameter.

The parameters I used were

Number – Used to order the notes
Note – The note itself
Category – This is used for each heading in the specification sheet. For example in hydraulics this could be Stormwater, Hot & Cold Water, Drainage etc. or for electrical it could be Lighting, Power, Lightning Protection etc.
Blank Spacer Left and Right – These are to give a cleaner look to the note blocks on the sheet, they’re personal preference only.
Region – I had to deal with region specific notes both within Australia and also internationally.

Once you have the family loaded into a project, create a drafting view to arrange your annotation symbols. Mine looked like so

I manually typed in the headers that you can see just for my own reference, the headers aren’t required though as all the required information for scheduling is contained within the families themselves.

The next step is to create the schedule itself. If you’re not aware, the note blocks can be found under the schedule drop down on the ribbon.

You will then be prompted to select the annotation that you want to schedule.

From there, select all the parameters associated with the annotation that you need for your schedule.

Filter out the annotations you need for this particular block of notes, in this instance I am working with hydraulics acoustic notes for Queensland.

Sort by the number, formatting and appearance is obviously up to you and your documentation standards.

Rinse and repeat for your remaining categories. My project ended up looking like so

It takes a little bit of time to setup, but once you’re done future modification is simple and if you don’t need to modify the notes, even better! If you’re worried about template clutter, the schedules don’t need to live in your base template either, they can be located in a separate *.RVT file where all the standard notes and schedules are kept and can then be imported to the project as required.

The result is a clean, easy to organise specification sheet. If you don’t want a particular section, it’s quick to remove and re-align the remaining parts. If you don’t want a certain note to show up, you can filter it out by changing the number to xx or delete it from your drafting view. Engineers can confidently take responsibility for what is on their drawings without worrying about typos, misreading of hand markups or information hanging over from previous projects.

And finally, you can see here how the blank left and right parameters affect the schedule. As mentioned previously these are entirely optional, I just liked the resulting layout of the notes.

To get you started, you can download my example annotation family here

Making Revit Work For You Using Advanced Families.

June 1, 2012Ryan LenihanRevit Families, Revit MEPas3500, box gutter, families, family, hydraulics, kg martin, plumbing, revit, revit schedule, roof drainage, schedule, shared parameters, stormwater design

Lately I have found that a lot of the buzz about Revit is 3rd party add-ins and software. Sure they’re great and save a lot of time in our workflow, but what about making Revit itself do some work for you?

Earlier this week I created a box gutter sump family that replaces an Excel spreadsheet that I used to use.

You simply input the data you would normally enter into a roof drainage calculation sheet into the Revit family, I also added a few more inputs to allow further control over the family. The inputs are

Catchment area
Rainfall intensity
Minimum box gutter depth
Minimum sump depth
Maximum sump depth

From there, all the calculations are built into shared parameters. I decided to use the KG Martin method for sizing (from the CSIRO Experimental Building Notes 1978). Hydraulic designers sizing roof drainage know all too well about h, 2h, Dg and Dmax which were easy to work into the family in a step by step process.

My original effort at creating this family I had devised excessively complicated formulas in an attempt to reduce parameters and what I originally thought to be simplifying the family as a whole. If I had taken advice from my Planning Families post though, I would have started out a little differently. When working through a family, you not only have to take into consideration the 3D elements, but parameters as well. What resulted in an excellent parametric family had absolutely nothing that I could schedule out.

With all the calculations undertaken step by step within shared parameters, I have 17 results I can include within a Revit schedule. The outputs from the family now include data such as:

Catchment flow rate
Calculated maximum flow rate achievable by sump/outlet combination
Depth of sump
h (depth of gutter flow at discharge end)
Dmax (depth of gutter flow at still end)
Dg (Dmax + freeboard)
Gutter high and low points
Td (total gutter depth)

The schedule includes conditional formatting to warn that either the outlet is too small or the sump too shallow/excessively deep. As a further step, I also included a visual warning in the family itself, displaying a text box indicating the error within plan view.

The schedule can then be added to a calculation sheet within the project for design verification purposes.

The data inputs for each sump/outlet can be controlled through the schedule, or the user can double click on the sump within the schedule which will then take them to the family within the project.

The next step is pipe sizing. You would probably know already that Revit does not include a sizing method that specifically applies to stormwater drainage, however I have had some success using the hydronic supply system type with accurate results up to 100l/s which of course uses the data calculated within the family.

For me, being a hydraulic designer and Revit modeller, this family eliminates some double handling in data entry, saving time in modelling and performing calculations. Data entry time is further reduced by creating a fixture tag that pulls the gutter size and sump size from the shared parameters with the family. All for a lazy 90mins development time.