Panel Name - Allow Unique Values per Group

Some time ago they added the ability to tell Revit we want a parameter to be able to store unique values even when the element is part of a group, like this.

That example is possible because it's a shared parameter. I find myself wishing that we could do the same thing for the built-in Panel Name parameter for electrical panels. These are unique identifiers in all the situations I've ever encountered. Never mind the unfortunate poor support for being in groups to begin with...

I wish that Panel Name could be like a Door's Mark parameter or a Room's Number...unique even when included in groups. I wish upon a star...

Group Exclude Element and Rooms

We can use the Exclude Element feature on the parts of the model we assign to groups, like this for example (a workstation with chairs).

We can also include rooms in groups. Just be careful if you use Exclude Element on the room(s). If you do you'll see a hint of a room when you pre-select (highlight) the group but you won't find it among the rooms in a room schedule...because it/they is/are excluded.

A potential gotcha for users.

Group Editing and Ceiling Hosted Elements

Aaron Maller let me know about an unpleasant bug he's encountered in both Revit 2015 and 2016. If you're thinking, "Boy I'm glad I didn't listen to Steve's rant yesterday." Point taken... It's the exception though, not the rule.

Simple steps to reproduce the issue:

• Create a new project
• Create a ceiling
• Place at least two light fixtures (faced based or ceiling based)
• Create a Group (of the ceiling and both fixtures)
• Copy the Group to create several instances
• Edit the Group
• Swap or move one fixture
• Finish the Group

Where did the other fixture go? It (they) is (are) Excluded. If you select the Group you'll see Restore All Excluded appear on the ribbon. If you use that tool you'll find the fixture is no longer hosted by the ceiling though. It will report in it Host parameter.

If you'd like to avoid this issue then:

• Edit the Group
• Make the changes you need
• Select all the fixtures
• Nudge Up and Nudge Down to put them back in the same spot
• Finish the Group

The copies should be intact, no excluded elements.

I've also found that I can use Save Group, edit the Group in its own file and then use Reload to refresh the Group in the project. This doesn't seem to suffer from the same affliction. Take it slow if your project is using a lot of groups with ceilings. The issue doesn't seem to affect elements hosted to walls, not in the testing I've done so far at least.

Here's a video example of what happens and using Nudge to avoid it.

Restore All Excluded Intermittent Ribbon Button

This is an odd one, seeing it in 2014, 2015 and 2016...

Three of these four instances of a quad workstation Group have had Elements Excluded. The group has both possible seating positions included for each workstation and I can just exclude the one I don't need. When I select one group I get the Restore All Excluded button on the ribbon.

When I select two groups I don't get the Restore All Excluded button on the ribbon...sometimes. It's not there in this image but several times it did show up.

When I select three groups I get the Restore All Excluded button on the ribbon...again sometimes.

If it's any consolation, the right-click Restore All Excluded works everytime.

Here's a video...

Schedules can be in a Group

Alex at RFO mentioned in a thread that he has created a Group with schedules on sheets to help manage them when he needed them on more than one sheet. I wouldn't have thought it was even possible and I probably wouldn't have thought to try that even if it occurred to me.

Schedules that are on more than one sheet can end up in different locations so a Groups origin could make it a bit easier to ensure a schedule or schedules are arranged the same way from sheet to sheet.

Something to think about, hat tip to Alex!

Parameter Grouping

Consistency, CONSISTENCY, consistency...

This post is the result of noticing that families that were using a specific group for some parameters were not showing up in the correct group once they were added to a project.

When you create content the names you use for parameters is one thing to worry about. The Group you assign them to is yet another. We don't get much control over how we present parameters to our users, but Groups are one thing we do get some say about. We can even change them without starting over, compared with getting the parameter name or data type wrong.

If you'd like all your content to show the same grouping you'd better be consistent. Then again even if you are you may not get your way though. I should explain myself now?

Here's a parameter called "Mounting Elevation". It's neatly tucked away in the "Construction" group.

Curious about why I'm using Mounting Elevation when you can clearly see Default Elevation just above it? I can't tag something with the Default Elevation parameter (Data Devices in this situation), it's not among the parameters available in a tag family. I'm using a shared parameter for Mounting Elevation and "connecting the dots" with a formula that is equal to Default Elevation.

I loaded it into a project and all is well. A bit later I notice this. The parameter has wandered into a new group called "Dimensions". Hmmm...

I went back to the beginning, just like Vezzini told Inigo he should. I started with a blank project template and a single family. I added a shared parameter for "Mounting Height" and assigned it to the "Construction" group. Parameter showed up as expected. I went back to the family and tried to change the group to something else. Loaded back into the project, no respect...parameter still located under "Construction". Apparently once the project captured the group, it stuck, even if I change it in the family and reload it.

Next I tried adding a second family that used the same shared parameter but assigned to a different group, no change. Still assigned to the original group. Hmmm... So how did the parameter move?? I started to think that maybe I assigned the parameter to the other group originally and later decided to use "Construction" instead. That was so hours ago, don't really remember now. Just not sure anymore.

Let's mix it up a little with Project Parameters. When you use a shared parameter in your family Revit is kind enough to make them available in schedules without doing anything extra (except for titleblock families, they are a special case). I thought I'd try adding the same parameter to the project and assign it to the group I really wanted. Aaah... the parameter moved to the group I wanted!

If I edit the Project Parameter and change it again it moves to the new group. Well that's consistent at least.

Fire Protection probably isn't the best group to use though eh? My lesson learned from this fun is to think a bit harder about the groups I want to use earlier and to be really sure I'm happy with the setup before putting it in a real project. If I don't I'll either have to live with it or just add the parameter to the project too (which isn't really a hardship even if it isn't technically necessary).

Revit has a Wblock Feature Too?

Read a post a couple days ago that AutoCAD has WBLOCK to write information out to a new file. It went on to say that Revit does not. Technically true, no Wblock command. It got me thinking that the "Save as Group" feature however does much the same thing, select elements, create group, Application Menu > Save As > Group. This takes your selected items (the group) and writes them to a new .rvt (project) file. In essence the "same" thing as Wblock.

The subject of the post I read was about splitting a project up. The method advocated is to use Save As to create a separate project and then clean out everything you don't want to keep. The Save as Group approach could/would/should work too. Regardless the hard part isn't Save as...it's carefully filtering/selecting everything.

As you were...