revit

Lookup Tables and You – Part 2 – Improving Your Workflow

Now you understand how lookup tables are formatted and referenced from Revit families, let’s have a look at how we can improve our workflow.

It’s clear how lookup tables are beneficial to the pipe and conduit modelling process, so how can we use them in other Revit family categories?

Originally lookup tables were only available to pipe and conduit fittings, but we can use them in any family category. We can build fully flexible families that a controlled with lookup tables, we just need to use a bit of common sense when deciding if a lookup table is best suited or not.

Valves would be suited quite well to utilising lookup tables, whereas a VAV box would be more suited to using formulas and other parameters.

Building Your Own Lookup Table

You can use dimensions, angles and integers to both look up and be looked up, the trick to working with integers is that your column header format should follow

ParameterName##number##integer

Using integers can be valuable within lookup tables to control the dimensions of specified manufacturer equipment. To achieve this, we need to take the manufacturer sizes and populate them into a lookup table. Working this way locks down the sizes so that the end user is unable to manipulate them. In this example, we’re going to work with a basic rainwater tank.

Rainwater tanks are a perfect use of lookup tables, you could have a family file that contains data for one manufacturer, then the lookup table drives the dimensions based on the volume. We use the volume value because this will drive all other dimensions of the tank.

We’re going to use an integer parameter for our tank volume, as volume parameters can not be used in lookup tables.

This is our basic lookup table to get started with. We’re going to look up the volume as an integer which will in turn drive the tank diameter, height and inlet height dimensions.

You can see that based on our basic lookup table and our lookup formulas, the correct data is being input into the family.

Once the lookup table is populated with the tank dimensions across the product catalogue, all a user needs to do is change the tank volume to a value that corresponds with one in the lookup table and all the dimensions will automatically update.

A trick that can be used with lookup tables is that we can drive a single text parameter with a lookup table, the same old restrictions apply though, if you’re looking up an instance parameter, you must be driving an instance parameter.

The secret behind bringing text in from the lookup table is to leave the lookup column in the formula blank. In our rainwater tank example, that would read as follows

size_lookup(Lookup Table Name, “”, “NOT SPECIFIED”, TankVolume)

Getting More Advanced – Allowing Custom User Input

The example water tank is great when you want to completely lock down a family, but what if you want the option to allow input form the user? We can allow for this by adding a few additional parameters to the family.

To achieve this, we’ll add a yes/no parameter to the family which can be checked when the user wants to specify a custom size. When checked, this parameter will override the lookup table.

We then need to add parameters within the family for every parameter that is controlled by the lookup table.

The new parameters that have been created in the family are CustomDiameter, CustomHeight, CustomInletHeight and CustomTankType.

We now need to change the formulas for each parameter being controlled by the lookup table so that the lookup formula is nested within an if statement.

This also allows our trick with the text lookup to make it very clear that custom dimensions are being used, as we’re changing the TankType parameter to read “CUSTOM DIMENSIONS”

Modifying Existing Pipe Fitting Lookup Tables

Now that we know everything there is to know about lookup tables, modifying existing lookup tables should be quite easy. For this example, we’re going to use a PVC pipework bend.

You can download a copy of the files I’m working with here

 

Open the family

Open the family type dialogue

Click on the Manage Lookup Tables button

Export the existing lookup table

Rename the lookup table to Bend_PVC_DWV_Iplex.csv

 

Back in the family types dialogue, import the new Bend_PVC_DWV_Iplex.csv and chance the Lookup Table Name parameter to Bend_PVC_DWV_Iplex

Apply the changes and close the family types dialogue before continuing.

Download a copy of the Iplex DWV piping catalogue from http://www.iplex.com.au/iplex.php?page=lib&lib=8&sec=186 we will be referring to the Plan Bend F&F on page 24.

We also need to refer to the Drain, Waste & Vent Pipe table on page 23 for information about pipe diameters and wall thicknesses

Open the .csv file in Excel. The out of the box (OOTB) lookup table is in inches, it is up to you if you convert the current dimensions to millimetres or not, but we will need to change the column headers from inches to millimetres (USA spelling)

