Filter Criteria Order Matters

Taylor wrote to me to say that he noticed a subtle quirk when he wanted to filter pipe in a schedule. He needed to focus on Mark values that contain M15 and M16 for example. He discovered that the filter would work if he put the criteria in that order but that if he happened to reverse them like this, M16 and M15, Revit no longer found the M15 pipes.

Definitely subtle.

Family Not Shared vs Shared

This isn't about sharing things with others. This about the concept that Revit 7.0 provided to families in 2004. It presents itself to us in Family Category and Parameters dialog or just in the Properties Palette if nothing is selected.

Shared or Not Shared means nothing unless the family is then nested into another family. There is really no reason to make a family shared at all if it isn't going to be nested in another family.

Most content is Not Shared, not checked. You can nest families that are not shared and you will see them when the host or parent family is loaded into a project. You see them but they aren't really there, they are just symbols. Revit has not loaded the definition of the nested family(ies) into the project. You can confirm this by scanning through the list of families in the project browser, you won't find it there.

When a family is Shared, checked, something special happens when the host family is loaded into the project. The nested family is loaded into the project too. You'll find it IS in the Project Browser now. Since it is now "real" that means Revit can include the nested shared family(ies) in schedules. You can tag them too. You can use the 2014 Displace Elements on nested shared families too.

You can also place an instance of the nested family separately if desired. By the way, nested families, whether shared or not, "kill" temporary dimensions, they don't show up automatically when you select the family. You need to click the Activate Dimensions button (Options Bar) to get them to appear.

Mass Floor Area vs Volume

I managed to trick myself into believing that area and volume for a "floor" should be the same whether a mass has one or several mass floors. To help explain my delusion, I created a mass that is a 50x50x50 cube, with five levels.

If I remove two levels from the mix (levels 2 and 5) I get twice the volume for floors at Level 1 and 4

Looking at the 3D view it immediately made sense to me. Looking at the schedule I found myself thinking something was wrong. Why is there double the volume? Why would the floor think it is so much bigger? The real problem was my perception. I was thinking floor, the thing I walk on, instead of a "floor", where I am in the building.

If it isn't obvious, the Mass Floor area is the surface area of the mass floor element. The Mass Floor Volume is the volume between mass floors or the top and bottom of the mass if there are no other mass floors.

Btw, you can select and delete a mass floor, like in a 3D view for example, and that's the same as opening the Mass Floors dialog and un-checking a level.

Learn to Program the Revit API

If you are interested in learning the Revit API Harry Mattison (Boost Your BIM) created an online course hosted at Udemy (The Academy of You).

It's delivered in 33 video segments which vary from a few minutes to a little over fifteen minutes. It's also very reasonably priced at $149.00. Maybe I'll see you on campus?

Learn to Program the Revit API

Paul Aubin Book Survey Seeks Input

Paul Aubin recently mentioned that he's working on a new book, title TBA. The title is one of the things he's asking about in the survey.

If you are interested in the subject and can spare a few minutes to

Click to Take the Survey

Project Base Point Manipulation

I written before that I occasionally experience something that feels like a "Revitary alignment" regarding features in Revit. I'll see a post at AUGI or get an email or two from friends or clients asking about the same thing or theme. I recently ran into a user that manipulated their project by moving the Project Base Point. Then a post at AUGi meandered into a related conversation.

General Statements

• The Survey Point allows us to show where an imported CAD file's origin is relative to your model (CLIPPED)
• The Survey Point allows us to identify a benchmark location on the site instead of referencing source file's origin (UNCLIPPED)
• The Project Base Point does not ever "need" to be moved (CLIPPED) normally (my opinion/belief/preference)
• The Project Base Point will allow us to move our project on the site to reposition it (CLIPPED) but the file origin isn't changed
• The Project Base Point (UNCLIPPED) will let us identify an alternate location that Spot Elevations and Spot Coordinates can reference

Applied to a Project

Let's say you design a house, import a survey and it's off to the right and above your building. If you use Acquire Coordinates on the survey file you should find the Survey Point (CLIPPED) moves to mark the origin of the source survey data file (sometimes this is quite far away). The Project Base Point (CLIPPED) can be used to reposition the building over the site. Just drag or move it with specific values. What you see moving is the "Project". The file origin is untouched and you should see that the linked survey file isn't moving either. If you import a small origin "marker" file using Auto - Origin to Origin you'll find that it lands at the Project Base Point. Now if you move the Project Base Point (UNCLIPPED) you see that you can move the icon to another location but it still references the "file origin" (see image).

That approach works for a single building on site but is not very effective for multiple buildings on site. The approach I advocate where we create a site file that is coordinated with survey data and serves as the master coordinator for multiple buildings which are linked into this master site file is much more effective and versatile. Since this subject can be confusing enough I advocate using the same approach for any project so I can learn one technique and use it over and over, since it works for any project.

