Risers and One-Line Diagrams: Not Just a One-Way Street
The theme for this month’s issue is customization. This can mean different things to different people. It could be as straightforward as reviewing the options and features provided with the software to flex to your way of working. For example, things such as modifying the user interface, keyboard shortcuts, quick access toolbar, etc; a sort of tips and tricks.
Another common form of customization is extending the functionality of Autodesk® Revit® via the API. This is perhaps what most people think of when the topic is customizing Revit. There is no shortage of great add-ins, macros, and Dynamo scripts to customize Revit—achieving things the software can’t do out of the box, but using the information already contained in the model. If you can’t find what you need freely available or for purchase, there is an active community that can help you build your own.
A third type of customization is the infamous Revit “workaround.” These are the contrived workflows to achieve a desired result that the software either doesn’t support at all or not well enough. These usually involve either taking advantage of a bug or anomaly in Revit or using a built-in feature in a way that wasn’t its intended purpose.
In the September 2018 issue of AUGIWORLD, we discussed a specific type of workaround for legends—an often overlooked but essential tool when creating construction documents. We covered the basic purpose of a legend, looked at the built-in functionality provided with Revit to create legends, and discussed alternatives when the provided tools may not meet your needs.
Building on that article I want to review another contentious issue for those on the engineering side of the fence: risers, one-line diagrams, and single-line diagrams, etc. They have many names and slightly different goals, but the basic idea is the same: they are a 2D schematic or diagrammatic depiction of a system’s design. By definition this differentiates them from plan drawings because routing information is not included and not all connections are necessarily shown. Or, in some cases, more information is included that is not shown on the plans.
I think most would argue that risers and one-line diagrams are technically different. A riser is used to indicate connections of a system as it travels vertically through a building, perhaps only displaying the major components. In an HVAC riser, for example, while showing connections between equipment across levels, the more numerous connections to air terminals are usually not included.
A single-line diagram, by comparison, is most commonly used by electrical trades to indicate connections between equipment and various components. They graphically depict the flow and electrical data of the system without necessarily indicating the location of the components.
Plumbing also has its version of risers or isometric drawings indicating connections to fixtures. These typically provide and show information that is difficult to indicate in plan view. With careful planning and implementation, a 3D view or views can be used to achieve an isometric directly from the model.
As with our previous discussion of legends, fundamental questions should be asked when thinking about risers and line diagrams. Does the diagram need to use information from the model, reducing duplicate work and data entry? Or can the diagrams be more “typical,” not necessarily having to stay coordinated with changing information in the model? Having answered these questions, this article will investigate some of the options available in Revit for engineering designers.
At this point it is also worth asking an even more basic question: what role do these diagrams play in designing engineering services for a building? Should the riser or one line summarize what is in the model or should it drive what is input into the model? In other words, what comes first, the diagram or the model?
In my opinion, Revit is more of a modeling and construction document tool than an engineering tool. It does not natively allow for driving the model from diagrams. But that doesn’t mean it isn’t possible. Via the API or even Dynamo, a lot of data and automation can be pushed around. There are also third-party solutions that both extend the engineering design using information from the model or are able to drive the model from the information and layouts performed in their software first.
Still a summarization of what has already been modeled and assigned to a system, Revit has what is called the system browser (and system or circuit schedules to a certain degree – Figure 1).
Figure 1
The system browser is helpful for basic tasks like seeing a tree view of connected items, isolating and editing elements on a system, and finding elements not assigned to a system (Figure 2).
Figure 2
Sadly, its usefulness stops there. All that information available for assisting in creating diagrams! Understandably, risers and diagrams quickly get complicated when considering the myriad standards and requirements each company, discipline, and permitting agency may have. However, I believe it can be framed another way as well. Revit itself provides the technology and tools to create models and construction documents, but leaves many of the “last mile”
decisions such as symbols, appearance, etc, up to the user. The same approach can be used on the system browser with risers and line diagrams. The underlying technology and information is already there in the system browser—we just need a few more tools to assist the user in going the “last mile.” This is an area I hope to see explored.
So we’ve concluded that Revit doesn’t provide a way to start with a diagram and drive the model from there. We’ve also concluded that the system browser won’t help us much in summarizing what is in the model by creating risers or line diagrams. Where do we go from here?
One approach is or was to continue drawing the riser or line diagram in AutoCAD® or other software. This information was then linked in as a DWG to a Revit drafting view. All the standard symbols were already built and it was a tried-and-true process. Why reinvent the wheel?
I see the above approach as a stepping stone to the next option: creating the diagram in a drafting view in Revit. After all, Revit can draw lines, text, and symbols just like AutoCAD, so why not keep it all in Revit? True—detail items, tags, and generic annotations need to be created, but once complete there is a lot to gain from this approach as opposed to continuing to link in DWGs. Parameters, tagging, and even schedule-specific views or elements are a few examples, not to mention eliminating the hassle of opening and modifying the information in another piece of software and then having to reload, all just to see a change.
It should come as no surprise that the above options are not using actual model information. All that parameter and system information from those model elements, but no way to get to it for a diagram. What a shame! Remember those fundamental questions we raised earlier? If your riser or diagram is more typical in nature—not indicating actual element properties or system information from the model—then a drafting view is a good choice.
However, what if you do want model information to be coordinated with the diagram(s) in your drafting view? Obviously, you can do it manually. Had to renumber your chillers or air handlers? Don’t forget to do it on your riser. That’s no fun. This is where customization is required.
Still making use of drafting views there is an approach that can help automate this process. With the API or Dynamo, it is possible to create parameter relationships between elements. I personally use a paid add-in for such purposes. Once the relationship is established, any change in parameter values in either the model or the drafting view updates the other.
If you are fortunate enough to have an in-house person or department capable of programming this functionality into an add-in, macro, or script, the features can be even more automated and customized to your company’s workflows. This approach perhaps requires the most time to implement, but the returns can be fantastic. I’m a big fan of preservation of data and minimizing duplicate data entry. Just think, once in place, no more chasing your tail around trying to remember where to update information.
This gets us to our last “type” of customization: workarounds. The dilemma here most often boils down to these two points: 1) All the information needed for the riser or diagram is in the model; and 2) The technological know-how to coordinate this in a drafting view is beyond your abilities and time limits.
The first workaround option is to a create the riser or diagram in the model. Think about it—all the information is in the model. Why go through the effort of getting that information into a drafting view? A drafting view, by definition, is not tied to the model. So rather than bringing the information to the drafting view, we are bringing the graphical elements (lines, tags, detail items) to the model.
This approach has been around for a while and is well covered in previous AUGI publications. As such I will outline the basic steps but not go through the process in detail. The basic premise is that the information is in the model. We just need to display that parameter information suitable for the riser or diagram by using tags. What is needed then are tags created just for this purpose. They will include the parameter information we wish to display as well as the symbols and graphics we need to use.
If a riser is the desired result, an elevation or section is a good choice for the type of view to create for this purpose in the model. This way you can see levels, floors, even ceilings, if desired, as well as spaces or rooms. If level or floor information is not required, technically any model view type should also work.
In order for this approach to work, all model information needed in your riser or diagram must be visible in your view. This means check to make sure your view crops and offsets are not excluding any elements you need.
Because the model elements should not be moved, risking your plan views, the flexibility required to make the riser or diagram relies on tags. Tags can be moved independently of their model elements. Beginning with version 2017, tags can now be pinned and will not move even if the model element host moves. This enhanced functionality makes this approach much more attractive compared to previous Revit releases.
No riser or diagram is complete without lines to indicate the relationship between elements. Lines can be drawn in model views just like a drafting view. Keep in mind, however, that because the elements are tags we will not have snaps to help us snap the lines to the tags. Further, if these lines need to also “carry” information, perhaps about the system or circuit, line-based detail items can be used. These can hold information in parameters for tagging, can also be used by Revit keynotes, and can even be scheduled.
Lastly, because this is a model view it probably contains information we don’t want to see in our riser or diagram such as links, datum, and family geometry. If we don’t want to see most if not all of the model elements, we will need to control their visibility. Controlling the visibility of links and datum elements is easy. However, turning off visibility for model elements, either by turning off a category or using a filter, also will make the tag for said elements not visible. The solution is to override the color of all elements that need to be not visible, changing their color to white. This keeps the element from printing or plotting but keeps it visible so that the tag(s) also remain visible (Figure 3).
Figure 3
Once all view settings have been changed and configured as desired a view template can be saved for easy re-use.
Don’t forget this is a workaround—using functionality for something other than its intended purpose—so it is not without its drawbacks. First, as I already mentioned, inputting lines between tags does not offer snaps to help with alignment and appearance. The information is preserved at the expense of less graphical consistency.
Second, the tags, with their desired parameters and graphics, must be created for just this purpose. The danger that creeps in here is when different symbols are needed for elements of the same Revit category. Nothing is preventing the user from tagging an element with a tag using the wrong symbol. Or, if during the course of design the element changes types, the symbols in plan view also change. The symbol in the tag in the riser or diagram will then be incorrect. This is not a big problem if your tags are not indicating different symbols.
Third, once tagged, all the tags must be manually moved to their desired locations. This can be tedious depending on the number of elements. Once located as desired, don’t forget to pin all your tags!
Fourth, the scale of the view must be such that it will fit on a sheet. Decide this sooner rather than later to avoid having to adjust annotative elements if the view scale changes (Figure 4).
Figure 4
Fifth, but probably not last, is that this works well for risers or diagrams depicting major equipment connections of a system. But what if more elements are required than just the major connections? For instance, on a security design project, hundreds of elements are to be included in the riser, indicating device information and panel termination location. You may ask why that is even necessary, considering all that information is most likely already on plan or can be easily displayed in a schedule. To that I would say, “your words, my sentiment.” I would completely agree with you. This article would be over. And that’s not happening.
The above requirements are daunting. Either way you look at it, whether using a drafting view with parameters linked to model elements or creating a modified model view to serve as your riser or diagram, it is an arduous task. It is a regurgitation of information displayed differently. We needed another solution.
A coworker recently had a brilliant idea that we have now used on several projects. Making device schedules in Revit is as easy as pie, right? We already use schedules with images for our legends. The next natural step then is to make a schedule to be used as the riser!
Under the right conditions, using schedules this way can dramatically improve the riser creation process. Just like tags in modified elevation views or “smart” drafting views, parameter information is always up to date. However, an advantage is that it removes the need to manually place tags or detail items and order them, sometimes sequentially, as needed. The formatting abilities of schedules assist in standardizing appearance and alignment. Elements can be easily filtered, sorted, and grouped (Figure 5).
Figure 5
Once placed on a sheet, a schedule can be split, now allowing for dynamic column control and arrangement. The columns of the split schedule can be resized as needed to accommodate size restraints of the riser or sheet itself. A single schedule can be used, or another option is to use several schedules filtering by level, for example (Figure 6).
Figure 6
It is not a perfect solution, however. Because schedules can only be placed on sheets, any required lines must be drawn on the sheet directly. If information needs to be added to these lines, you must resort to text or generic annotations.
A possible alternative to the limitation of detail lines, one I have not personally tested yet, would be to still create a drafting view where line-based detail items can be input. By placing the drafting view on the sheet, overlaying the schedule, and working through the viewport of the drafting view directly on the sheet, it may be possible to get the benefits of both worlds. This would allow for parameter information, keynoting, and tagging of the lines, but would rely on the schedule for the bulk of the information.
Were schedules intended to be used in this way? Probably not. Does it work? Absolutely. As long as we are producing construction documents, we will most likely have to continue issuing risers and line diagrams to convey information. Furthermore, as long as we continue to utilize software for those purposes, there will be the need for customization. If the tools provided don’t meet a need, we improvise by creating our own, adding more functionality to what is already there, or finding workarounds.
Nathan Mulder has more than 10 years of experience in the AEC industry. He is currently the BIM and CAD Manager for Guidepost Solutions, a global leader in investigations, compliance, and security consulting, offering design services for security, telecom, and technology systems. A Revit MEP Electrical Certified Professional, Nathan is always looking for ways to fully leverage software to improve the project design and management process. Contact him at mulder.nathan@gmail.com or on LinkedIn.
