Friday, December 19, 2014

Quick Tips - Disabled New Data Row Button and Pinned Element Selection

Two gotchas I've seen come up a few times lately.

Revit 2015 R2 provides a separate button for a new Data Row when we create a room, area or space (sheets too). It is disabled however when the schedule is not using the Itemize every instance option (un-checked). This means creating a new row might not be visible in the schedule, so it is disabled. I wrote a post about the new Data Row button when R2 became available.

Can't select something in your view? Did you pin it? Someone else pin it? Why do I ask? Because we can tell Revit we don't want to select Pinned Elements now. The trouble is we forget those settings easily and later we look clicking challenged when we repeatedly click on something and Revit ignores us. I previously wrote about the new since Revit 2014 Selection Options.

Thursday, December 18, 2014

Creating Elevation Views and Finish Floors

If you use the finish floor approach to create individual floors for rooms they manage to confuse the Elevation tool. If you create an elevation view inside a room you will likely find that the view's crop boundary is very short.

These are two interior elevations I made. The crop region for the one on the left is good but it's floor is flush with the sub-floor (and level). The crop region for the view on the right is bad, too short because the finish floor is set so that it sits on top of the sub-floor. Quirky quirky.

Raff, a member at RFO, started a thread the other day and it reminded me that I'd created the video below, embedded here.

The video is based on Revit 2015 R2 and Update Release 5 installed.

Wednesday, December 17, 2014

Revit 2015 R2 - Reveal Constraints

A new view override feature called Reveal Constraints is part of the subscription only R2 release for Revit 2015. It is intended to make it easier to see constraints that have been applied to the model but may have been obscurred in some way. For example it is possible to use a padlock on a dimension string and then delete the string, ignoring the warning message and clicking OK to accept it but retain the constraint. Clicking the sneaky little dimension string with a padlock icon on the View Control Shortcut bar reduces the model to gray/halftone and displays constraints in a burgundy color, like below where I've locked a couple dimension between Levels.

Even constraints that are related to elements within a sketch are displayed but they are also gray or halftone. You can double-click to edit the element, if you have that feature enabled, or edit the element and then remove the constraint(s).

I've embedded the following video, which you'll find within Autodesk's help documentation.

Tuesday, December 16, 2014

Gray Inactive Worksets

This feature is often overlooked but it can help ensure you are setting the Active Workset as you transistion between tasks. It is located on the Collaborate ribbon tab > Manage Collaboration panel and right underneath the Active Workset drop down list.

Let's say I need to start working on the interior partitions next. If I click to enable Gray Inactive Worksets it becomes more obvious that the exterior walls are still my focus.

If I change the Active Workset to Interiors then everything else becomes a light gray color instead.

Now all the interior work I do takes a visual priority compared to the rest of the model.

Such a simple yet easy to overlook feature, try to remember to take advantage of it.

Monday, December 15, 2014

Revit 2015 R2 - Perspective View Changes

It is not uncommon for a new Revit user, that is already familiar with Sketch Up for example, to be a bit surprised that we can't do routine modeling work while using a perspective view, called a camera view. I liken Revit to having been raised by parents with different beliefs than other software's parents have. In this instance Revit's parents didn't think it was necessary or important to let their kid model around in perspective views. Most users react to this as if they've just found out their friend's parents ground them for practically any infraction. How sad, your parents are tough!!

Good news on this front, 2015 R2 begins reducing this restriction!

The following are available in perspective views now:
  • Editing tools: Move, Align, Pin and Unpin
  • Reset Target tool: Restores the position of the camera target to the center of the field of view
  • Toggle between the perspective and parallel representations of the 3D view

Reset Target is a new button when the view's crop region (perspective views) is selected. It places the camera target back at the center of the crop region. It may be useful if the changes you made switching back and forth between view modes has altered the view in a confusing way.

Toggling between view modes is possible through the View Cube and right click. CLICK TO find out more about these enhancements.

The online help documentation specifically notes these items when switching from parallel to perspective view modes.
  • If you add elements to the parallel view that are not supported by a perspective view (such as annotations or displacement sets), and select to toggle to the perspective view, a dialog displays.
    You have the option of duplicating the view without the non-supported elements and opening the duplicate view in perspective.
  • The Toggle to Perspective 3D option is only available from the parallel view if the Crop Region Visible property is selected for the view.
  • Some modes are not supported in the perspective view. For example, if you are in Reveal Constraints mode in the parallel view, this mode is automatically closed when switching to perspective.
  • Changes made to the View Scale in the parallel view are reset when switching back to perspective.

It's not quite the 60's, the era of free modelling, but it's a start.

Saturday, December 13, 2014

Family Orientation

It is quite common to find the orientation of families confusing, both when we make them and when we attempt to place them in a project. What we consider front, back, left and right doesn't seem to follow consistent logic. Okay, there is some consistency it just seems opposite of what we might expect. What do most of us expect? Speaking for myself at least; Front is the bottom of a plan view, Back is the top of a plan view, Right and Left are the right and left sides of the plan view.

If we examine every family and family template in the stock content we'll find that Front IS at the bottom of every plan view in all of them. The View Cube also matches that convention. The thing that confuses us is that a portion of the stock content has been modelled in the reverse. That which we think of being the front of the object being modelled is the back. Even in those families however, upon closer inspection, we will find that the reference planes are oriented correctly (if they are named at all), the geometry orientation is wrong. The direction the geometry is facing is wrong.

