Tuesday, January 26, 2016

Revit Extension and the Big Pause

I've noticed that when I start sketching walls in a new project that at the third segment Revit decides it needs to PAUSE before continuing. It seems it has something to do with having Revit Extensions installed. It thinks needs to add some parameters and interrupts my sketching to do that. Bill (Mr. BIM Thoughts) helped point me toward this bugger the other day when were discussing a few workstations that were pausing to install/update the extension...much worse pause.

If you experience this too...might be the same situation for you.

Monday, January 25, 2016

Revit Version Build Update and Service Pack Naming

Bill (Mr. BIM Thoughts) shared this subtle bugger with me the other day.


Oooh boy... so Revit 2016 R2 is called Update3 behind the scenes if you look at the Control Panel\Programs\Programs and Features > View Installed Updates and Revit 2016 R2's update is called Update 1 for R2...

Phew...just when I think I understand the naming...

Wednesday, January 20, 2016

Worksharing - Loading Content Part 2

In my previous post I recommended a point person be assigned to manage the loading of content for a team. That might sound like a beauracratic minded recommendation. Not me at all. It is more a matter of self preservation, wishing to avoid having to fix the resulting duplication before it becomes a bigger problem. As such there is a another minor measure we can take to help catch the issue when it occurs and fix it.

Always use Synchronize with Central (SwC) immediately after loading new families or types (or duplicating system family types). Don't place any instances.

If we can't get a single person to manage this loading then using SwC immediately afterward will increase the odds that a warning message will appear as soon as the transaction is completed. This does assume that we all develop this habit. If the warning appears than we need to examine the new family(ies) and or type(s) in the Project Browser and resolve the issue.

The goal is to avoid creating the duplicates and even more importantly using them in the project.

Thursday, January 14, 2016

Worksharing - Loading Content

I read Jason's post this morning and he describes a classic worksharing gotcha. Unfortunately he hasn't identified the true culprit. I'm referring to this part of his post specifically.
One of our most notorious examples is the infamous Break Line. Each drafting view we imported had a copy of the break line family. By the time anyone noticed, the project model had “Break Line (1)” through “Break Line (22)”.
What he describes is the result of worksharing and multiple users loading the same family in their own local files. Revit sees multiple versions of the same file being loaded from different local files (users) and seeks to protect them by renaming the other versions it encounters. We see this sort of message when it happens.


This error and situation is easy to replicate.
  • Two users open local files for the same project
  • Each user loads a new family and the same type
  • Each uses Synchronize with Central (SwC)
The first person to sync will be successful without an issue but the second person will receive a warning about the family being renamed. If this is repeated enough, and by enough users at the same time, we could end up with family22 like he described.

For example, if eight people all introduce the same new family to the project then by the time the last person uses SwC there will be eight versions of this family listed in the Project Browser. This is what the Project Browser looks like after just two users think they both need to load a new double door and type.


Jason's post is focused on cleaning up after oneself and it IS important but it is also important to manage the loading of content and harvested details. It is equally important that people understand why these extra versions show up in the first place. Each time someone uses Load Family or Insert from File they must reconcile the warnings that appear before anyone has a chance to begin using the wrong version of the families that are duplicated.

I think it is worth restating that the subtlety of this issue is that this only happens when more than one user is introducing the same new family to the project (via their Local Files).

Once the family is part of the project (defined in the Central File) Revit doesn't get confused anymore. Here's what happens when I introduce the Break Line family he mentioned to the project via two users. Keep in mind that there is no Break Line family defined in the Central File at the moment. Each user loads the family, into their Local File, unaware the other user is doing it too. The first person to use SwC is fine but the second user sees this message (I expanded the warning to see the family description).


When the first user uses Reload Latest or SwC they'll both be able to see this in the Project Browser, listed beneath Detail Items.


Subtlety compounded with yet another subtlety...if the family is already defined in the project (Central File) but a new TYPE is loaded by more than one user then we end up with this situation in the Project Browser.

How do we avoid this situation?

As soon as we think we need to load a new family or type...STOP.

Who (on our team) is responsible for ensuring the content we need is available to us? There ISN'T any ONE person assigned to this? There should be. All new content should be requested, requests sent to or asked of this person. That person can delegate the task.

The goal is to avoid the situation where more than one user is loading the same new content.

Only ONE person needs to load the family(ies)/type(s) and then use SwC to make it available to everyone else on the team (they use Reload Latest). We are working on the same project after all.