Revit 2014 Update Release 1

An update for Revit 2014 became available recently. It has been blogged and tweeted many times already but I chose to echo it now because I've encountered questions about it a few times this week. This applies to all Revit versions, Architecture, Structure, MEP and Revit (aka "one-box"...all Revit disciplines in a single Revit install). These are update links for each version:

Revit Architecture 2014
Revit Structure 2014
Revit MEP 2014
Revit 2014 (one-box, only available as part of BDS)

Families with Nested Families and MEP Connectors

While trading some emails with Aaron Maller recently he mentioned that he observed that he could create circuits for nested shared electrical families. I don't recall Autodesk publicly taking credit for adding or allowing this behavior but I find that it has been possible as far back as the 2012 release. I'd try earlier releases too but I don't have them installed anymore. Since I started preparing this post I've discussed it with Jose Fandos and he confirmed that it is possible in 2011 too.

I'm a bit frustrated because I thought I tried to explore this possibility a couple years ago while making some electrical content. Rather than dwell on what I thought wasn't possible I'll focus on what IS possible instead.

Experience tells us there are many components that have a variety of options or configurations that can prove difficult to include connectors in, for example a boiler with its electrical panel available either on the right side OR the left side. When a single connector is placed we are inclined to placing it in the "middle" so we can "connect" it to a power supply. That's easier to accept for electrical connections but not as easy for piping or duct.

When the connectors are native, placed directly in a family, it isn't possible to put two connectors in place but disable one or the other. Revit sees both even if we only use one of them in the project. With two connectors in the model we can define where connections take place more accurately but ultimately we end up with one valid connector (connected) and another lurking as "unassigned" within the system browser. It might not a big deal but Revit's developers encourage to assign everything to systems so this approach means there will always be some we can't assign properly.

If the connector is part of a nested shared family and this nested family is assigned a Yes/No parameter to control its Visible parameter we gain control over not only when it is visible but also whether or not Revit sees a valid connector in the host family when it is loaded into a project. This is a crude example with connectors for pipe, electrical and data circuits, offering a conceptual right and left configuration.

When I use a yes/no parameter to control the visibility of the nested families it is interesting to find that the system browser responds to their condition. As can be expected Revit will delete a circuit or system associated with a nested connector if we choose to turn it off.

So far I find that I can create systems, connect pipe and duct, draw wires as well as tag the nested shared families. This means that it may be a bit easier now to define a component that has multiple circuits. This can help counter the limitation that a family can only report circuit information (in a tag) for the primary connector when multiple connectors are in a family.

It isn't perfect...naturally.

Nested families with connectors are harder to see and therefore are harder work with. The connectors are only visible when you hover over the location where they are when you are using the appropriate tool, like duct, pipe or wire. That also means we can't use the convenient right click "create pipe/duct/wire" options because we can't see the connectors.

It may also confront us with a need for sub-categories for connector geometry, not for the connectors themselves but any forms we use to host them. It can be easier to find the connectors if we can see the hosting forms but we may not want to see them in every kind of view.

Ultimately I think it's worth exploring further. Perhaps you'll agree?

Schedule Linked Files

We can schedule elements that are in linked files but there isn't a schedule that is only interested in telling us what linked files there are. We can determine which files are linked easily enough while working inside Revit. What if we want to document what files are linked into our model and include this information on a sheet? We can take advantage of the addition of Grids and Levels as elements we can schedule in Revit 2014.

If we assume that all projects will have levels and probably grids a schedule that is assigned to one of those categories can be manipulated to look like it is just a schedule of linked files. Then we can combine that with a Starting View if we want to see it each time our project is opened. Add the schedule to a general information sheet and it can be part of our documentation too.

I created a schedule that includes the fields for RVT Links and at least one for Grids. In this example I used Grids to drive the schedule but Levels are probably a better choice.

When we load a linked file we can supply a unique "Name" value. When we use Reload From or Reload later to update the model we can revise the "Name" parameter to show the current version/date.

Make a custom titleblock family and add the Project and Client related parameters as desired. Load the family and create a new sheet using this special titleblock. Add the new schedule to the sheet. To use this as a starting view activate the Manage ribbon and click the Starting View button. Choose our special sheet view as the starting view.

I used the Clear Cell tool, new in Revit 2014, to remove the link between the schedule name and the header text. This allows us to call the schedule something meaningful in the project browser and show something else in the header of the schedule on the sheet, as shown in the first image in the post. Since schedules can be on any number of sheets it is an easy matter to place it on additional sheets if desired.

A Doors Life