Compare the dimensions of the Iplex product catalogue with that of the Revit family.

Iplex Catalogue Revit Family
L1 – L2 (from fitting table) Centre to Socket Bottom (CtSB)
L2 (from fitting table) Socket Depth (SDpt)
a (from fitting table) Angle
L1 (from pipe size table) Fitting Outside Diameter (FOD)
L2 (from pipe size table) Wall Thickness (WThk)

Something to take note of is that the L1 dimension from the pipe fitting takes into account the total length of the fitting from the centre of the fitting to the end of the fitting including the socket.

Within Revit the Centre to Socket Bottom does not include the socket, so the figure that we need to take for CtSB is actually L1 – L2

In this example, I’m going to start with the 40 dia fitting size, however if you have a need for the 32dia pipe fittings you can start there.

There are 3 different 40 dia elbows in the Iplex catalogue. 40×15°, 40×45° and 40×90° each with differing dimensions. To allow for each specific fitting, we’re going to add a row for each fitting from the catalogue.

Fill out the corresponding data to the lookup table from the Iplex catalogue, once done, save the csv file and load it back into the family and test the flexing of your new 40 dia fitting.

If you’re happy with how the family flexes for your 40 dia fitting, continue adding the remaining sizes to the lookup table.

Once you’re finished you’ll have a complete, dimensionally accurate Iplex PVC pipe fitting.

Lookup Tables and You – Part 1 – Understanding Lookup Tables

Life isn’t just about Dynamo, so here is something a little different to mix things up.

Earlier this year I spoke at BiLT ANZ 2017, I had the opportunity to present two separate talks of which one was lookup tables. It’s a bit of a dry topic, so stick with me.

Lookup tables for pipe and conduit fittings provide an invaluable enhancement to the MEP workflow that we take for granted. On every project we work on, lookup tables save us countless hours in the modelling process. Without them, modelling a pipe system would require each individual pipe fitting to be sized as you go. It may be only a few seconds lost per fitting, but multiply that by hundreds or even thousands of times across a project. Then consider the revisions across the piping network. Those few seconds wasted quickly adds up.

At their core, lookup tables are simply comma separated value files (.csv) that are used in conjunction with Revit family files. Prior to Revit 2014, these files were stored on your hard drive or in a common network location and that location was referenced by the revit.ini file.

You might have had experience with tiny pipework fittings that wouldn’t size correctly in Revit if the lookup table location was not correctly configured. Nowadays, lookup tables are stored within the family themselves, provided your family content has been properly updated to 2014 or newer the new system with embedded lookup tables should eliminate those tiny fittings altogether.

Most commonly lookup tables are used for defining pipe and conduit fittings based on the nominal diameter of the fitting. Revit is then able to automatically size and resize fittings based on the size for the pipe the fitting is connected to by using the data contained within the lookup table.

The Lookup Table Format

Lookup tables can be created and edited in either a simple text editor such as Notepad or Notepad++ or in Microsoft Excel and it’s alternatives.

The first column is a reference column, the values in this column could be ‘Tom’ or ‘Jerry’ but it’s obviously more useful to give enter data that is relevant to the family being created.

Usually when dealing with pipe and conduit fittings this is the nominal diameter, when dealing with pipework branches, I like to format my references as Upstream x Downstream x Branch so for example, 100x100x65. You could however include product names, say if it was a 5000 litres grease arrestor, the reference could be GreasePit5000

The second column defines the lookup value which is typically the nominal diameter of the fitting. This is the column that Revit will look up to determine the remaining parameters for the element.

The formatting of the headers within the csv file is

ParameterName##ParameterType##ParameterUnits

which you can see in the example above. The formatting of the headers is critical for the lookup tables to work.

In column B of the example, we have ND##length##millimeters (note US spelling of millimetres) which in this to the nominal diameter, it’s a length parameter and the units are in millimetres.

If further lookup values are required, say for example in the instance of a pipework branch, more lookup columns can be added as needed, shifting the remaining columns to the right.