If we consider a chair family most if not all of them are modelled with their front toward the top of the view (which is Back). If we compare that with a desk we'll find that it is modelled with the drawers (can we agree that they'd be the front?) toward the top of the view. These two families oriented this way don't allow the user to place a desk, horizontally for example, and then a chair horizontally so that they are oriented correctly with respect to one another. In the case of this desk there is no visible clue to know which way the desk is facing during placement. We'd be rich if we got a dollar every time we noticed the desk was backward when we open an elevation view later.

Looking at the View Cube the chair looks wrong, but only if we happen to agree the front of the chair is the side our legs are on. In the context of being placed next to a table or desk it means that the chair is facing the wrong side of the desk or vice versa. They had to pick an orientation but in the case of a desk that has drawers they picked wrong. Other work surfaces and tables might not matter nearly as much. It would make more sense to me if the desk were modelled with the drawers facing front, the bottom of the plan view. This would allow us to place a desk and chair and their orientation would make sense regarding each other.

Another apparent mismatch of orientation logic is base cabinet and wall/upper cabinet casework. Base cabinets are modelled with front facing the bottom of the plan view but the wall hosted upper cabinets are facing the back, the top of the plan view, opposite of base cabinets. Placing them in a project however defies the apparent orientation mismatch because the origin of the base cabinet is at the back and it is for the upper cabinet too. This means they orient logically when used together despite being modelled facing different directions in the family editor.

Also contributing to confusion is that the original content for doors and windows all assume that their Exterior side (and Placement Side) is what Revit considers the back side of the family. I've always thought of the exterior side as the Front of a door or window, the side that faces people as they approach the house. A door was the very first family I made with Revit. Afterward I believed that Front was the top of a plan view in the family editor. At least until I encountered enough other families to realize I was wrong.

To appear more consistent, while working in the Family Editor, Autodesk would need to revise most if not all of their hosted content (and others) so that the geometry orientation respects the bottom of a view being the Front view. The placement logic it uses must compensate for the placement side orientation of the geometry not being consistent with the notion of Front. If they revised the orientation of content to please Family Editors then they'd have to be careful to also revise the placement side logic.

Friday, December 12, 2014

Detailing and Circles

If using a Detail Line and drawing a circle Revit doesn't much care for attaching a dimension to the "side" of it, in this case it is a conduit, when they are sketched that way. We can sketch a short straight line segment and place a dimension that references that instead.

If we create and use Detail Items for 2D versions of real things then we'll find the dimensions more accommodating. The advantage of being a component is it can be re-used, provide a variety of sizes as types and they can be tagged. Lines have never been quite the equal to components in Revit's world. I do think it is a bit silly that the dimensions don't work on a detail line used to create a circle. We can only dimension the diameter, radius or from center to another element.

Thursday, December 11, 2014

New Canadian CISC Standard 9.2 Structural Shapes Available

If you rely on Canadian size structural shapes for your work then you'll wish you had a valid subscription if you don't. The Canadian Structural Content Extension for Autodesk® Revit® RST 2015 software provides the latest CISC standard 9.2 hot rolled structural steel shapes is available in the Subscription Center for you to download. This extends the current out-of-the-box content offering, reducing the need for users to seek alternative sources of content.

This was announced via the BIM & BEAM blog earlier today.

I have to admit my first reaction was that it ought to be available regardless of subscription status. I'd prefer that anybody using Revit Structure and relying on accurate structural shapes also has the latest shapes to use. If it is truly supplemental, as opposed to updating critical existing shapes, then perhaps it is a subscription benefit?

Wednesday, December 10, 2014

Revit 2015 R2 and Shaft Openings

Another subtle change within the new R2 release (only available to active subscription customs) affects Shaft Openings. These now assume a Base Constraint equal to the associated level of the view you create it in. They also changed the order of the parameters so they are the same as the parameters as other elements that have a Base Constraint, Base Offset, Top Constraint and Top Offset.

The settings we see above are the result of creating the shaft in the floor plan view for Level 1, before I extend it any higher. If you create a Shaft Opening in a 3D view it will assume the Base Constraint of the view's active work plane.

Tuesday, December 09, 2014

Guide Grid and Pin

We can assign a Guide Grid to sheets which provides a way to make sure selected views are lined up from one sheet to another. If you aren't familiar with this tool then have a look at this older post for an overview.

If we're concerned about someone moving the guide grid we can use the Pin tool to make it a little harder to move it accidentally. Then we can make it even harder if we un-check the Selection tool Select pinned elements.

Just keep in mind the Pin tool does not prevent the Guide Grid spacing from being changed. Methinks it should.

Monday, December 08, 2014

Autodesk Subscription Concepts Changing

