plumbing

Step by Step Guide – Creating My Iplex FWG Family in Revit

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.

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.

Sizing AS3500 Compliant Pipework Using Revit – Part 2

An important part of domestic water design is calculating flow and pressure losses, a common complaint I have from fellow Aussies though is that Revit’s pressure loss report is it’s not in a familiar format and is not something that they’re comfortable including within their design folders. Not to mention, with the AS3500 pipe sizing work(around)flow that I posted last week, the flow rates still don’t quite match up due to the IPC vs AS3500 conversion factor.

So with a powerful tool like Revit at your disposal, why not utilise it to generate data outputs that are in that familiar format and that you are happy to drop into your design notes?

There is always old faithful – the Excel spreadsheet that performs all your calculations..

2016-05-13_17-59-59

..because it’s the way you’ve always done it, so why change right? Not a bad solution if you want to spend the rest of your career manually measuring pipework on drawings to verify your design; ultimately though this is how we came to the true “She’ll be right” Australian method of pipework sizing. After all, doing it properly takes far too long, so just go with your gut and prove your design with actual calculations later, but only if someone questions it down the track.

Did you know you can recreate basic Excel calculations within Revit schedules using calculated values? Of course you did! OK so maybe you didn’t. The problem I have with this method though is due to needing to neutralise Revit units your formulas will start looking a little.. weird.

Take the following example, comparing a simple Excel formula to it’s Revit equivelent

This

=D32*0.001/(0.7854*E32^2*0.001)*1000

Becomes this

=((AS3500_PSD / 1 L/s) * 0.001) / ((0.7854 * Diameter ^ 2 * 0.001) / 1 m²) / 1000

Which how you’d explain that to another engineer I’m not quite sure. They’d probably look at you like you’re a bit odd. So what’s the solution then? Well, maybe you’ve heard of this thing called Dynamo? It’s frequently touted as the best method to model a facade made from old chairs, but did you know that Dynamo can be used for actually useful things too?

In Dynamo, our formula is quite clean and simple, in fact if you squint a little, it looks just like our original Excel formula.

2016-05-13_11-05-15

Armed with that knowledge and a bit of time, that trusty old Excel sheet you’ve been using your whole life can be converted into Dynamo. Once you’ve got the calculations working off your Revit model in Dynamo you can generate all the data within your schedules for every single piece of pipe in your model within seconds. So do you still want to spend the rest of your life measuring pipework? I thought not..

And here are the fruits of my labor. My graph was developed in 0.9, but I can confirm it will work in 1.0 and the 1.0.1 pre-release.

2016-05-13_18-23-13

Stepping through from left to right, this is how it all works:

Starting off simple, I’m selecting all the pipework within the model.

2016-06-15_12-16-57

From there, we’re feeding the All Elements of Category node into the Element.GetParameterValueByName node. Filter out the pipework elements based on their system classification using a combination of String.Contains and List.FilterByBoolMask. This gives a set of true and false results for all of the selected elements, which in this case is our pipework. We take the “in” output of the List.FilterByBoolMask which gives only the elements marked as true.

In this instance I have used String.Contains and checking for the string water. What this means is that it will select anything with water in the name, which would include cold water, hot water, rainwater and so on. You can adjust this to filter out your pipework as you need for as many different systems as needed.

2016-06-15_12-24-58

From this point onward is where all the good stuff happens. We push our pipework out to three separate groups of nodes. A Barrie Smith lookup, velocity calculations and head loss calculations. The Barrie Smith lookup was the most difficult part as it required custom python code to perform the lookup.

2016-06-15_12-32-00

In this group, our results from the previous step feed into the Element.GetParameterValueByName node. We’re picking up the calculated fixture units from our pipework and multiplying it back out by our 3.5x multiplier from my previous post to give us our actual AS3500 compliant fixture units. The code block in the upper left generates a list which is Table 48 from Barrie Smith transcribed to Dynamo. The fixture units and Table 48 are then fed into the custom python node

2016-06-15_12-45-31

The output of the python node then feeds into a math divide node and we divide our flow rate figures by 28.317 and pushes the result to a flow based parameter that I’ve named AS3500_PSD. The reason for division is that Revit stores all units of measurement in imperial rather than metric. When inputting data through Dynamo, Revit doesn’t know that you’re inputting metric figures. What this means is that when you review your data in Revit, you have input 0.23 gallons per minute, not 0.23 litres per second.