As I mentioned in an earlier post I presented a session called "A Door's Life" at the recent Central States Revit Workshop. It tackles creating a host door family that nests 2 panels, 2 frames and 2 handles. It also features a nested clearance form for clash detection and a variable plan swing angle. The host door permits rotating the 3D panel and hardware to any angle as well, though 0-180 is probably the range that's most useful.

If you are interested in more information this is the handout that attendees received (embedded here).

As the handout will tell you it isn't meant to be the perfect door. It's a demonstration of concepts and how to put them all together. If you're lucky you'll end up with something you can use right away or at the very least have a good idea how to get where you want to go.

Click to Download the completed files for each exercise.

Hiding Columns in Schedules

We can hide a column if necessary. Hopefully that's not a surprise. Each field in a schedule has a parameter called Hidden Field, available when we are looking at the Formatting tab in the Schedule Properties dialog.

We can also right click on a column while editing a schedule, in a schedule view, and choose Hide Column.

We can use right click to Unhide All Columns but it will reset them all, as the name implies.

If we use this on more than one column and only want to restore one of several we need to return to the schedule properties dialog and the formatting tab to uncheck the Hidden Field parameter.

Transfer Project Standards and Shared Coordinates

These two are not friends. They are even less friendly when worksets are involved. In earlier releases the project base point and survey point were assigned to Workset1 (2012 and older). In a post some time ago I mentioned a support issue that IDEATE's techs encountered where a user assigned them to a different workset and eventually deleted that workst. It resulted in unpleasant crashing.

If you look closely in 2013 and 2014 you'll find they are assigned to a workset called Project Info and we can't change that anymore.

Unfortunately the more mundane information like the project name, number, issue date, client name and address and many more are also Project Info.

When we use Transfer Project Standards hoping to share the same mundane project info with related linked project files (seems a reasonable expectation) Revit wants to transfer project base point and survey point information too. You'll get this dialog when you fire up Transfer Project Standards (TPS).

This is what my dummy project looks like before using TPS, note the Survey Point's coordinate values and position.

Here's what it looks like after TPS is done. The project base point and survey point have reversed their orientation to one another and they are very far apart now (I zoomed in closer though), far enough that the walls are tiny and hiding under the project base point icon.

If two files are already sharing coordinates they aren't immune to this "feature" either. In my testing I find that the coordinates still get messed up if I use Transfer Project Standards and Overwrite in order to pass along the other project information. It appears that the safest thing to do once Shared Coordinates are established is... DON'T Transfer Project Standards AND leave Project Info selected.

I think that the Project Base Point and Survey Point should be more isolated so they have their own Project Setting based workset, not shared with other Project Info. I'm glad they made it harder (impossible) to reassign them to a different workset to eliminate the other problem I mentioned earlier but they've introduced a new quirk as a result.

I find it mildly amusing that Transfer Project Standards acronym is TPS...reports anyone?

Linked Ceiling Hosted Light Fixtures and MEP

A ceiling hosted light fixture can cut the host ceiling. When an architect uses one of these fixtures the ceiling surface the Revit MEP user has to work with actually has a "hole" in it. This means that they can't put their own light fixture in the same spot because there is no ceiling there.

Technically that's an oversimplification. We CAN put a fixture in the same location but there isn't a face for Revit to detect easily. If you try to use the Downlight - Recessed Can family it's origin is too far from a ceiling's grid pattern to let us put it within a tile. We can put it in randomly and then move it to the correct location. We'll get yelled at though, the light isn't properly hosted now.

If we do the same sort of thing with the troffer family (2x4 fixture) it will be a bit more tolerant as well as not losing its face association.

This sort of discipline collaboration isn't tons of fun.

Drafting Views have an Origin

When we create a new drafting view we are presented with an empty view. We are free to begin our drafting exercise anywhere we see fit. It's not obvious but there IS an origin in the view. If we import a simple CAD file that has some lines that define where the 0,0,0 origin is we'll find out exactly where the origin is in the drafting view (use Auto-Origin to Origin).

What does it matter? It may not matter at all. I've often wondered about it since Revit cares about keeping us near the origin of the file for our model views and complains when we import external files that are very far from origin or very very large.

As such I can't help but wonder if we ought to be careful to keep our details near the origin of drafting views too. I have encountered drafting views that have their contents very very far from the origin. It's easy to do, just zoom out a bit and start detailing. It just seems inconsistent with the best practice expectations for model views.

I'm inclined to create a "template" drafting view in a project template to begin drafting views with (duplicate them) with the origin clearly marked, like shown above. I'd welcome someone from the factory chiming in to say this is a good idea or unnecessary.

Revit Server Documents

If you visit the wikihelp site for Autodesk Revit Server you'll find (if you look closely) these documents are available for your use/review.

Bandwidth Requirements for Revit Server
Cost-Effective Revit Server Deployments
Locking and Worksharing in Revit Server
Revit Server 2012
Revit Server and Riverbed Steelhead
Understanding Revit Server
User of Revit Server on High Latency Networks

