Reference Planes without Names

It is a common practice to add a name to the reference planes we create. If it isn't common where you work then it ought to be. The name helps give a hint to anyone that works in the model that this reference plane is more important than those without a name. It can also help understand what it is for, why it was made.

There are some who make the effort to clear out reference planes that are not named periodically, just another of any number of model/housekeeping chores. I've even seen Dynamo scripts intended for this task.

If you're using Ideate's Explorer you'll find it easy to see a summary of all the reference planes in the model. In the following image I've created two reference planes, one with a name and another without a name.

Notice that there are five (5) reference planes listed though. As it happens, when the Edit Profile concept is used on a wall four reference planes are created and internally applied against the sketch of the wall. They are only visible to us while editing the wall's profile sketch. We can't see these reference planes in the regular user interface, it only becomes very apparent with their Explorer tool.

It is also possible for us to create reference planes while creating any sketch based element, like a floor or stair for example. These reference planes are only visible to us while editing their related sketch.

The reference planes associated with a wall's edited profile can't be deleted via IDEATE Explorer. It can delete them when we've created our own within a wall's profile and other sketch based elements.

Attempting to clean up these unnamed reference planes might also be an issue if you're writing your own code or Dynamo script to delete them. We can/could add names to these internal reference planes (wall profile) but I don't think that's a task that worth the effort.

Something to keep in mind.

Filter Dialog and Reading a Long Filter Name

Dialog stretchiness has been an ongoing long standing user wish for all dialogs. Daniel wrote to me hoping that I'd echo his complaint about the Filter dialog. Yes you can stretch it but the frames remain less so. The Filter name frame does add a scroll bar at the bottom when a filter name exceeds the width of the frame, which does not increase in size when the overall host dialog stretches out. Ideally we'd be able to stretch/adjust individual sections of such dialog boxes. If memory serves that is dependent upon which GUI tools are being used to generate the dialog. If that tool set doesn't do it then...we don't get it...without a custom entity.

Daniel was writing about Revit 2019. Even when you scroll over to the right completely a filter with a long name gets truncated and you can't read all of the name.

I note that in Revit 2020 a tooltip will appear that displays the full name while the frame does the same truncating even when it has been scrolled completely to the right.

Naturally, we can avoid it if we can use Filter names that are not very long, an easy fix...there's that word again - easy. Easier said than done...it seems.

The Family has been Renamed

This warning message is probably familiar, troublesome and annoying.

I was reading a couple threads at RFO; THIS ONE and THAT ONE.

Apart from workset related issues I've written about before, I believe the underlying cause of renaming is that Revit perceives a family as different. That's not very surprising but I think that the actual difference is the result of different versions (2016 vs 2017) or having Save As used on the family (to put it in a different folder)...AND any operation that involves Copy/Paste, which includes the Insert from File tools.

When Load from Library > Load Family is used I only see it occur when worksets are being used (see the links at end of this post). The families merely having some different parameters (either instance or type) generates the dialog asking how we want to deal with the existing definition.

Using Revit 2017.1 and passing a family from one project to another I observed the following:

Family is renamed but no warning message:
If the family being introduced is an older version (upgraded) of one already in the model
If the family is same version but has had Save As used on it, i.e., to put it in a new folder location

Family is renamed and the warning appears:
If the family is an older version or Save As version AND Insert from File is used

Family is not renamed:
If the Family is copied from same library folder to a new folder
If the Family is from the same library folder
If the Family (existing) is reloaded from older version before using Copy/Paste or Insert from File.

The issue can be avoided if we are meticulous about using families from the same library and version. If we load office details from a detail library project file using Insert from File and the families (some or all) involved are based on older versions while newer versions are already present in the project we'll incur the renaming penalty.

The detail library should be updated, have the newer versions loaded first so they will be the same as those in the active project. If we need to keep the detail library in more than one version then we'll have to decide how to manage that and for how long. Merely upgrading the detail library model does not appear to be sufficient to avoid the issue.

I ought to mention that I can load a family and let it upgrade. Then if I use Copy/Paste to pass it along to another project file it does not get renamed unless the existing family in that project is based on a different version than the one I just upgraded. Upgrading a family does not seem to create the same problem that using Save As does for a family, at least not in the context of Revit treating it as a rogue family competing for the same name/existence in the project.

Regarding the workset issue I wrote three posts about previously, they describe how families can get renamed when worksets are being used and more than one person loads the same families and synchronizes their work in a specific way. The posts are:

FIRST post
SECOND post
THIRD post (references the first two as well)

Revit 2017 - Space Naming Utility Update - It is Available Now