Heading back to our second (green) step, the List.FilterByBoolMask node feeds into another Element.GetParameterValueByName node. This time we’re picking up the diameter of our pipework and we’re finding the diameter in imperial and converting it to metric using a formula within a code block.

2016-06-15_12-56-46

The metric diameter from the code block and the probable simultaneous flow rates from the third (blue) step combine first to calculate our velocity. The calculated result is converted back to imperial and populates to a velocity based parameter named AS3500_Velocity

2016-06-15_12-58-48

Our last fork from the second (green) step is to calculate our head loss for our section of pipework. The brighter pink section first takes our length. Now for whatever reason this is taken in millimeters,  so no conversion from imperial required. In the purple section we’re feeding the code block with our pipe size and probably simultaneous flow from previous steps to calculate headloss per 100m, then another code block to calculate headloss for the section of pipe. Finally we push our headloss calculations into their respective parameters AS3500_Headloss and AS3500_HeadlossSection.

2016-06-15_13-09-26

When you’re finished, you end up with a schedule you can drop on your drawing or export to Excel for design verification, and it’s all calculated as you model and far more accurate than you would have ever provided before.

2016-05-12_23-35-53

The example that I’ve used here is highlighting flows where the velocity falls outside the acceptable range of AS3500, so you have a simple visual prompt that you need to check your design. I have found though that most of the time, the design is correct and the sections of pipe highlighted are either 15dia supplying a single fixture with a velocity greater than 3.0m/s or 20dia with two fixtures connected with a velocity of less than 1.0m/s.

Give it a go yourself, once the Dynamo portion is humming along your return of investment is incredibly quick.

Creating Pipework Drop/Rise Hexagons

If you’re located in Australia or New Zealand, chances are you use these lovely hexagons or some other variation of them to annotate pipework dropping or rising.

2015-03-10_11-37-38

But how do you create them in Revit? It’s quite simple actually. For this example I’ll assume you have not created an annotation family before and therefore is aimed at beginners.

First, start by creating a new annotation symbol using the generic annotation template.

2015-03-10_11-41-30

In the Family Category and Parameters dialogue, change the family type to a Pipe Tag

2015-03-10_11-44-21

You can either draw up the hexagon manually or you can temporarily insert a DWG file to trace over the top of. Once you’re done, you should have your trusty hexagon sorted.

2015-03-10_11-48-05

To add the text to your symbol, you want to use labels. You can find the label tool on the create panel of the ribbon.

2015-03-10_11-49-38

When creating the labels, you will need to select the parameters that you want to pull the data from in your model – we will be using Diameter and System Abbreviation. The reason why I use System Abbreviation is that it will automatically propagate to all pipework in the system where as other parameters do not. Don’t forget to adjust the text style of the label to suit your drafting standards.

2015-03-10_11-52-59

The next step is to apply a visibility setting on the filled drop and rise indicators. Simply select the triangle and and in the properties window, look for the Visible parameter. Select the small square at the end of the line (marked at 1), you will now have an option to select parameters to apply, yours should be empty.

Select Add Parameter and then create a new parameter with the name RISE. Make it a Type parameter and sort it under Graphics.

Repeat the process for the drop indicator.

2015-03-10_12-07-46

 

Finally open up the Family Types dialogue

2015-03-10_12-12-24

Create a new family type called RISE and then check the RISE parameter and make sure that DROP is unchecked. Do the same again creating a family type named DROP and check the DROP parameter, making sure that RISE is unchecked.

If you want to get tricky, you could use a not( ) formula. Simply type in the forumula

not(RISE)

in the drop parameter. When RISE is checked, drop will be unchecked and when RISE is unchecked, DROP will be automatically checked.

2015-03-10_12-13-19

And that’s it! Once you’re done, save your new family and add it to your template.

When tagging your pipework, you need to manually select if it is a dropper or riser by selecting the family type from the properties window, the size and the service however will be automatically filled out for you.

For the System Abbreviation parameter to be picked up, you will need to have this filled out in your pipe system settings for each service, note that it is simply listed as Abbreviation in the system settings.

2015-03-10_12-00-43

If you don’t use systems (you should be using them!) and rather you use pipe types to define your service, the System Abbreviation parameter will not work and you can use a shared parameter instead to populate the label within the annotation.

Making Revit Work For You Using Advanced Families.

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.