MEP Systems: Autodocumentation to Fabrication
In an age of advanced technology such as the one in constant development around us today, the requirements for automation and the proportion of leveraged data to data created are on the rise. A truly eye-opening experience while implementing solutions for EvolveLAB, the BIM consulting firm, has been the number of automatic documentation requests for an efficient modeling to fabrication solution.
With the advent of BIM, a new gold rush occurred with respect to the restructuring and re-education of an organization (MEP or otherwise) to harness the true potential, through lean project development and BIM, of every workflow. Many general contracting firms—firms that are building the world’s most grandiose venues, firms building the next generation healthcare/education/military facilities—are releasing internal mandates for the adoption of automation workflows and a high proportion of architecture firms have converted to a fully BIM process.
Behind every new development is a team of engineers, contractors, and fabricators, that when looked at holistically through the lens of the approaching posterity and their ever-expanding, modern technology driven mindsets, we see not only the ability for adaptation for the utilization of what the future will bring for our current processes, but we also see an opportunity.
The ubiquity of these initiatives is staggering, and this article will outline various components required when adopting automatic documentation to fabrication. The article will also show, more specifically, the Dynamo graphs that can be used to quickly implement this automated process in the Revit environment.
Splitting the Systems into Assemblies
Starting off the fabrication process, we can look at the modeled ductwork system below in Figure 1. This ductwork was split automatically into Revit Fabrication Parts using the “Design to Fabrication” tool.
Figure 1: Duct by design to fabrication and automatic tagging with Dynamo
Some firms have different standards of splitting systems into assemblies for electrical, mechanical, and plumbing, and we have a lot of options for going about making these distinctions. For ductwork, we can set limits on duct length and be sure to split the duct at distances optimal to the takeoffs from any duct lines. For electrical, the conduit will most likely already be split, and we look more to setting parameters to the conduit based on necessities at the start and end of the conduit, necessities based on the conduit bending process, and we can write some Dynamo graphs that will algorithmically set parameters for creating assemblies of conduit systems.
The final point to mention about Figure 1 is the ability to automatically tag the fabrication parts in this 3D view. Although there is the “Tag All Not Tagged” tool that is provided out of the box, we can clearly see how we can achieve a more clean and controlled tagging through the Revit API, either through a Dynamo graph or an add-in.
Gathering our Fabrication Parts from Revit
Figure 2: A Dynamo graph for gathering fabrication parts
Figure 2 is an image of a Dynamo graph. As a preface to the rest of the article to follow, Dynamo is a visual programming language for Revit, and it allows a user to easily drag and drop these “nodes” to move, manipulate, and create data in the Revit environment. We will see many of these graphs throughout the article, and they are all representing algorithms for processing the data harvested from a building information model.
Looking at the far right-most node in Figure 2, we see that we are grabbing “Unique Parts.” For most processes related to fabrication, we’ll want to only grab unique parts (with the count of these unique parts able to be represented in other ways). These will be parts that are unique by Overall Size and Length for the example of ductwork. For example, we’ll need a sheet for the instances of any 8’ 0” round duct runs with a diameter of 8” and similarly for other instances of duct runs. If there are identical assemblies with other systems, these can be consolidated on their own sheets.
Another thing to notice about the first graph (Figure 2) is that it gathers all the fabrication parts for use in other parts of the graph. We can use a filter to selectively pick which fabrication part we’d like to grab. This means that we can have different processes for automatically documenting round/rectangular duct runs, air terminals, and fittings.
Beginning the Documentation Process – Creating 3D and Section Views
Now we’ll be creating 3D views of each of our assemblies for placement onto sheets. Dynamo for Revit will help us out a lot here to be able to quickly manifest these views for all the assemblies. There’s a node that can be dragged and dropped onto the canvas called “AxonometricView.ByEyePointTargetAndElement.” With this node, we can set up our 3D views in a very controlled and methodical way by being able to choose the view direction and to isolate the element we need.
Figure 3: Create 3D views for unique parts
One important aspect of creating views that we don’t see in this script is setting the view template of the view. The reason behind this is we can set which view template is automatically applied to any created 3D views. It’s important that the view template is utilized as much as possible. When the automatic documentation workflow includes the creation of section views, dimensions, and many different categories, isolating elements or hiding elements in the view becomes extremely cumbersome for the graph to take care of. It’s ideal to always look to the view template before implementing view filters or anything related to view graphics.
Lastly, we should take advantage of project parameters in different stages of the process. Project parameters can be used for storing date/time stamp information, storing information if the assembly has already been processed by the documentation tool, and for having the graphs communicate with each other. This will allow processes of the workflow to become more modularized and have a more stepwise operation. By having information stored through project parameters in the different graphs, we can ensure quality control on graph reruns and make sure we keep a tight fidelity between the model and the final documentation output.
Figure 4: Part section
Section Views
For the graphs shown in this article, we don’t create any section views. I’d be remiss if I didn’t cover them in at least a small amount of detail. I’ll stick with the necessities of creating a section view through the API and leave to the reader the exercise of implementing the solution.
For the creation of the section views themselves, there is some basic information we need to have a stable way of gathering. The first of this information is the direction that the section view is looking toward, also called the ViewDirection within the API documentation. The ViewDirection, together with the left to right direction of the section view and the center point of the section view (typically at the assembly centroid), will allow us to create the sections. The next piece of information we need to get is the crop region information. Sometimes this information can be gathered from the bounding box of the element, but a lot of times we’ll have to look at a rotated bounding box or make a general crop region using the longest length, like how we will be dynamically setting the view scales of views that we create when we later set the views onto sheets.
Figure 5: Section placed on created sheet
Dimensioning
Together with creating section views, we can create dimensions, since most likely these will be the views where the dimensions are going to be created.
Figure 6: Adjusted dimension to revise overlapping dimensions
Before undertaking the automatic placement of dimensions, there should be a strategy about how the graphs can tackle simpler dimensions such as dimensions of rectangular objects or dimension strings that are between grid lines or other curve-based objects.
When the dimensioning becomes more complex, such as dimensions from Family Instance to Family Instance or non-standard reference lines within the family, the dimensions may need to be cleaned or manipulated after their original creation to ensure quality. For example, if there is a small distance between multiple objects that are being dimensioned, the dimension values can overlap and the dimension values will need to be adjusted so the leader is pointing back to the narrow dimension line. These types of issues can be less apparent or more apparent from project to project, but it should be a critical part of the discussion when deciding what should be automatically dimensioned and to what extent the automation versus the users should be involved.
Another important point to consider when dimensioning the assemblies in the section views is there are not many options for creating the dimensions outside of accessing the Revit API, outside of the Revit for Dynamo out-of-the-box nodes. The main node for creating dimensions shipped with Dynamo is mostly for dimensions between curve-based elements such as grid lines. This means that the developer implementing the dimensioning will have to use Python within Dynamo or change the workflow to an add-in suite and only do textual programming. It should also be noted that moving from Dynamo to Python or to an add-in doesn’t necessarily mean that it will be more complex, only that it will require more experience with the Revit API. Even though implementing advanced dimensioning can lead to increased efficiency, it is definitely an important point where the investment (cost) can increase more rapidly compared to other implementations such as creating views and sheets due to its inherently more complex nature.
Creating Sheets and Centering Views on Sheets
Figure 7: Create sheets and center views on sheets
Now we have an opportunity to create sheets and place the 3D views that we’ve created as their main content.
Figure 8: Schedule shows fabrication parts have been processed
In the previous graph, along with this one, we have a group of nodes labeled “Set AutoDocumented to True.” The logic of this group in the graph is that we can set this Yes/No Project Parameter to Yes when the graph is run. This will give us an easy way to schedule fabrication parts and visually communicate the progress on the current project with respect to how much of the documentation process has been completed for the project.
At this point, we will be setting the sheet names and numbers. We went with a simple method of grabbing the Overall Size of the Fabrication Part and adding a prefix to it. It’s important to look at the various overall sizes that can be possible and make sure that there can’t be any duplicate sheet names. Sheet names are typically created with reference to an assembly number or other type identifying mark related to the system. For instance, in Figure 9 we can see that one method of setting our sheet number can be through the use of the Mark parameter of the fabrication part.
Figure 9: Mark value used to set sheet number
An important note at this point is to take a look at the view scale of the 3D views that we have created and to dynamically set this view scale to ensure the proper placement and alignment of the view on the sheet. To set the view scale of a view as it relates to the sheet size, we can get the general size of the fabrication part that is being displayed in the view. This can be done by grabbing the length parameter, or it can be taken as the distance from the maximum to the minimum point of the bounding box that surrounds the part.
When it comes to setting the locations of the viewports on the sheet, the Revit API gives us a few tools for getting the size and location of the viewports, view crop regions, and sheet outlines. We can go ahead and run with these methods to implement viewport layouts that are two side-by-side, multiple in a grid, and to have placements based on certain orderings of the assembly identifiers, and clockwise or counter-clockwise layouts. Dynamically changing the scale and the control with project parameters gives us a pretty tight control over how these are laid out and allow us to keep manual edits to the sheets and their viewports to a minimum between when they are created and when the sheets are printed.
Figure 10: Setting assembly information to sheets
For the final piece of the Autodocumentation process, we can take a look at the power of shared parameters in this type of process.
In our titleblock family, we added labels that show the shared parameters for the length of the assembly, the overall size, specification information, and the count of that assembly in the project. This type of exercise of the programming tools available to us is one that to be done manually is extremely tedious and prone to errors. The graph can get the information needed from the assemblies and pass that information to be set onto the sheet. To do this manually, the user would have to select the assembly, read the value, and type the value into the parameter of the sheet.
Figure 11 shows the final output of this graph process that has been outlined.
Figure 11: Set fabrication specifications to sheets
Our final output here is simple. We have moved our systems from design to fabrication, we gathered the information we needed from our assemblies to create 3D views, placed the 3D views on sheets we created, and passed information from the assembly into the sheet for the final cut sheets. We briefly outlined important aspects of creating section views and implementing automatic dimensioning, and we discussed strategies for setting view scales dynamically for fitting multiple viewports on sheets.
Modular construction, generative space programming and master planning, and automatic documentation to fabrication are all ways for the respective organizations to control their process and achieve outcomes that far exceed any previous workflows that have been available.
Mark Mendez is a nascent individual in BIM Consulting. Mark is the Director of Product Development at EvolveLAB, Boulder, Colorado, where he has developed custom software solutions to the AEC industry. He’s an active moderator of the EvolveLAB Community Forum and enjoys answering questions there. Mark can be reached for questions and comments via email at: mark.mendez@evolvelab-inc.com or on LinkedIn.
