View Worksets

View worksets are created by Revit whenever a view is created. We don't need to do anything. When we add annotation to views they are assigned to the view workset. Using the library metaphor they are like shelves for annotation books (dimensions, detail lines and detail components, text, tags and symbols). Building elements like walls, doors and windows are associated with User Created Worksets and we do manage them. We don't manage View Worksets.

We don't have to deliberately borrow a view workset as a separate task either, it just occurs as we do things within an active view or to a view's properties. If we change a view's property, like Detail Level for example, we become a borrower of the view workset. If we move a tag in a view we borrow the annotation from the view workset. Revit evaluates our actions and responds with the necessary element borrowing.

It is reasonable to say that we can ignore View Worksets (also Families and Project Standards Worksets), as seen in the Worksets dialog. It is also technically true that we can make any of them editable deliberately, for example by using the workset dialog, but it isn't necessary because Revit lets us transparently borrow view properties and elements as we interact with them in our project.

It IS important to make sure we relinquish View Worksets (true for all worksets too) when we use Synchronize with central.

Workset Names

Via email I was asked,

"We are probably all familiar with names like Core, Shell; or Core-Wing1, Shell-Wing1 for example. We have been discussing using the Omni-class table 21 with 7 categories and 3 levels. For example a workset name would look like this: 01 10 00 Foundations. Would you agree with taking this approach?"

My fear, whenever we start talking about using coded naming, is that we are going to have too many worksets and create additional bureaucracy. I wrote a post called How Many Worksets do I Need. I described one warning sign as having to scroll the list of worksets.

I don't have any objection to being organized. I do caution against creating extra work for each of us by getting too granular with worksets. Using OmniClass numbering might work well if the highest levels are sufficiently distinct to be useful.

My measure is, "Are we are better off for taking the trouble to do it?" That's a vague answer I suppose. I know enough to know I don't know everything. That means there probably are projects that would benefit from using that approach.

I'd know it is the right choice if we are going to be better off afterward.

Open File Project Version Warning

I wrote a post in November that complained about Revit not asking if I really wanted to upgrade a project before going forward. In response Harry Mattison wrote some code (and I wrote another post) and made a solution available through his Udemy API class.

Since then I've used it so much that I've been starting to think it's part of Revit. I was using another computer the other day and was confused for moment when Revit didn't ask first, puzzled until I remembered..."oh, yeah...Harry's app isn't this computer". (sad face)

Well Harry has made a new version of the app available HERE and has decided to use a Pay What you Want approach as a test to see how well that works for him and us. You can read Harry's blog post and explanation of features HERE and here's his YouTube video.

Two Minutes with Rolling Offsets

Revit doesn't let us quickly create rolling offsets for piping or conduit, at least not in an uninterrupted process as we are sketching consecutive segments. In the past I wrote about a related concept called a Conduit Kick. It isn't that they don't want us to do it its just that Revit is biased toward creating vertical and horizontal runs. This means sketching a run of pipe and changing elevation usually creates something like this instead. The example on the left is good while the right is bad.

This video shows how to create a rolling offset for both pipe and conduit. The Routing Solutions tool works for pipe (and duct) but not conduit. We can also use the option Ignore Slope to Connect for pipe, duct and conduit. The resulting rolling offset does not abide by any rules for specific angles or slope. It's easy to create a sloping section between two elements as long as they are in the desired location, offset from one another correctly and at the elevations you need. The rolling offset just can't be created as we sketch from segment to segment. We need to place the two lateral runs and then return to create the rolling offset section.

Btw, there have been a few tweets on this subject focused on creating an app to help us cope with rolling offsets. Jeremy Tammik (The Building Coder) has written about it and wrapped up his posts with THIS ONE. Harry Mattison (Boost Your BIM) also inquired about it via Twitter but I don't think he's put anything to code about it yet.

Change a Family's Category

Most of the time we can change a family's category. We can open the family, click Family Category and Parameters and choose a different category.

An exception to the rule is when we attempt this with a family that is already assigned to the Structural Framing category. Revit will let us think we've succeeded until we try to use the family in a project or reload it.

The special Revityness of structural framing prevents this transition. If you've already loaded and created an instance of the family in a project Revit will generate an error and invite you to delete the family type(s). The moral of the story is "don't because you can't".

Scope Box Issues with Disciplines

When we assign a view to Mechanical, Electrical or Plumbing disciplines a Scope Box gets treated as an underlay element and its graphic display is also affected. This image is of a mechanical view and a scope box, only two sides of the box are visible (it's been like this since 2012 at least). Since it is regarded by Revit as an underlay element if I choose to disable the Select Underlay Elements option (new in 2014) I can't select the Scope Box either.

There isn't much we can do to counteract this graphic quirk except to deal with scope boxes in views where they aren't graphically harmed. Most of the time people want to hide scope boxes faster than a litter box when guest arrive. For offices that don't show a scope box in printed documentation it isn't an issue. If you really want to show it then it might be necessary to create an annotation symbol or detail component that you can use to compliment the Matchlines that are usually associated with scope boxes.

Keep in mind that each Scope Box has a Edit button for Views Visible (button is in the Properties Palette).

This dialog governs which views the scope box will be visible in or not. If you find you can't see a scope box in an elevation for example then double check these settings. You'll probably find that it is set to be invisible in the view.

As mentioned in the first line of the dialog in the image, Scope Boxes are automatically visible in 3D views and in other views where they (the scope box) intersect the view's cut plane. This changes dynamically, if the scope box is altered so it comes into contact with a view's cut plane it will change from Invisible to Visible without any additional effort on our part. We can use the dialog to force either condition to be persistent however.