IMAGINiT Building Solutions Blog

Modeling a conduit "kick" in Revit

By Jordan Mussett, IMAGINiT Building Solutions

It is an everyday occurrence in the electrical discipline so it is good to know how to create these jogs or kicks. The image below presents the problem. The conduit is running right through the VAV box.

This is when a conduit run will route over and up, or over and down, depending on how you see it. The best way to tackle modeling conduit believe it or not is in plans and sections. By limiting yourself to these views, you remove one of the major axes from the equation; in the plan, you are removing accidental Z axis potential and in sections you are removing wither Y or X axis potential.

For this example, we are going to kick over (X direction) and up (Z direction) 6” and 6” to set myself up to create a “kick”. These dimensions work the best with a conduit size of about ¾”. The larger the conduit gets, the more room you need to give Revit to provide the fittings and connecting piece.

The first step will be to split apart the conduit in front of the obstruction.

 

 

Split it in two with the Split Element tool in the Modify Panel.

 

Overall, this operation can be done several ways, but I prefer to make a copy of the conduit and move it over 6” and delete the original.  This is only a good move if the other end of the conduit is not connected to anything that you will need to reconnect later.  

 

Select the piece you copied in the previous step and move it 6” up, in the Z direction. Now everything is set up to connect the two pieces.

This next part can be done in Plan or in Section. Back in Plan, click on the low conduit, right click and select draw conduit and connect it to the upper piece. Be sure "Change Slope" is selected.

Here is the finished result in plan.

Here is the finished product, up, over to the side and continuing over top of the obstruction.

It is possible that you would want to make your own family for this.  Something similar to a P Trap for plumbing. It is really just pipes but kind of considered its own item.  If you do this, all you have to keep in mind is that I cannot specify that a component family falls into the system family category “Conduit” in the project.

Exporting DWGs from Revit: Exploring options and overrides

By Jordan Mussett, IMAGINiT Building Solutions

Deliverables for projects utilizing Revit often include dwg copies of the drawings in addition to the pdfs and native Revit files. That is normal, but sometimes the client has their own CAD standards that you have to comply with for that deliverable. This post will explain how to override necessary layers in the export dialogue so you don’t have to get into scripting a bunch of AutoCAD dwgs unnecessarily.

Let’s start with the high level options. You have a default layer export that is chosen for you based on the AIA layer guidelines. There are several others, but for architecture, the AIA is the best place to start. Once you get to the next dialogue box, you can choose to name the file manually or have the computer generate a name based on the project name and the view name, choose the AutoCAD year format, and whether you would like to export your Revit links as xrefs. The last option is the most important in here for me. If you uncheck this box, it is kind of like binding all layers together in one file.

For this post, I will be leaving these save settings static as shown below for the behavior that I really want to point out which comes from changing settings in the Export Setup.

You can customize just about all of the AutoCAD Layers that get exported to AutoCAD, which is a good thing. The trouble is, you are not always able to override everything that is in another Revit Link when exporting to AutoCAD – or so I thought.

Now let’s visit the override dialogue box. I am going to change the cut layer name and color of the wall pattern. I changed the initial setting from “A-WALL-PATT” to “A-WALL-PATT-IMAGINiT” Color ID 6 (magenta). An important thing to remember is that the wall on the left in this section export is in the Architectural Revit file, the wall on the right is in the MEP file. I will be exporting the sections to dwg from the MEP file. As you can see, there are quite a few line items and quite a few tabs. For this example, I am only going to change the one item circled below.

The other variable at play here is the Export layer options. From now on, I will refer to these as Export layer options A, B, and C. 

Here is the same screenshot in AutoCAD from the three different options. Remember, the wall on the right, I drew in the MEP Revit file to show more clearly some of these export behaviors.

With Option A – the override didn’t make it through to the wall in the linked file on the left. The cut pattern of the wall is still yellow.

With Option B, the override does make it into the walls that are in the linked Architectural Revit model.

Option C applies the override to the wall within the MEP file and creates additional layers. Oddly enough, there is no linework on “A-WALL-PATT-IMAGINiT”.

As a recap, if you need to override and export to meet client demands, you probably want to uncheck create xrefs in the save options (so you don’t have to bind them afterward), and choose option B for the Export Layer options so overrides can permeate objects in the Revit links.

 

Remember when we all called it AEC…

By Carl Storms, IMAGINiT Building Solutions

If you work in the Architecture, Engineering, and Construction industry then you are very familiar with the acronym “AEC” which stands for Architecture, Engineering, and Construction. However, those simple days of just one acronym seem to have passed us by. Now that we are living in a BIM world and collaboration is on everyone’s mind there have been some new acronyms going around that are trying to be more inclusive. I think the idea is that with BIM and the ability to have models be useful beyond just construction and continues being used for Facilities Management (or building operations) that “AEC” was not enough to get the point across anymore.

So now comes the onslaught of new (and longer) acronyms:

