Tuesday, October 18, 2016

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)

4 comments:

sarab said...

What would be a good workflow for this where you say "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.".
By the detail library, do you mean, the actual detail components library, or a standard details file?

Steve said...

Sarab - Sorry I forgot to reply to your questions.

It is tricky the more versions of Revit are actively being used on projects. The trick is to have as few families, that are reused constantly, being available to users from more than one place.

For example, Let's say I have families from 2014 but some of those are not in 2017 format yet. Our project is based on a 2016 template with a 2016 version of Break Line. A user will load a Break Line from 2014 and it will upgrade and be renamed to protect the existing family. Later someone gets a detail that has a 2017 version of Break Line and that new version will get renamed too.

Now we have three versions of the stock Autodesk Break Line family but they are called Break Line, Break Line1 and Break Line2. Each user places whichever one they can touch or see first. Now there are hundreds of each family in use. Very tedious to clean that up.

You can manage the risk out...some. You also need to teach every Revit user to fix it as soon as the error appears. That's the best time to reconcile the naming. Swap any instances of the new type that exist because of the new drafting view being added and before any of the renamed families get a chance to be used.

Detail Library: I mean a project file that contains all the standard drafting views a firm uses. Sometimes firms organize their library in separate files according to CSI or sorting logic that makes sense to their own needs.

Jaysyn said...

Steve, this is an old post but I have just recently tried to find out how to avoid this. One thing that you didn't suggest a solution to is what do you suggest we do to fix it in our detail library file? Do I simply reload all detail components to my detail project file from my latest library versions (Revit 2018) and then go through the process of changing the duplicately named files to the properly named original file. Then save my detail project and I shouldn't have the issue anymore if it is assumed no one bu I add details to my detail project file? Of course when I would add to it I would be very careful and fix any duplicates at the project level before inserting from file....

Steve said...

Jaysyn - I don't think there is a perfect scenario that will prevent it from ever happening. If you're detail library is maintained in an older version of Revit and the content it uses is the same as what people use in current projects in new details it might not occur much.

If people pull from current folders (per version) you'll likely run into it every time someone loads an older drafting view from a container/library project file. Detail Items that are used in many/all drafting views (like Break Line) are bound to cause issues eventually.

If people are aware of the meaning of the message at least they can choose to use the version that is already loaded in the project instead of the version that's been renamed. They do need to reassign the new rogue's to the project's version...if they're going to keep the inventory clean.

Good luck!