As you can see in the above example, we have three nominal diameter columns to determine the size of our fitting.

The remaining columns after our lookup columns contains the data that drives the modelled dimensions of the Revit family and you can have as many lookup columns as you need to generate your family.

How Lookup Tables Are Used in Revit Families

Lookup tables are stored within the family file itself through the Manage Lookup Tables dialogue. The lookup table is then referenced using a text based parameter and lookup formulas are used to retrieve these values from the lookup table.

Importing and Referencing the Lookup Table

To import the lookup table, you first must open the family file itself. In the family types dialogue box, click on the Manage Lookup Tables button.

Once in the Manage Lookup Tables dialogue, you have the option to either import or export the lookup tables contained within the family.

If you’re starting with a family that already has an associated lookup table, it’s always a good idea to start by exporting the original lookup table so you can use that as a base and then modify.

Once you have a completed lookup table, you can import it in the Manage Lookup Tables dialogue. You can have multiple lookup tables within your family files and chose whichever is required.

Once the lookup table has been imported, you need to add a text parameter to the family that references the lookup table name. Historically this parameter has been named Lookup Table Name although you can name this parameter anything that you like, it’s best to remain consistent with the out of the box parameter naming.

When filling out the parameter data, it needs to match the name of the .csv file that you are going to use, minus the .csv extension.

Lookup Table Formulas

The formula used to reference the lookup tables is

size_lookup (Lookup Table Name, “Lookup Column”, Default If Not Found, Lookup Value) 

The format of the formula is similar to that of an if statement.

The first portion of the formula is telling Revit to find a value in the lookup table “Lookup Table Name” for a column named “Lookup Column” and then pull the value from the row that corresponds with the value from the “Lookup value”. If there is no match, Revit will provide the value from “Default If Not Found Value”.

In the example above, the formula is finding the value for the fitting outside diameter.

Stepping through the formula, Revit will lookup the table that has been defined in the parameter Lookup Table Name for a value in in the column named “FOD” that corresponds with the lookup value of the Nominal Diameter parameter (50mm). If no match is found for the nominal diameter in the lookup value column, a value equal to Nominal Diameter 1 + 9.1mm will be returned.

Note that the nominal diameter is currently set at 50mm. If we refer to our csv file we’ll see that our lookup value is ND1 which corresponds with Nominal Diameter 1 in our family.

When ND1 is 50mm we can see that the value of FOD is 56mm, this has set our family to have a fitting outside diameter of 56mm.

What About Multiple Lookup Values?

You may have noticed that the example family used is a DWV pipe branch fitting, so we need to deal with multiple lookup values. The fitting may be a reducing branch or it may have different variations in branch angles.

To achieve this, we simply need to add more lookup values to the end of the formula.

In this example we’re looking up the socket bottom to socket bottom run, we are again referencing the same lookup table however this time we’re looking for a match for Nominal Diameter 1, Nominal Diameter 2, Nominal Diameter 3 and Angle in a single row within the lookup table.

If a match is found, Revit will return the value from the column that corresponds with SBtSBR. If no match is found, Revit will return a value equal to that of Nominal Diameter 3 + 27.7mm.

This particular fitting we are working with is a 50x50x50 x 45° DWV branch

Referring to our csv file, we can see that when we look up the values 50, 50, 50 and 45 the corresponding value in the SBtSBR column is 81mm which is the value that has been set in our family.

Remember that the lookup columns need to be in order in columns from left to right to be able to lookup multiple values.

 

So that’s it for understanding how lookup tables work, stay tuned for Part 2 where we look at applying the use of lookup tables to improve our workflow.

 

Tagging Invert Levels

Over the years, I’ve seen a lot of err.. solutions for tagging invert levels. From adding shared parameters to your pipe families through to using Dynamo and everything in between.

Ignoring the fact that you can’t add parameters to system families like duct and pipework, there is a far simpler way to get what you’re after.

Ever heard of the spot elevation tool?

The key is in the settings that you use.

The settings that I use in my templates are as follows, the settings to change are highlighted below

In the units format dialogue, change the your settings to match the following

