Tags

, , ,

There’s an old joke in CAD Management circles that the wonderful thing about standards is that there are so many to choose from. (We laugh because it’s true.) For our firm, most of the time these are client-driven standards, which in turn are probably owner-driven. In these cases, we grumble, sigh, and then build templates to automate compliance as much as possible.

But what about internal standards? And, more specifically, what happens when they change?

I’m thinking about Revit families here — other kinds of standards will have to wait for another day.

To answer this problem, I went back to thinking about how we handled it in AutoCAD when a symbol changed or was added. Adding was easy. (“Here’s a new block.”) When we changed something, though, we had to think through how it would affect our projects in-progress. Was it worth updating them with the new block? (Maybe.) Was it worth updating our typical details? (Yes*.)

Taking this into Revit, I think the basics of the process are the same, but the challenge is multiplied due to the vast numbers of families and the various ways of accessing them.

But here’s how I think it can work:

  • If you need to update a family, go ahead and rename it. Don’t try to keep two versions hanging around. (At least not in the active folders. Backups are fine, of course.)
  • If needed, update your template so that new projects will use the new family. (This part’s kind of a no-brainer.)
  • Projects in-progress will continue to use the old family if it’s already been loaded. If you inadvertently load in the the new version, you should probably say “no” when asked, “Do you want to overwrite this family?”
  • If you need the new version in an existing project (and be honest, it’s probably why you updated the family in the first place), rename the existing family as zzOLD-family (or with your prefix/suffix of choice) and then load in the new family.

I’m in favor of the prefix method here because then all the zzOLD families will drop to the bottom of your project browser, where your users won’t be tempted to grab them when creating new instances. It’s also a pretty good visual clue if they do happen to select a superseded family.

Admittedly I haven’t put this into practice officially yet, but I think I’d like to. Am I missing anything?

(Back to the asterisk from above — updating typical details can be a huge chore. It needs to be done, though; otherwise you end up with old symbols perpetuating themselves through new projects. Maybe set aside a day a month for maintenance? I’ll have to think about that.)

Advertisements