The other day I poked Autodesk about this feature. As it turns out it is deployed slightly more automatically. The catch is that the latest iteration of Autodesk Desktop Application (I'm going to call it AdA) must be used to see these updates.

My first problem was that AdA wasn't working. It just displayed a blank white screen. I also noticed that there was no Autodesk (A icon) in the system tray for an active service. Eventually I used the wisdom of The IT Crowd; turned it off and on again. That restarted the service and AdA started working, displaying information.

The second problem was there were no updates to choose from. I logged out of A360 and closed its system tray instance. I also logged out of A360 via Revit, since I had it open. I closed the instance of AdA in the system tray too. I had a browser open looking at my Manage portal. I thought that maybe my access settings were wrong. I logged out and closed the browser too. Then I logged back into A360 and launched AdA...voila, updates appeared. It made no difference earlier that I used the right-click Check for New Updates option for AdA in the system tray repeatedly.

Once I got it working again this appeared in AdA.

This a tiny bit better.

People will still have to pay attention to be alerted to download and install it. If they don't have enough control over their computer they'll still have to get EyeTee involved. I'll have to see if I notice more people have it installed in the coming months.

Once it has been downloaded and installed you don't have to rely on AdA to pass it along to others in the office though. You can just capture the downloaded installation file from the location defined when you downloaded and installed it the first time (C:\Autodesk by default).

It is also a bit tedious that every one of the updates is a separate installation; must be run and completed before starting another. If you attempt to run them while another is running you'll run into messages about something already being in process.

By the way, when you run Revit after installing all the available updates you may be greeted by "Security - Unsigned Add-in" warnings. Nice...

I've got my Space Naming Utility! Do you? I hope so!

...and thanks to Paul Aubin for the heads up!

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...

Create View Template - Tool Description

Oh so...subtle...

The command via the ribbon is called Create Template from Current View.

The right-click context menu offers this version of the command instead (Create View Template From View).

It's subtle because the right-click version is based on the fact that we've selected a view and used right-click. The context doesn't demand using the language Current View because it's based on the view we selected in the first place. The ribbon version leaves out the word View because it is listed as part of the View Templates button already. It also declares that it will create the template based on the Current View since it is possible to have accidentally changed which view has focus prior to using the command; for example if views are tiled or cascading in the drawing window.

My initial reaction was that they were inconsistent and wrong to use a different description for a command that will produce the same result. After mulling it over I think it is a reasonable subtlety since their use is different and the phrasing is intended to help us know what to expect in each situation.

Matching Workset Naming with Linked File Worksets

I wrote about a workset tip/trick that describes how we can use consistent workset names between linked file to manage which elements should be visible/open more easily.

In the last couple release there's been a subtle issue between what we see in the Workset dialog versus Manage Worksets access through the Manage Links dialog or via right click > Manage Links (selecting a link in the Project Browser).

The technique still works as described before...almost. What is different now is how Revit responds when you open the Workset Dialog. You'll get the behavior we expect if we use the Manage Worksets button in the Manage Links dialog or right click on a linked file in the Project Browser and choose Manage Worksets.

The images below show the Open status for the same linked file according to the route used to gain access to the workset info. I've closed the workset Grids - A using Manage Links > Manage Worksets.

The Workset dialog doesn't seem to realize I did that.

The short story is we need to use Manage Links to alter the status, not the Worksets dialog...seems a bit buggy/quirky to me.

Naming a Reference Plane

I read recently that just adding a name to a reference plane would cause it to be "strong". The notion of Strong, Weak and Not a Reference are related to the IsReference parameter, which I've written about before. It's my observation that adding a name to a reference plane has no impact on it's behavior in a project. To test my belief I created a small family with a collection of reference planes with various combinations of Name and IsReference parameter values.

The reference plane on the far right is set to Not a Reference and has the Name No 3. Its the only one that is invisible in the project environment. The two on the far left have IsReference values (Weak and Strong) but have no Name either, they still are detectable in the project. I sketched dashed lines from the detectable ends of the reference planes. The dashed line on the far right is sketched where the reference plane should be but I couldn't snap to the end because it isn't detectable there. I also added a dimension string across each detectable reference plane.

I think my beliefs are intact, just adding a name to a reference plane does not alter its IsReference conduct in a project. When we create a new reference plane Revit assigns Weak Reference to its IsReference parameter. If we copy a reference plane, those that Revit lets us copy, it also assign Weak Reference to the copy.

Copy Monitor and Name Changing

I use the monitor part of Copy/Monitor to create a relationship between my existing levels and levels in a linked model. There is no need to use Copy because I've already got a couple levels to work with. In this scenario I'm using Revit MEP and linking an architectural model. I'd like my level name to match the architects. If you use Monitor first and then decide to make your level names match the linked levels you'll get a message like this.

Revit isn't really evaluating or comparing the names. If it was it would realize that I just changed it to match the monitored level. Instead it's just reacting to the fact that the name (my level's name in my file) is now different.

Moral of the story is, if you intend to use the same names it is best to change them before you start using monitoring. If you don't then you'll need to stop monitoring, change the name and then restore the monitoring.

Schedule Name and Header

A few years ago (Aug 08) I wrote a post that explained how to break the relationship between a schedule's name and its header. With Revit 2014 that approach is no longer necessary. I can just use the new Clear Cell button on the header text.

Now the schedule header can be something else and the name we see in the Project Browser can be something else. If you rename a schedule the header will match that name at first, or vice versa. If you click in the Header cell, click Clear Cell and the value is removed but the view name is not. Now put the name you really want in and you can alter either without affecting the other.

We can't use Project Browser organization on schedule views yet but we can control the naming a bit more easily now with this technique.

Revit MEP 2014 Space Naming Utility

This is still a separate download and installation but it is available now from the subscription center.

Why should it be part of the software?

Essential Tool - It is impractical to manage the relationship between architecture and engineering models without it. Many of the other extensions that are available (2014 versions available now too) are idiosyncratic, a small percentage of users will tend to use them. I don't think this one is. The fact that several other companies offer similar solutions as add-ons suggest that this one is at least solid enough for general use.

Development Plans - The utility has gone unchanged essentially since its inception. If it has been kept separate because they are going to do something else really wonderful and make it irrelevant, they've had years to do it. Until it really is part of the next release planning, put the one that works in.

Awareness -  Many people don't know it is available, because it is hiding at the subscription center, and therefore just suffer with room/space management. Most users I meet don't have access to the subscription site let alone know of its existence. Even when it is installed it is not in an obvious place so users who haven't been told about it either stumble on to it or don't use it until someone does point it out.

Complaint Dept. - If it remains an extension because of the fear that users will complain that they've "lost" one of their extensions...well... I sure hope that's not a reason.

I say put it on the Analyze Tab with the other Space tools, call it Space/Room Matching, like this:

Just do it!

Family Type as Type Catalog Flag

I don't see this technique used much but it is a pretty good way to let a user know that a family is supposed to be loaded with a Type Catalog. I was reminded of this by a thread at the RevitForum.org which also pointed to another thread at AUGI.

It's easy, create one "default" type in a family that uses a Type Catalog but instead of "default" use a more descriptive name like, "Family Is Not Loaded Correctly" or "This Family Uses a Type Catalog" or "You Should find the Type Catalog"... get the idea?

When you gaze over a list of families in the project browser you'll see that a family was loaded at least once without the type catalog because your "default" special name will be among the types listed there.

Reusing the Same Grid Names

A reader saw a post by Brok on the HOK BIM Solutions blog and he wrote to me about this tip. His name is Mr. Smith, yeah uh that's his name, Mr. Smith... Well anyway the tip is this. We can use the right click option to insert unicode control character when editing the grid name parameter.

If we choose one it won't print but it will make Revit think that this grid #1 is different from this other grid #1. Pretty sneaky.

Mr. Smith's name has been changed to Mr. Jones to protect Mr. Smith.

P.S. My 2014 prediction is still that Revit will still be called Revit.

Hosted or Not Hosted

The description "hosted" or "not-hosted" that we use for component families can be a bit confusing. Technically ALL families ARE hosted. They are either hosted by a level, a wall, a ceiling, a floor or a face (surface of some element). When we say not-hosted or non-hosted we generally mean that a family is not specifically associated with a certain host element like a wall, ceiling, floor or face. A chair, desk and various other families across many categories are "not-hosted" though truly they ARE hosted by a Level. They can sit on the floor or are free to be above or below it by altering their Offset parameter.

I often think that it is a disservice to spend time calling them just one or the other. It seems more explicit to use a family name that describes what host is required. A family called, "MyCoolFamily-hosted.rfa" might be better called "MyCoolFamily-Face.rfa" or "MyCoolFamily-Wall.rfa" or "MyCoolFamily-Level.rfa". We could reduce it to a single letter designation. For example the families could be named "MyCoolFamily-W.rfa" or "MyCoolFamily-L.rfa". What if the file extension allowed for this subtlety so the names are not affected by it? Extensions for families could be .RFF, .RFW, .RFC, RFF... Uh oh floor and face both are "F"...so we could use S for surface instead of face?

These different placement methods also mean we have to be careful to consider what sort of hosting nature a family has before we start placing it. We have to resort to reading the family name and/or glancing at the ribbon for any placement options to figure out what the family expects us to do. It would be great if a family could be assigned to a primary placement option. For example, light fixtures usually want to attach to a face, not the vertical face option we are offered by default. Ideally we could specify the hosting priority for each family and use the ribbon only to choose an alternative when those rarer situations happen. Maybe the ideal spot for this parameter is in the Family Category and Parameters dialog, like OmniClass and other settings..

Just writing out loud...

Illegal Parameter Names

It is fairly well understood that we can, but should not, use characters in parameter names that compete with Revit's own calculations. These include the addition (+), subtraction (-), multiplication (*) and division (/) symbols to name a few.

We also need to be careful to not use the specific function names either such IF. IF is the same as iF or If as far as Revit is concerned, though normally it is case sensitive.

When creating parameters use names that are not going to confuse Revit's own mathematical and conditional functions.

Family Naming - Don't Worry

Jose Fandos of Andekan posted again in his continuing theme of content related posts. He suggests that worrying about a family naming standard, an all-encompassing one at least, isn't our biggest priority. I agree, I've always preached consistency instead of specifics. Every firm I've met over the years has their own position about file and folder naming for every kind of software they use.

He (Jose) predicts that how we find content in and out of Revit will only get better as we move forward so the actual name of a Revit family may become less important as a means to find one. For example, the add-in Family Browser allows us to organize content logically and the name isn't really the focus (while it, a standard, does help organize the folder the content is in perhaps).

If by some chance everybody could agree on a standard strategy it wouldn't hurt us. I don't think it is a fundamental or major priority over actually having content created. If it gets made with a "bad" name, I can always rename it when it hits "my" library anyway. ;)

No Math Characters in Parameter Names

I've mentioned this before in the context of older posts but never in a dedicated post. Don't use characters that Revit respects as mathematical symbols in the parameters names you create. That means don't do things like this.

Revit will be nice and accept parameter names that include most if not all of them but when it comes time to do something more clever with the parameters you'll regret it. More clevererer? Like using the parameters in a formula, that's clever! You'll get messages like this one.

Easy to resolve, just don't use mathematical symbols in parameter names.

Dept. of Flashback - Mark and Type Mark

This subject pops up now and then as I encounter people doing the implementation "thing". I wrote this little piece in March 2009. I've clipped it out and posted it here again:

...snip
Language...with Revit's parameter naming the follow is true:

Door Number = "Mark" (not the person but the signature, ID or identifying "mark")
Window "type" = "Type Mark"

Out of the box, Revit's tags are assigned to these as described above. A door number is unique for each door so its tag is using a label assigned to the "Mark" parameter. Windows, for the most part, are defined according to a "type", a common letter or number designation for each window of a given "type" or configuration, therefore a window's tag is assigned to the "Type Mark" parameter.

"Mark" is located in the Element properties dialog while "Type Mark" is located in the Type Properties dialog. Most of Revit elements have both. Some Mark values are automatically supplied based on the "last" value entered and many are not. Type Mark values are not supplied with the assumption that each project will have its own needs and will be defined accordingly.

If you don't approve of the out of the box setting, you can create your own tag so that you can properly identify an element according to your needs.
...snip

What's with the Year in the Name??

Revit 2010 released in 2009, Revit 2009 released in 2008 and so on. It boils down to this, Autodesk's fiscal year is currently 2010 so therefore is the software it makes. I guess it is kind-a-sort-a like the car industry, selling a 2009 model in the fall of 2008??

At least it is better than trying to make sense of the Revit compatibility between the previous naming scheme; Revit Building 9.0, Revit Structure 3.0 and Revit Systems 2.

Room Name - Full or Abbreviation

Sometimes a name is just too much, too long, it just doesn't fit in a room. The stock Name parameter for a room is easy, it's already there waiting for us to us. When we use abbreviations in this parameter we end up with some full names and some abbreviations. An abbreviation of "T." for Toilet might be fine on a plan view but it is less than stellar in a schedule. We could use another stock parameter like comments to store an abbreviation instead but that subverts its usefulness for actual comments.

Shared Parameters to the rescue!

I've written several posts about shared parameters in the past so I won't go into making them again in this post (see bottom). This is what you need to do to get a new parameter working in a project.

Create a shared parameter (called Abbreviation for example)

Create a room tag family that uses your shared parameter, save the Family and load the family into your project

Add a Project Parameter (Settings > Project Parameter) using your shared parameter too. Assign the parameter to the Room Category

Use the parameter in your rooms, set-up a schedule and tag your rooms with the appropriate tag.

This gives the best of both worlds. Supply abbreviations for names that are unruly and don't bother for reasonable names. A schedule will make it easy to define either and those that don't have abbreviations don't "need" them. Just make sure you use the correct tag to display the value you really want people to see.

I've posted a revised copy of my Egress Example project that contains a working example of the shared parameter, tag and schedule.

This post Shared Parameter File: A Little Clarification provides a full list of the posts I've made in the past on the subject of Shared Parameters.