And of course, don’t forget to select the bottom elevation!

Importing DWGs to Revit While Still Displaying MTEXT Correctly

For those of you that still heavily rely on DWG based details and schematics that are bought into Revit from AutoCAD, you might have experienced issues maintaining the correct alignment of MTEXT once imported into Revit.

There is actually quite a simple solution, and no it’s not exploding the text.

In AutoCAD, MTEXT has grips that define the bounds of the MTEXT element.

The location of the grip indicates that the MTEXT bounding box doesn’t actually fully enclose the text contained within it. When the DWG is imported into Revit the text is displayed differently, it gives a completely unexpected result by placing the MTEXT word on the same line as TRUNCATED

If we modify the bounding box in AutoCAD to not truncate any of the text with the bounding box like so

And once we reload the DWG file into Revit and the text will display correctly.

 

Practical Dynamo – Moving Views Based on Another View

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 Categories and 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.

Hit the run button and watch the magic happen.

Practical Dynamo – Moving Views on Sheets

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!

Practical Dynamo – Generate Sheets from Excel

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.

Site Extraction with flux.io and Dynamo

By now, most people in the industry would have heard of flux.io, a spin-off from X (formerly Google X). Recently, flux.io updated their site extraction tool which pulls data from free open source datasets, Open Street Map and NASA. When combining with Dynamo, it couldn’t be any simpler to pull in topography information to your Revit model.

So how do we get started with this new-fangled technology?

Firstly, you’ll need a flux.io account. Once you have that sorted head on over to https://extractor.flux.io/ Once there you’ll be greeted with a Google map where you can search for your location. The map system works exactly as you expect it to. Simply drag and resize the selection box around the area you’re interested in and then select what you want from the menu on the top right of your screen.

When your data is ready, you can open it in flux and review the results. You simply drag and drop your keys from the column on the left into the space on the right. You can pan, zoom and rotate your way around the the 3D preview although as someone that works in Revit and Navisworks all day long I found that the controls aren’t the easiest.

Struggling with the navigation?
right mouse button = pan
left mouse button = orbit
scroll button = zoom

So all of this is great, but how do you get this into Revit? It’s actually incredibly simple.

You will need to have both Dynamo and the flux.io plugin suite installed, but once you have those installed you’re only a few minutes away from generating a Revit topography.

To get started you will need to login to flux.io through Revit and Dynamo, if it’s your first time using flux.io you might have to approve the connection between Revit/Dynamo and flux similar to what you would when sharing account information with online services and Google or Facebook.

Find the Flux package within Dynamo and first drop in the Flux Project node.

Once you have your flux project selected, it’s just three more nodes. Drop in the Receive from Flux node and select topographic mesh from the drop down. From there push the flux topography into Mesh.VertexPositions and then finally into Topography.ByPoints

Comparing the flux topography in red against the professional survey in blue, we can see that the flux topography is no replacement for a real survey, we are looking at a 5-8m difference between the survey and the flux data. Thankfully, surveyors aren’t going to be out of the job any time soon. This is the case on the example site in Sydney only though, other sites are far more accurate depending on where the source data is coming from. Remember the flux data is coming from a combination of sources including survey from satellites which leads to varying levels of accuracy. You shouldn’t rely on open source data like this as your sole source of information. You should be referring to relevant site survey information to verify the data against.

The inaccuracy of the data though doesn’t mean that the flux data is useless. Provided that you’re able to reference the flux data with known survey data and adjust to suit, this provides an excellent opportunity for using the flux data to fill in missing information surrounding your known survey and site. You then have opportunity to use the data for visualisation in concept stages or flyover presentations of large sites or precincts.

 

Using Dynamo to Generate Pipework Hangers

If you’re finding yourself modelling more detailed models that reflect proposed fabrication or constructed works, Cesare Caoduro over at the BIM and Others blog has a great step by step tutorial on how to use Dynamo to generate Unistrut style pipework supports.

If you’re mechanical or electrical it would be quite easy to adapt the first portion of the script to generate the same type of supports for ductwork and cable trays.

You can check out Cesare’s post here