“AECO” = Architecture, Engineering, Construction, and Owners

This seems to be a natural progression from the old AEC. Perhaps the 2nd “O” is not really needed as the operators will be agents of the owner anyway?

“AECOO” = Architecture, Engineering, Construction, Owners, and Operators

This one likes to make sure all parties are accounted for and does include the 2nd “O”. However I find saying “A-E-C-O-O” a bit of a mouthful, I find it rolls off the tongue better is you say it like this “A-E-C double O”.

“OAEC” = Owners, Architecture, Engineering, and Construction

This one has the “O” out front because we all know the Owners (read the money) come first!

Now I’m sure there are more variation out there, which will only make it more confusing. It was so much easier back in the good old days when everyone just said AEC.

I say we have an Acronym Battle Royal (ABR), and in the words of the High Lander “There can be only one!”

Which team are you on?

I’m on Team #AECdoubleO

BIM 360 Glue: Issue exporting NWCs from BIM 360 Revit Add-in

By Carl Storms, IMAGINiT Building Solutions

I had a client point out this issue to me. They tried to export a Revit file to BIM 360 Glue, using the NWC option in the “Glue” feature in the BIM 360 Revit Add-in. It was a Revit 2014 model exported from a 3D view. The project has two Revit links loaded. They set their Navisworks Exporter 2014 to convert linked files but after exporting to Glue, none of the links had been exported.

I did some testing and found that like my client said you cannot upload a Revit file with links to Glue using “Glue” in the BIM 360 Revit Add-in using a NWC format and have the links visible. I tested this in 2014, 2015, and 2016 and it would not work in any of them.

You can get the links to show if you “Glue” it with the DWF file format in all three versions (2014, 2015, 2016).

While looking for a possible solution in the BIM 360 Glue forum I discovered that this is a known issue for Autodesk.

“Just for clarification, the settings of the NWC Export and the Glue plug-in are independent. As a quick update, the error you are experiencing is a Revit issue which is currently being addressed.

We understand that this is a critical issue for our Glue customers, the team are doing their best to fix and release an update that solves this issue. I will certainly post an update in this forum once I receive a time frame as to when this will be resolved.” (Source Link)

The above was posted on Mar. 27th 2015, and as of today there has been no resolution posted.

The work around is to export the model as NWC from Revit using the export as NWC feature under the application menu, not by using the BIM 360 Add-in in the Ribbon.

Make sure when you do this that “convert link files” is selected in the Navisworks Exporter for the version of Revit you are using.

Then you can manually upload the NWC file to your BIM 360 Glue project and the links will be visible in that version within BIM 360 Glue.

 

It’s an extra step, but it does work.

Here is a screen shot (below) of what the file looks like when exported using the BIM 360 Add-in for Revit. The two linked files are not part of the model.

Here is a screen shot (below) of the same model that was exported using the NWC export feature under the application menu in Revit. The two linked files are now part of the model, and visible.

 

Setting the Right Standards: The Intersection of Levels of Development (LOD) and Facilities Management

A great deal of the information captured in construction models is helpful for ongoing facilities management work. However, identifying the data that is most valuable for FM and then getting that into the appropriate facilities management system is not always easy.

During the design and construction process, architects and contractors often use a Level of Development (LOD) Specification. This standard helps teams specify information in Building Information Models (BIMs) with a higher level of clarity and reliability. The specification referenced above uses and expands on LOD definitions that were developed by the American Institute of Architects (AIA).

There are six levels of development – LOD 100, LOD 200, LOD 300, LOD 350, LOD 400, and LOD 500. These define how much detail is included in a model element. To derive the information needed from BIMs, facilities management teams should create their own standards that refer to the LOD specification framework. Here are three tips that can help your team with this effort:

1. Recognize that not every model element needs information at the most granular level of development. Wasting effort on detailing that’s not needed is never advisable from a time and effort perspective.
2. Decide which facilities management functions could benefit from information stored in the Building Information Model (BIM). Take time to map out which activities would take less time or be more cost efficient if BIM data was available in the facilities management information system.
3. Determine what LOD is needed to support different FM activities. For example, space and asset management may not need information specified to a high level of development. Remodeling, however, usually requires a much higher LOD and may demand field verified information.

Has your team created an organization-specific standard that defines what information facilities management needs from BIMs and what LOD is appropriate? If not, what’s been holding you back? IMAGINiT’s facilities management team understands how to guide teams through standards development, as well as how to integrate BIM source data with facilities management systems. We’d love to hear what challenges you are facing.

Schedule Keys & Custom Parameters

By Jordan Mussett, IMAGINiT Building Solutions

Revit MEP disciplines often need to fill the gaps in their workflow with shared parameters. But wouldn’t it be nice if the data going into those parameters could be inserted in a regimented and orderly fashion? Look no further than Schedule Keys to help make this a reality.

Here is the link to the whitepaper.