If you were at Autodesk University last week (I wasn't) or at least watching the social media feed from the people you follow on Twitter, Facebook etc. you probably saw something about Autodesk changing how subscription will work in the future. This is anticipating more cloud based software use.

Scott Shepard shared (with Autodesk and blogger for "It's Alive in the Lab") a transcript of a Q&A session regarding what these changes are likely to mean to Autodesk's customers.

This is the text he shared within his blog post:

I (Scott Shepard) attended an internal Autodesk OnAir presentation where VP of Industry Strategy & Marketing, Andrew Anagnost, provided additional information. Here it is in question/answer form:

Q: What does "moving away from perpetual licenses" mean?
A: We will stop offering customers the option to purchase NEW perpetual licenses of Autodesk software. Customers will continue to have several other purchase options, including Desktop Subscription.

Q: Why are we making this change?
A: We are ahead of most of our competition in harnessing cloud and mobile to give customers superior user experiences and to provide more potential customers access to our products through lower prices for many of our products and term payments.

Q: What will be the impact on existing customers?
A: Customers who are on Autodesk Subscription will not be impacted by this change. Customers not on Autodesk Subscription will need to purchase Desktop Subscription to access the latest Autodesk software releases.

Q: What does this mean for customers on Maintenance Subscription?
A: Existing subscribers will continue to have the option to renew their Maintenance Subscription contracts and receive access to the latest Autodesk software releases and other Subscriber benefits. Any new software received as part of a maintenance contract will have perpetual license rights.

Q: What are we taking away?
A: The ability to buy NEW perpetual licenses.

Q: Does this mean customers will lose their perpetual rights?
A: No, if the customer previously bought a perpetual license in the past, that license doesn't go away.

Q: When will we stop offering perpetual licenses?
A: We anticipate it will be sometime in the next 12 to 24 months. Details will be shared as decisions are finalized.

He (Scott) then provided a few additional statements from the Autodesk PR team:

"We are aware of multiple conversations regarding Autodesk’s ongoing business model transformation and move to Subscription. In an effort to provide clarification, we would like to provide some specifics about changes in the sale of perpetual licenses."

"Over the next 12-24 months, Autodesk is planning to gradually discontinue sales of NEW perpetual licenses, and will make NEW seats of our software available through Desktop and Cloud Subscription only."

"Existing customers with perpetual seats will be able to continue using those products per the terms of those licenses. Customers with perpetual licenses that are current with Autodesk Subscription will continue to benefit from product updates and other benefits of Autodesk Subscription."

"We recognize that these changes will impact our customers and that you will have many questions. We plan to provide additional details about our plans as the information becomes available and will provide sufficient advance notice so you can plan for these changes."

Friday, December 05, 2014

Changing Column Types and Copy Monitor

Using Copy/Monitor Revit does not complain when we change column families or types. It does complain if the column is moved. This is different from other elements like grids and levels. My understanding is that the way they expected Architects and Engineers to use the feature is a little different for columns, something like this:
  • Architect places schematic architectural columns (different from structural columns)
  • Architect sends model to engineer
  • Engineer uses copy/monitor to create structural columns where the architects schematic columns are
  • Engineer sends their model to Architect
  • Architect adjusts their columns to be masking only (unless they are left uncovered)
The disparity between column types is intentional because an Architect's needs for the column are often different, masking a structural element versus designing/engineering the column itself. It can also be argued that it would still be better to complain when the column family is changed or swapped for another type (size). Even if, as the Architect, I've shifted my focus to wrapping structural columns it is likely worth being warned if the structural column has changed.

To be warned requires me to have a copy of the column to monitor, which I'd prefer to avoid ordinarily. In general, I encourage Architects to remove their own columns (structural or otherwise, if they use them) in their model as soon as the Engineer is hired and they send them their structural model. Now the architect can focus on using walls to wrap columns as required by Design Development and Construction Documentation. I resist the natural temptation to have my own copy of elements if at all possible, striving to avoid redundancy. Using copy/monitor (the monitor aspect only) can still alert us to major changes to location of the grids/columns.

For now Revit doesn't complain if we change the columns, as long as that change isn't its position/location. If that doesn't fit our model view then we need to let them know.

I wrote this post in part because of a thread at the Autodesk Revit Structure online user group. I wrote this suggestion to work around the lack of warning.

Since Revit is sensitive to movement, we could agree to move columns that are changed like this. If the architect is redesigning a column they can swap out the type for a new type but also move it off grid by a specific value. This will prompt a coordination review when the file is refreshed in the other discipline's file. When they examine the column they'll see the change is more about the size than position. They can respond to the change and move the column back into position, which will prompt coordination review upon return. We could agree that such trigger movement would always be East to West and always a specific distance or something like that so each team knows what to expect.

Thursday, December 04, 2014

Revit 2015 Release Update 5 and Terminology

Autodesk released another update for Revit 2015 yesterday, it was formally announced via The Revit Clinic and tweeted. THIS PDF is the published list of things that this update, as well as past updates, have dealt with. I hesitated to post this yesterday because I was a bit confused by what I read at the links below.

Revit 2015 UR5
Revit Arch 2015 UR5
Revit MEP 2015 UR5
Revit Struct 2015 UR5
Revit LT 2015 UR5

For many years an update meant a fresh installation, replacing the previous installed version. This eventually changed in favor of updates that could be applied to an existing installation of Revit. That meant a smaller file to download (usually) and it could be installed (or deployed) more easily. For many of those earlier years we just referred to these updates by their build number, as in, "What build do you have?" We still have a build number to reference.

More recently they began including the phrase Update Release and a number. For Revit 2015 it was easy, through Update Releases 1-3, until Revit 2015 R2 became available, introducing new terminology. The R2 release, which delivers brand new features, is only available to customers who have active subscription accounts. As it happens R2 also includes things that an Update Release would include, as such installing R2 meant we were technically installing Update Release 4 at the same time. For customers that don't have an active subscription it is necessary to make Update Release 4 available to them too.

Distinctly different from R2, an Update Release fixes things within the existing product. It does not provide new features. These shouldn't be confused with a Hotfix, though having a similar intention, which tends to repair a relatively tiny part of the software. They are both delivered via a download from the Autodesk site too. We should be alerted to them becoming available via the Communication Center and/or the Autodesk Application Manager (if deployed/enabled).

In contrast, the R2 release does provide new features that we might normally expect to be delivered as part of a brand new yearly release. In this case it was delivered as part of our subscription benefits, only to those with valid subscriptions in place. It also does not incur a file format change as we see with the yearly releases. As we've seen in the past it could have been delivered as Revit 2015.1 instead. Language and terminology is fun!

Such was the confusion initially that The Revit Clinic offered up a post called What is the Difference between Revit 2015 R2 and Revit 2015 UR2? As I mentioned at the beginning of this post, I found myself confused when I visited the download pages for Update Release 5. This section seems to suggest there is a separate update to download via the Subscription site?

Note: If you are an Autodesk Subscription Customer and have installed Autodesk Revit 2015 R2, please install Autodesk Revit 2015 Update Release 5 for R2. Refer to the Autodesk Revit 2015 R2 subscription download page.

If you follow the link they provide it brings you (if you log in) to the original Revit 2015 R2 subscription download page. There is no mention of a special Release 5 update for R2. I wouldn't have been as confused if it said what I now believe it really meant: "If you haven't installed Revit 2015 R2 yet you can download it via this link".

I gambled and downloaded the update for Revit 2015 (first link above). My Revit is delivered as part of the Building Design Suite and I was able to apply this update successfully. In the past it was necessary to download a unique BDS delivered version of Revit 2015 updates. In this case they appear to have dispensed with that subtlety.

To summarize I believe this is accurate - see if you can stay with me:
  • Original release of Revit 2015 for which they have provided Update Releases 1-5.
  • New Release of Revit 2015 R2 which is available to subscription customers only, to which Update Release 5 also applies.
  • Update Release 4 became available at the same time as R2 was introduced but it was necessary to provide a separate update for customers that were not eligible for Revit 2015 R2.
  • If you installed R2 you also received Update Release 4.
  • If you install Update Release 5 today you also incorporate all previous Update Releases.
It is not clear to me at the moment if there is a different build number when Revit 2015 R2 and Update Release 5 are installed as compared with Revit 2015 installed and Update Release 5 applied. I'd expect a different build number since Revit 2015 R2 has features that are not part of Revit 2015. Shall we compare build numbers? Mine is in the image above, R2 installed with Update Release 5.

As always, be sure to carefully read through the Readme documentation provided at each download page. Clear as mud? I sure hope so!

Wednesday, December 03, 2014

Our Revit Username and Signing into A360

When Autodesk began introducing Autodesk 360 based tools and services they provided us with a place to sign in to our account within Revit too. We can sign in via the Info Bar.

Regarding using worksets, when we are using Revit 2014 we can sign in to our A360 account and it leaves our current Revit username alone. When we are using Revit 2015 logging into A360 will attempt to change our username to match our A360 username. If we are already working in a Local File with a different username we'll get this warning message and signing in to A360 fails.

If we are working on a project that doesn't use Worksets we will be able to sign into A360 but it will change our username in the process.

If we attempt to open an existing Local File later we'll encounter this warning.

If we intend to work on a project, that uses worksets (as many of us do), then we need to make sure we've already logged into A360 before we create/open our Local File to avoid this issue. In Revit 2015 we can sign into A360 via the Options Dialog too.

I'm making a habit of checking my username before starting any work AND logging into A360 first if I intend to use it. That's the tricky part, will I and when? How many people this affects right now compared is another question. The concept of Autodesk 360 poses EyeTee with an interesting problem, creating and managing separate user (other than their own domain) accounts at Autodesk.

Tuesday, December 02, 2014

By Sketch Stairs and using Stair Path and Tread Number Annotation Tools

Since they revamped the stair tools in Revit 2013 and tweaked them slightly in 2014 and 2015 we've had two annotation tools, Stair Path and Tread (or Riser) Number, to place view specific stair annotation.

Sadly the Stair by Sketch method of creating stairs is not recognized by these relatively new stair annotation features.

You'll find Revit is unresponsive when you attempt to apply them to your stair. They only work with Stair by Component. However, we can create a Stair by Component and then use Convert to turn each run/landing into a sketch based component and the Stair Path and Tread Number tools continue to work.

I assume this limitation has something to do with built-in locations within the component stair elements to define where the annotation can appear. There is no way to provide equal representation within the sketch. For them to work on the sketch based stairs I imagine it would be necessary to add another type of sketch element like Stair Path and/or RiserTread Path, like we already have for Run, Boundary and Riser. Using Convert on a stair component allows for sketch based modification but retains its componentness, at least enough for the annotation tools to keep working.

For now it may suffice to start with Stair by Component and then use Convert to modify the sketch as required. Worth a try.

Monday, December 01, 2014

Setting Yes No Parameters with Formulas

Peter boards a train in Philadelphia bound for NY. Joe boards a train in NY bound for Philadelphia. If both trains... oh I don't care when their trains pass one another. Next question?

I want Revit to automatically check a Yes/No parameter but only when two other parameters are checked already. I read a post at RFO asking how to accomplish this. That member's issue was Revit complaining about inconsistent units, as it does. I replied that Revit doesn't accept 1 or 0 as a valid true/false value. The formula was written like this for parameter C:

if (and (A,B), 1, 0)

Since Revit doesn't like the 1 or 0 used in that formula we can use this instead:


Revit reads that as, "I (Revit) can only check C if both A and B are checked too". In the Family Types dialog it looks like this.

If I'd like the opposite to happen it looks like this instead:


Revit now reads it as, "I (Revit) can only un-check C if A and B are both checked too." In the Family Types dialog it looks like this.

Greg replied (in the RFO thread) that the formula would accept valid math statements for the true or false result. That means that the formula could be written like this, using the original formula above.

if (and (A,B), 1=1, 0=1)

It looks like this in the Family Types Dialog.

Either approach provides the same end result. Programmers often compete to write the leanest code, complete a task or tasks with the fewest instructions, fewest lines of code. My formula is leaner code but not by much. Regardless, I think it does help to see different solutions to help us solve the problems we encounter later.

Wednesday, November 26, 2014

Roads Category and Spot Elevation

This is too weird not to write about it. I was asked to take a look at a file that would not let us apply a spot elevation. I did the usual things, check for the floor category visibility, no overrides to the linked floor(s), no filters, no underlay weirdness... no joy.

I compared it against a new view with no view template. The new view worked but the one with a view template assigned didn't. I tried turning back on all the model categories that were off in the view template. The Spot Elevation tool worked again. Hmmm...

I reset the View Template and then I turned back on each category that was off in the template, one at a time. When I turned on the Roads category the spot elevation started working again. WHAT??

That's more than a little bizarre since we've never been able to use the Roads category for anything. They don't even let us create an In-Place family using the Roads category. I imagine that it is something gone awry in this particular project file since this is the only one behaving this way but still...turning on the Roads category fixed it??

Thursday, November 20, 2014

Username and Local Files

Revit knows who we are based on a simple piece of data, the Username entry here (Application Menu (Big R) > Options). That is usually defined by who logs on the computer. If we log on our computer, then open Revit AND change the Username...Revit preserves this alternate username until we change it again. If we never change this value then Revit just uses the computer's log on username identity. When we change it Revit captures and preserves it for this particular person's log on credentials on the computer.

Using Worksets (Worksharing) this username provides our unique identity to Revit, the Librarian (not to be confused with the TV show or movies). We can't just arbitrarily change our username while we are working in our Local File. If we do that we'll be greeted with an unpleasant message when we attempt to use Synchronize with Central.

We can become convinced that changing the username is permissible because Revit doesn't complain until we attempt to use Synchronize with Central. It's also easy to think it is reasonable because when the file contains changes that have not been synchronized yet we see this message when we attempt to change the username. When Revit complains and offers the reason that changing the name isn't going to work it implies that there might be an acceptable circumstance.

Fwiw, we CAN change our username freely if we are working in a central file (discouraged). However we won't find that very fulfilling if other users are also working on the project via their own local files. We'll be advised by Revit that it is necessary to use Save As to create a our own Local File first, when we use Synchronize with Central.

We CAN assume any username identity, we just have to change the Username parameter before creating a new Local File.

Damn Revit's Worksets and Worksharing features are fussy!

Wednesday, November 19, 2014

Importing CAD Files and By Shared Coordinates

When we link/import DWG files with survey data Revit often encounters file extents that are quite large. The developers have always encouraged us to use the Auto - Center to Center positioning option with those files. Revit will forcefully use that option when the extents of the file violate the current 20 mile tolerance it has.

I wish I could write that linking/importing survey files was very simple and error free. The reality couldn't be further from that. I recommend these steps to improve the odds for success:
  • Import multiple Survey files individually (don't nest them as xref's)
  • Purge everything you don't need, purge again
  • Use Wblock if you can't get Zoom Extents to focus on just the relevant portion of the site
  • Remove Named UCS (Revit only wants the World Coordinate System)
  • Set UCS (User Coordinate System) to WCS and Plan to WCS
  • If the survey isn't oriented to WCS, North is "up", have the civil engineer/surveyor change their file first
  • Identify a specific location within the relevant part of the survey, put a marker, identify its coordinates, better still make those coordinates easy to use, even clean numbers.
  • Make sure everything actually aligns correctly in AutoCAD first, no point setting it up in Revit if it doesn't work there
  • Once you get a working first survey file, pass it back to the surveyor so they know what you need in the future
Once we've used Acquire Coordinates on our first survey file and verified the resulting coordinates are correct we can import the rest of the site related files. If Acquire Coordinates didn't work then we need revisit the items above, especially Named UCS. I find that Revit will acquire very large coordinates accurately IF the file is pristine.

In contrast I also like to use Specify Coordinates at Point (SCaP), using the marker I created earlier. Keeping in mind that doing so doesn't establish a shared coordinate relationship between the CAD file and the project. By relationship I mean that Revit records the identity of the linked file in the project when/if Acquire Coordinates is used to align the project with the linked file's WCS origin. SCaP does not.

Now regarding the title of this post, importing the rest of the files. Once shared coordinates are defined based on our first file we can import other site files using the positioning option: by Shared Coordinates. This assumes that each of the site related files are already aligned with each other using the same WCS origin. When we link a file this way a warning will appear while it is loading.

Revit is being precise, warning us that this project doesn't have a shared coordinate relationship with the incoming file. That's true, it is just another CAD file as far as this project is concerned. The only shared coordinate relationship that is established is between the first file and this project.

The last part of the warning is the significant part, The link's World coordinates will be aligned with this project's Shared coordinates". That means it will line up correctly because our project is aligned with the same WCS and both cad files already use the same WCS origin between themselves. Clicking Close accepts the warning and the link should land in the correct location. We can repeat this as many times as we have site related files to use.

When we save our project we may receive this warning. In this circumstance choose the bottom option Disable shared positioning...

We really don't want to create a named UCS in the CAD file the dialog references. It's linked and lined up correctly, its WCS is already correct, there is nothing to be gained by letting Revit store a named UCS in the file. This is what happens if you click Save instead, we end up with the named UCS in the image below.

I don't recall Revit bringing up this dialog in the past, unless I moved the link later, and I don't think it should be doing it in this circumstance. Fwiw, it doesn't in Revit 2015, at least not with the files I've been experimenting with for this post. It may be related to having a Named UCS. In some further testing I was able to link and save without generating the dialog. The inconsistency seems to consistently fall back on the condition of the DWG file though.

If we are careful to link each file and Disable the shared positioning Revit seems to think needs to be established all our linked file should line up very nicely. When they don't I find it necessary to revisit the list above. Skipping over them is very likely to bring on heartache later.

Tuesday, November 18, 2014

Adding Callout to Quick Access Toolbar in 2014

If you're using Revit 2014 and have tried to add the Callout tool to your Quick Access Toolbar (QAT) you've been turned away, rejected, sorry no you can't do that here... Sorry, applying Web Update 3 doesn't fix it either.

Subtle and minor it may be but stuff like this frustrates users. ...and I was sure it was possible. Oh right, it's working in Revit 2015. One more subtle reason to upgrade.

Friday, November 14, 2014

Enable 2D Setting for Multiple Grid Lines

There are times when we'd like to alter the 2D (view specific) position of Grids. When you select a Grid you can click the 3D icon to toggle it to 2D. That's a one-at-a-time affair though. If you have many grids you won't look forward to doing that.

When a Grid crosses a crop boundary in a view (when the crop boundary is enabled) it switches from 3D to 2D automatically. If you want to enable the 2D setting for all the vertical grids at once turn on the view's crop boundary and make sure it crosses your grids.

Now you can adjust all the Grids end point position together just like they do automatically for the 3D setting. It will work for levels too. If you don't want the crop region long term you can just disable it afterward. The Grids or Levels will retain their alteration until (if) you elect to use the Reset to 3D Extents (right click context menu option).

Thursday, November 13, 2014

Relocate Project is Sleight of Hand

Try these steps:
  • Create a new empty project
  • Open the Site plan View
  • Make sure the PBP (Project Base Point-circle) and the SP (Survey Point-triangle) are visible
  • Use Relocate Project, "move" the PBP 1 meter to the left
  • We'll find the SP is now 1 meter to the right, left behind marking where the origin was
  • The SP identifies the origin of an alternate coordinate system, roughly equivalent to AutoCAD's WCS (World Coordinate System) origin, consider that using Acquire Coordinates aligns Revit with the WCS of the source DWG file.
  • The previous steps are essentially the same as moving the SP (clipped) to the right 1 meter instead (use Undo and try it)
  • Using Relocate Project you see the PBP move but its really the SP that's changed, it just doesn't look like it because the PBP is reporting a different 0,0 coordinate offset now (more on that below).
In a sense Revit just shifted the world over, underneath our building, and the origin never really changed. If we try the steps above and make sure we can see elevation symbols it becomes more apparent when they don't change their relationship to the PBP after using Relocate Project.

The PBP and SP start out at the same location in stock templates, but they are NOT marking the same information.

The Project Base Point always (when clipped) identifies where the project's origin is. The Survey Point identifies one alternate coordinate system's origin location, when it reports 0,0.

I believe it causes confusion when we examine the PBP coordinate values (when selected) because it displays values that are relative to where the SP defines the WCS origin, NOT the project origin. Since the project origin is never really changing it would be more accurate or consistent to continue displaying 0,0 and only begin showing different coordinates when it is moved un-clipped.

The following image shows a SP that has been moved by Acquire Coordinates to mark the WCS origin of a source survey DWG. The PBP now shows coordinates that match the offset from this alternate coordinate system's origin. To be fair it does say Shared Site: just above the values but it isn't as meaningful to most users as we'd hope.

The following image shows both PBP and SP moved while un-clipped. It is tempting to think of them as points when they are moved like this but they are really annotation referencing coordinates that are only meaningful when compared with where the origins they are referencing are, which I believe contributes to the confusion about what they display when selected.

General Comments and Advice
  • The Project Base Point never displays coordinates that reference anything but the Shared Coordinate origin location.
  • The Survey Point initially identifies an alternate coordinate origin but it can be un-clipped and moved to show coordinates that reference its origin location.
  • The Project Base Point and Survey Point start by marking their own origins, at same location in stock templates but they are NOT the same coordinate systems.
  • Don't use Relocate Project for X/Y axis project changes, it's really just establishing an offset relative to the Survey Point, not changing the project origin.
  • Don't move the Project Base Point clipped
  • Relocate Project can be useful in the Z axis when you need to show an arbitrary elevation value without placing the building at the actual elevations, see True Elevation and Position, it is still sleight of hand though, using Shared Coordinates to achieve the difference.
  • Moving the PBP un-clipped can be used with the Spot Coordinate annotation. It can reference the Project Base Point location when it is desirable to mark locations, using the Spot Coordinate tool, that all reference where we've placed the un-clipped PBP.

Monday, November 03, 2014

Dynamo Tip and Forum

If you open a Dynamo project that is based on a language that is not the same language as the Revit project you are in it can cause Revit/Dynamo to crash. We can avoid the crash if we open a project that shares the same language first. That's how it was described to me at RTC in Dublin this past week. Perhaps it is just a build incompatibility? It seems to me that will make it difficult to mix and match up Dynamo work that is done in various languages?

The best place to stay in the loop about Dynamo info is Better check in with the forum there to be sure.

BTW, regarding forums, AUGI recently created a new forum for Dynamo, to expand their Revit forums to include a place for this rapidly emerging tool. You can VISIT it HERE.

Friday, October 31, 2014

Confirm Acquire Coordinates

I'd like Revit to display a confirmation when I successfully acquire coordinates. It would also be nice if it displayed the coordinate "shift" that occurred in the dialog too. If I failed to select a source then it would be nice if Revit let me know I failed, try try again.

Tuesday, October 28, 2014

Occupancy Calculations and JavaScript

The other day I read a post at Revit Add-ons about integrating Java Scripts into Revit. I was intrigued by an example it described which provides a connection between a java script calculation (formula) and assigns it to a parameter. A very common request among Revit users is to be able to associate with a formula with a Shared Parameter, and in this case occupancy calculations. Timing is a funny thing because an email came in the same day asking for advice doing these calculations.

The application is called LazJS and is currently offering a beta version 1.0. Fwiw, I created an Occupancy Calculation sample project years ago which you can download HERE. I thought I'd open that project and try LazJS out on it. Since we can't put a calculated value in a tag the example uses a schedule so we can transfer values manually. With the advent of the API there are more options but for anyone who is leery of programming it's still a bit intimidating.

I found it was really easy to get this installed and configure LazJS to fill in the values for me automatically and keep them updated if I make any changes. This is the dialog that appears for their ParamJS tool. I started by choosing the Rooms category. Then I chose the parameter that is in my room tag. Then I dragged the parameter whose value I wanted to be in the tag up to the code editor window. Once the code was present I clicked Run, seeing values in the results window I clicked Save.

Now whenever I add a room and assign a occupancy type its tag fills in the appropriate Occupancy Factor for me (the script does). Same for any editing I do of existing rooms.

Worth a closer look if only for this piece of their whole application.

Monday, October 27, 2014

Visible Parameter and Associate Family Parameter

When we work with Forms, Symbolic and Model lines and nested families they each have a parameter called Visible and we can use Associate Family Parameter to control their visibility.

If you decide to remove this relationship Revit applies the current state of the parameter that was controlling it to the Visible parameter. If it was checked (visible on) then removing the parameter relationship leaves it checked. If the reverse is true (visible off) then the opposite happens.

It's subtle and can cause a few minutes of confusion when you reload a family and find it isn't visible.

Friday, October 24, 2014

Including a Sheet File Name and Path

Ever since we started using computers to generate architectural and engineering drawings we've been inclined to provide a place on a title block to help people find the file. Sometimes it is just the file name and other times it is necessary to have both the file name and path to the folder it is in.

The path is useful to the team working on the files but if those files are passed along to someone else it may be meaningless to them, or confusing at the very least. The file name is useful to anyone who happens to be looking at the drawings as long as they are in a position to access the digital version of the file too.

In a Revit model, which usually contains all the sheets for a project, the file name doesn't have the same usefulness when compared to a file based system like AutoCAD. That's true unless you are printing multiple layouts from a single DWG file, then it's not all that different than Revit. When someone is looking at a printed sheet and sees the file name and path it doesn't help them find the digital version, like a PDF file for Sheet A100 for example, because the file name is the Revit model, not the resulting PDF export.

As such Revit misses the mark in helping us carrying on that tradition. Since there are a number of ways our sheets can end up as individual files it is hard for Revit to anticipate or provide a suitable way to plug in a unique value until the data is exported outside of Revit. I'm sure there are some things that they could do to help us with this but it hasn't happened yet.

Revit's API could be used to capture the sheet information and store a contrived file name in a parameter for each sheet. When we print or export we might end up with the correct file names matching the resulting files or bearing a slight difference. I don't recall an existing application that deals with this specifically but one might exist, like Xrev Tools for example.

If we forget limitations within Revit for the moment, since the output format of a set of documents is where the appropriate file data is really needed it might make sense to consider focusing on how we handle the output files instead, at least for now. For example, the company Bluebeam offers software to process, review, and markup PDF documents. It includes the ability to add custom headers and footers, which can be the file name (among other things). It can also Batch Process files to include the file name. The file path is another available choice to put in a header or footer so we can combine them if we want to include both.

If it is necessary to provide the specific file name (and path) for exports to DWG it is probably best to add it those files after exporting, this way they'll point to an actual file instead of the Revit project file. Again some customization could add the necessary fields pretty effectively.

It seems like post processing this information is probably as effective as trying to come up with a way to deal with it internally in Revit.

Thursday, October 23, 2014

Filter Filtering Gotcha

When you create or edit a view Filter we can apply a Filter to the list of categories based on discipline.

Filtering the list of categories has a direct impact on the Filter Rules > Filter by: list too. If you tell Revit to only show you Architecture categories then you'll find the available parameters listed in the Filter by: criteria drop down will not include parameters that are related to other disciplines. For example, if you were hoping to use the filter to alter the way MEP elements look when they are linked into your model then you might be confused until you realize that earlier you told Revit to only show you Architectural stuff.

Remember the Filter's Filter. Same thing can happen in the View Templates, Visibility/Graphics dialog and Object Styles dialogs.

Wednesday, October 22, 2014

Local File Error on Open

Have you run into this error message before?

One possible reason is that the folder you are storing local files is running out of allowable space. A folder can have restrictions placed on it. If so Revit can't properly create the local file in a folder that has hit its quota.

When we create a new local file we can often avoid this if we use the option to Overwrite the existing local file versus the Append Timestamp option. Chances are there are just a great many older local files hanging around in the folder.

Tuesday, October 21, 2014

Revit MEP Pipe Appearance in Sections

I met Freddie at the BIM Workshop in Anaheim recently. We chatted for awhile about Revit (shock I know) and then a little about music. It was great to meet someone who wasn't necessarily required to know Revit but decided he wanted to learn Revit and has become quite good at it. The company he works for (TJP Engineering) specializes in water treatment systems for aquatic attractions.

He passed along a graphic that Chris Aquino (Autodesk support specialist) marked up for him when he was trying to sort out piping graphics in section views. Sometimes writing this blog only requires sharing what other people tell me, thanks Freddie!

Here's the image which has markups that explain the various conditions they discussed.

Quick Summary of Issues:
  • No rise/drop symbol? Most likely the pipe is sloping "through" the section.
  • If you see a "crosshair" or "target" it is probably the pipe beyond the fitting but within the Far Clip Plane of the view.

Btw, my Uncle Ben called me Freddie when I was a kid. I. Don't. Know. Why... :)

Monday, October 20, 2014

Revit 2015 - Closing a Workset and Linked File Ownership Conflict

This post describes an awkward issue with Revit 2015 when using a specific workset(s) to manage a linked file(s).

Project File A has a separate workset for Project File B and that file is assigned to it. Both the linked file's instance and type parameters are assigned to the same workset. User A is the Owner of Project File B's workset. Now User B is working in their own local file and decides to close the Project File B workset (instead of using the Manage Links > Unload method). User B gets a warning that User A owns the element.

When we expand the warning we see that the file is the issue.

User B clicks Cancel and the workset closes, the link is no longer visible (the desired result despite the message). If User B Opens the workset, no error. The error only occurs when the workset is closed.

Closing a workset that has a linked file associated with it now is equivalent to using Manage Links > Unload, because using unload generates this error message now too.

This error dialog is very confusing because it claims that we can't do something, without creating an Editing Request, that clicking Cancel does let us do. We now have a normal error message that we have to tell users they can ignore, click cancel please. That's just ridiculous.

Demand loading and unloading worksets is fundamental and critical for large projects. Large projects have many people contributing so now we'll have many people getting a pointless message.

Thursday, October 16, 2014

Parameters with Math Characters

Kudos to GMcDowellJr at for paying attention. I missed it entirely. We've been careful to warn people not to include math characters in their parameters names for so long that I just don't ever try to do it.

At some point in the recent past (my testing shows beginning with Revit 2014) Revit started reconciling the issue for us with these brackets [ ]. Just wrap your rogue parameter name using math characters with those brackets and Revit won't mind anymore.

Revit will even add them (the brackets) for us if we rename a parameter to include math symbol(s). For example, in the following image these parameters and the formula are fine.

Then I changed my parameter name and Revit put the brackets in the formula for me.

When I try this in Revit 2013 it doesn't mind changing a parameter name to include a math symbol if it didn't have one originally. If I try to create a new parameter with a math character and use it in a formula then I get the familiar warning. If I add the brackets myself, no difference. In 2014 and 2015 the brackets start working and get added to a formula for us, when necessary.

I don't recall The Factory ever taking credit for this change, a nice subtle compensation for parameter naming.

Wednesday, October 15, 2014

Stage Curtains

Back in January of 2004, about eleven months before I started blogging and a couple months before moving to California, I shared a couple stage curtain families at AUGI. They were made using Revit 6.0. I recently got a message thanking me for them which made me curious how well they'd upgrade to Revit 2015. I downloaded them from AUGI too since I'd lost track of the files since then. They upgraded fine. Well, without a warning message but they didn't retain all their parametric behavior unfortunately.

If you're like me, you can't help but second guess the things you did when you get to take another look at something you did in the past. This is no different. I didn't like my choice of parameter names and the logic I used to allow for them to be reconfigured. So I spent some time re-working them in Revit 2015.

Here's what they look like in play now, the main setting is a burgundy color, the olio setting is a lighter shade and the cyclorama legs, borders and rear traveler are just black (though they look gray). If you aren't familiar with theater terminology, the olio setting is traditionally fancy or at least a different color. It is typically used (closed in front of the stage set) as the background for the opening act of a show, comedian, magician etc., far enough forward to leave most of the stage for the primary production (hidden from view), close behind the main curtain setting but leaving some stage space for the intro act.

And in plan view

And in Section

If you'd like to download them here you go:

2015 Stage Curtain Border
2015 Stage Curtain Traveler

If you need them in an earlier version than 2015 these are the Revit 6.0 files. You'll probably have to tweak them a bit to retain their parametric relationships, such as changing the height of the curtain or length of the batten etc.

Revit 6.0 Border Curtain
Revit 6.0 Traveler Curtain

I'll close with a rendered view using some stage lighting fixtures that Andrew K shared at (works with ARCAT) and a couple saxophones that Michael Anonuevo shared with me back when he was working on his family editor book.

I did consider rebuilding these using the new Adaptive Point divide and repeat concept. Perhaps another day. It would be interesting to compare the performance of that technique against these. These do put a bit of a drag on a model because of the blend array that makes the curtain.

Okay, now I'm just having fun...