Consistency is Key. Setting Project Info With Dynamo

Over the last 3 months I’ve been busy working hard on coordinating the BIM for an existing infrastructure study of a hospital. The site consists of everything from heritage listed sandstone buildings constructed in the 1800s where for obvious reasons there are no existing drawings to a building that’s currently in the final stages of construction and has been fully designed and coordinated in BIM. The infrastructure study involved locating assets and services that interconnected between buildings within relatively accurate space within the BIM at LOD 200 as per the BIMForum guidelines.

When it came to the BIM, we decided to work with one building per MEP model which meant we had 28 MEP building models, 28 architecture building models that were created using a series of stacked DWG files and 4 site models. The obvious problem with so many models was going to be the consistency of the data and how we would go about verifying that data. Ensuring that we had all 60 models with the same information consistent information was a mountainous task that would have taken an exorbitant amount of hours to complete if manually reviewed, even if utilising BIMLink.

Enter stage left: Dynamo.

We used Dynamo far more extensively on this project than any that I have worked on before. Normally I’d work with little snippets to process small amounts of data and automate minor repetitive tasks, but this project was a real BIM project; there were no traditional drawing deliverable which actually seemed to genuinely baffle newcomers to the project. The deliverable was the federated model and more importantly the information contained within all the individually modeled elements. A few hours on one of my Sundays and I ended up with what you see below

2016-09-16_14-30-00

That structured mess was able to verify photo file names and associated photo URLs, it verified asset codes were correct and if they weren’t, it generated new asset codes in the required format, it also checked and corrected all the information required to generate those new asset codes and finally probably the simplest part of it all, it filled the project information parameters for us. It was run on all MEP models, with another run on all the architecture models that we created.

Although we were able to automate a lot of really mundane processes, they were for the most part fairly project specific so even though the Dynamo script itself was invaluable to the project, other than the experience provided it doesn’t hold that much value for future projects. There was however one custom node that I put together for the population of Project Information parameters that will probably get used again and again on projects in the future.

2016-09-16_14-48-01

Each input of the node is filled with a string for each individual parameter. In the project, the building name/number parameter relied on the levels within the model being named correctly for which there was another portion of the script that checked that the naming conventions for levels were followed.

The processing of the data itself is performed by Python code inside the custom node, after which the output showed the data that has been filled. You can either pick the custom node up from the MisterMEP Dynamo package or if you want to recreate this yourself the Python code is below

 import clr
clr.AddReference("RevitServices")
import RevitServices
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager

doc = DocumentManager.Instance.CurrentDBDocument
projinfo = doc.ProjectInformation
#The inputs to this node will be stored as a list in the IN variables.
OrgName = IN[0]
OrgDesc = IN[1]
BuildNumber = IN[2]
ProjAuthor = IN[3]
ProjDate = IN[4]
ProjStat = IN[5]
ProjClient = IN[6]
ProjAddress = IN[7]
ProjName = IN[8]
ProjNumber = IN[9]

TransactionManager.Instance.EnsureInTransaction(doc)


projinfo.OrganizationName = OrgName
projinfo.OrganizationDescription = OrgDesc
projinfo.BuildingName = BuildNumber
projinfo.Author = ProjAuthor
projinfo.IssueDate = ProjDate
projinfo.Status = ProjStat
projinfo.ClientName = ProjClient
projinfo.Address = ProjAddress
projinfo.Name = ProjName
projinfo.Number = ProjNumber

TransactionManager.Instance.TransactionTaskDone()

elementlist = list()
elementlist.append("DONE!")
elementlist.append(projinfo.OrganizationName)
elementlist.append(projinfo.OrganizationDescription)
elementlist.append(projinfo.BuildingName)
try:
elementlist.append(projinfo.Author)
except:
elementlist.append(list())
elementlist.append(projinfo.IssueDate)
elementlist.append(projinfo.Status)
elementlist.append(projinfo.ClientName)
elementlist.append(projinfo.Address)
elementlist.append(projinfo.Name)
elementlist.append(projinfo.Number)
OUT = elementlist
#OUT = "done"