Revit MEP Circuiting

I created a short video that describes the basic interaction between electrical devices and creating a circuit. It's really meant to help explain what happens when a device is already assigned to a circuit and we select it along with other elements that aren't circuited. The ribbon changes based on our selection and a circuited devices impairs our ability to create a circuit for the other devices that are eligible to create one.

• A device that is not part of a circuit, when selected by itself, will cause the Power button to appear
• A device that is part of a circuit, when selected by itself, will display the additional Electrical Circuit tab
• Multiple devices that are both part of a circuit and not part of circuit will only display the context ribbon relevant for the devices, no circuit tab or power button
• Selecting multiple devices that are assigned different electrical requirements will disable the Power button

When we select devices we need to be sure to glance at the ribbon for clues. Here's a video (no audio, turn on Captions).

I also wrote an earlier post about circuits if you're interested.

Quirky Roof - Roofing Around

A recent thread at the Revitforum.org asked about this roof form.

Don't worry about the dimensions. I used them to make sure a roof would work if I was "careful". I later messed around with it a bit to see if I could reproduce the error the original poster described, like this.

The other day I was discussing roofs with someone and I brought this situation up. I used the arrow keys to nudge walls around and thought the result was worthy of a quick video to demonstrate how different proportions affect the roof outcome. It's certainly quirky, maybe even "buggy"?

Light Fixture Grid Positioning and Wires

I've seen some lighting content that has been modified to make it easier to align with acoustical ceiling tile grid patterns. For example this stock family is the Downlight-Recessed Can.rfa with some reference planes added so we can snap to the grid during placement, or use the Align tool easily afterward.

I didn't bother to assign any parameters to control them. I can use them to fit the fixture in a 2x2 grid or use the Align tool later to position it in the middle of a 2x4 grid. It might not be obvious but I can use one reference in a family to move the family over by selecting another part of the family as my second pick. This means it is easy to just set the reference planes at a fixed position and use the family's own references to move it over if necessary. It just means I don't have to have parameters to decide if the fixture is meant for a 2x2 or 2x4 grid. All this is seems good at first except when it comes time to add wiring to the fixtures.

These helpful reference planes end up affecting where the wire's graphical ends terminate. The fixtures are connected to their wire but they just stop at the extents defined by the reference planes. Not fun when you have to adjust a lot of wires to get closer to the fixture. This means Reference Planes aren't ideal for this task. This is what the family looks like if I use Reference LINES instead.

I've held the same attitude toward adding dimensions in this example too, with much better results as well! We can set the reference lines to Strong (IsReference) and uncheck the Visible parameter. They won't be visible when you select the family but the Align tool will "see" them and Revit will highlight the ceiling grid pattern when you place the fixture too. Fwiw, if you leave it checked they still won't be visible when you select the family.

Fwiw, Model and Symbolic Lines that are Strong References and assigned to Invisible Lines provide the same result. You can uncheck the Visible parameter so they aren't visible when you select the family.

(This is based on working in 2014, it does not work in 2012 or 2013. Nothing seems to resolve it in those versions)

View References

You may recall earlier post about this relatively new feature? I also mentioned how the 2014 Sample Project file uses them. Hopefully you've found them useful in your projects by now. This post is how I imagine they could expand on the concept.

It's a common situation to need to refer to common details within the context of a schedule, like this.

I think we'd need a new Type of Parameter called View Reference. We'd pick it from the list when we add a parameter to a schedule.

I imagine the schedule interface getting this addition when we click in a field that has the view reference type of parameter assigned.

My goal is to tie a detail view reference to an actual view so that such information is really connected together logically. It doesn't really matter to me if the end result looks like what I've mocked up as long as the end result is better integration of the information.

Workaround Alert!

In the meantime, one way to deal with this issue (without my wish being granted) is to use schedule keys. Start by creating a schedule key(s) for each detail type that needs a reference. It may require additional parameters. It sure would be nice if we could use Shared Parameters for them too, but that's another wish list item.

We fill out the key with all of the detail reference combinations we will have. In a door schedule we can choose each detail for each condition from those listed in the key. Not hard and a bit more reliable than typing them manually for each door. At least this way we are picking from a prepared list.

Technically if we've entered one value for each detail reference we can just pick from the previous entries without the schedule key. That's not really the problem, just one aspect of it. It's the need to update all of the detail references if something changes to the sheet numbering or detail numbering on the sheet, for every instance it's been applied to a door.

Well, may wishes come true?!!?

Search the Project Browser

Just a little reminder, don't forget you can search the Project Browser!! Forget what you named a family exactly? No problem just search for what you do remember! The hardest part is remember you can search it! It's just a little right click away.