To close and return to what inspired my post, Jason went on to write that they've abandoned using Detail Components in their details because of this issue. Tragic. They (the detail families) aren't the problem; Revit's worksharing behavior and user habits are. I hope he'll revisit that decision.

Wednesday, January 13, 2016

Pre-Selection and Selection Color

I always change the default color that Revit uses for selected elements. I use Red.


The default setting is the same blue that is assigned to Pre-selection. I don't recall when that changed but somewhere in the fog of time it used to be assigned to red. I happen to like the visual confirmation, the difference between what is highlighted and what is selected. To each their own.

If you want to change it too: Application menu (Big R) > Options > Graphics page

Tuesday, January 12, 2016

Revit Version and Build History

Philip and Luke both mentioned this on their blogs so I'm just echoing their mentions of this recent development. Autodesk put together a list of versions and builds going back to Revit 2012.


It's important to keep everyone that works on the same Revit project(s) on the same version/build, perhaps this will help?

It was fun discussing (while talking to a friend on the phone) the version/build/service pack/update naming yesterday, he'd missed the recent Update Release 1 for 2016 R2...damn it gets confusing.

Monday, January 11, 2016

View Range Dialog

I hinted at this change when Revit Sunrise became available at the end of last summer. In 2016 R2, when you open the View Range dialog box and click the Show button this version will appear.


It's intended to provide more information about what the settings within View Range mean.

Fwiw, I still think this version would be better for View Range and Ceiling Plans.


Friday, January 08, 2016

Text Box Boundary Quirk

I read a thread at AUGI describing an issue where the Show Border option to create a box surrounding text fails to completely surround the text it contains. First, if you weren't aware of it, each Text type has a type parameter called Show Border.


The Show Border feature worked fine until I used the Underline override to put a line under the NOTES: heading. It also happens if I use any of the other overrides; Bold or Italic.

I created the following video to show what happened.



Seems easy enough to resolve, just use separate text for the heading. Unfortunately I found that Show Border fails to work properly if the text is altered later too. Just adding a new line to the text is enough to confuse the border/box. Sadly this means the concept of Show Border is fatally flawed...

Thursday, January 07, 2016

Revit MEP System Browser - Systems and Families

When you examine the information in the System Browser there are separate items for Systems and the Families that are related to them.


We can delete a System if necessary via a Right-Click.


Be careful though, you can also delete a family the same way!


Wednesday, January 06, 2016

Doors and a Sliver of a Room

Following on my post yesterday regarding Doors and Rooms, if you happen to have a room that is NOT at least 14 inches deep you will find that Revit is unwilling to report either its To Room or From Room parameter. If you've been reading this blog a long time you may remember a post I wrote which included a short video that mentions this issue?

A room like pictured below will work because it is 14" deep.


However the room pictured below won't be recognized and the corresponding parameters will be blank, in this case the To Room parameters.


If you are familiar with the Room Calculation Point (I call it RcP) feature it can be used to influence this issue.


Keep in mind it will also negatively affect which room you can regard as the To Room, if not for this door specifically any other doors that need the opposite behavior.

The Room Calculation Point (RcP) feature was added to doors to provide a way to change how the To Room assignment is controlled. Originally the To Room value for a door was (still is without the RcP being enabled) decided based on the side of the wall the door swings in toward.

There are doors which must swing out of a room but still belong to the room they swing from. For example a classroom's door (like shown in the images above) often swings outward to the corridor (often set into an alcove), for exiting requirements usually. However we still think of and document the door as belonging to the classroom, not the corridor.

If the door is placed so that the panel swings into the classroom (using stock doors) then the To Room parameter is assigned to the classroom. If we then flip its orientation so the panel swings out of the classroom the To Room value remains associated with the classroom (check out the post I mention above for a video of this behavior).

The RcP feature changes that behavior to alter the To Room value to follow the flip of the door orientation regardless, which means in my example, and the images above, the To Room value would change to reference the Corridor instead.

May you have sliverless designs...

Tuesday, January 05, 2016

Doors and Rooms and Rooms and Doors

In the year 2016 we find Revit is still utterly clueless about the relationship between doors and rooms. We have this quirky documentation habit of using a room's number to derive a door number, not to mention it's room name to define its location in a building. I know they've noticed because each door has a From Room and To Room parameter.

Recently Elon Musk and his SpaceX team sent a rocket to space and returned the first stage to an upright position back on earth. A feat engineers have long dreamed of accomplishing.

Yet after 15 years Revit continues to rely on third party applications to bridge this feature crevasse.

Don't get me started on the Space Naming Utility being a separate application...grumble grumble...