Friday, April 10, 2015

Spaces instead of Areas

Area plans have their quirks. They can only exist in their own special area plan views. They've got rules and quite often people want to break those rules. If we need to do that then we end up sketching boundaries a lot. Areas don't know anything about Rooms either. That means we're probably going to have to enter some data twice if we must use Areas pretending to be Rooms, all to document fussy Room area requirements

If that's the situation we find ourselves in...do we have access to MEP's Spaces? If so we could consider...this...

The plan in this image is an architectural model (yeah really simple mock-up). Is it obvious what I've done? I've got Room tags reporting area only as well as Space tags reporting a little different area value along with Room name and number. It also has a Color Scheme applied to Room departments.


It's also a separate model I called Area Calcs. I linked the Architecture model into Area Calcs. The Room tags I mentioned a moment ago are actually Room tags, tagging each room's area in the link. For Spaces however I opted to just sketch Space Separators over the linked model since I need to identify different parts of the room's boundaries to calculate area anyway. A Space isn't different from a Room when we rely on walls for their boundary, in how they calculate area at least. Sketching our lines gives us complete control over the results without dealing with Area Rules.


A Space Separator is a linestyle (like Area Boundary and Room Separator) and I changed the appearance to a much thicker burgundy line so it stands out against the linked file's plan. I ended up applying transparency to Walls too. Once I defined the boundaries I needed I used the Space tool and opted for Place Spaces Automatically. This creates a Space wherever one is possible within the boundaries I've created. This is done floor by floor, assuming there is more than one floor.


Just in case you weren't aware of this already, a linked file has a Room Bounding option.


If this option is selected then Place Spaces Automatically creates Spaces wherever Revit finds Rooms and valid boundaries even where there aren't any rooms (note my interior design comment later). Since I need to define room area differently that's not going to help me now. It's intended to speed up the process for engineers while they are preparing their project to start work.

Now that I've got Spaces I can take advantage of a separate tool called Space Naming Utility (SNU). It is crazy that this tool is still a separate installation but it is. At least it isn't locked away in subscription only access anymore. I keep hoping it will show up inside Revit in the next release.

Sorry I digress, it (SNU) will read (from the linked file) each room's name and number and pass it to the equivalent Space's name and number.


One risk here is Revit might not figure out which Room is supposed to be related to a Space. However, if we examine the properties of a Space we'll see right away whether Revit can see a room relationship or not. Plus any Spaces that don't update will be a clue or at least identify a Room that hasn't been filled out with information properly yet. I'm hoping to apply the 80/20 rule here and win.


If I want to use Fill Patterns too, like below, I can create a separate view that only shows a customized Color Scheme that applies Fill Patterns instead of a solid color fill. Then I just stack (overlay) this view on top of the other floor plan on a sheet. I just need to make sure the view is using Wireframe so it doesn't mask the floor plan.


I can even add a separate Color Scheme legend to the other view that's stacked over the floor plan.


Choosing this route might come down to how I answer these questions:
  • Do I have Spaces? (Are they part of the Revit version I use?)
  • Which is worse, sketching Space Separators or Area Boundaries?
  • Which is more fun, using Space Naming Utility or manually updating Area data to match relevant Room data?
  • If I know a Dynamo/API programmer then maybe I can improve the Room to Area process instead?
This popped into my head last evening while I was mulling over a client's email. I've suggested using Spaces in the past to help deal with linked interior design models so this time around it didn't seem quite as crazy to me as it did the first time.

Want to poke around the files (Revit 2015) I used for this post?

Area Plans
Area Calcs

Your mileage may vary...

Thursday, April 09, 2015

Justifying a Revit Manager

Imagine...you work for a firm that doesn't have a dedicated Revit Manager. There are nearly fifty of you toiling away with Revit now, things are busy, business is growing. That's great!

Still, management isn't interested in having a dedicated Revit Manager. The current solution is to divide up the things that person would do across three power users in the office. A year or so ago when there was about thirty people it didn't seem like a problem, as much.
Can you help your firm justify a Revit Manager?
Full disclosure, I don't usually get involved in this kind of discussion with clients since I tend to focus on user's work, a Revity task and strategy bias. It's not a normal part of my work but I am comfortable with wandering into conjecture, to offer my thoughts. How would I approach this if I am the one in this person's situation? I want my firm to recognize a need for a Revit Manager (or if you must...BIM Manager, I'd prefer Design Technology Manager personally).

I'd want to find out how my firm's management makes decisions about staff in general. When do they decide they need another office secretary, assistant, architect, intern or anyone? What factors, what numbers are they crunching, considering when they do that? How much analytic effort is put into it? Who are they entrusting with the decision to do something ultimately?

Let's say in this situation, we have a full time IT person. How did they decide that was necessary? I'd want to know why they consider that different from a Revit Manager (or Design Technology Manager). This is software that so many people rely on for 40+ hours a week to do billable work. I think that makes it (the software) important, which in turn makes the role as important to the firm as the IT person is to keep computers functioning well and securely. If they really don't recognize that, then I'd want to understand their logic, if possible. Then I could counter their thinking with more data, more examples.

It is also important that they (management) appreciate they ARE already paying for this person. They are currently paying other people to do that person's work (the three people mentioned earlier). Hopefully they aren't so distracted to think that's not the situation at hand. Each minute they are not directly billable is that person's time.

As such they need to quantify how much time and money that effort, spread across three people, really costs. It's quite easy to ignore money trickling out the door when they don't have a security camera focused on it to help them see it. How is it affecting them being billable, providing a greater income and return for their effort than the internal work that is distracting them.

Chances are good that, lacking a specific support person, there are even more indirect costs that are not getting tracked well (or at all) because those three are not really covering everything that arises. Nor do they have time to plan ahead or deal with office wide implementation effectively enough. People tend to struggle for quite awhile before they ask for help. The three are busy so they aren't free enough to just check in on people and catch them in a problem.

If I'm hitting a brick wall, can't get them to agree there is an issue then I'd suggest a study (oh NO...going academic now). Doing one demonstrates being willing to substantiate a claim and having enough patience to research it, to remove all doubt.

We make all sorts of decisions and many of them as much emotional as analytic. We call it hindsight when in two years we look back and agree that it was obvious we needed to do something...either we did and we are patting ourselves on the back or we didn't and are expressing regret. In the skeptical mind, we hear..."oh, it's a delay tactic...putting off making the right decision we think it is". It's quite likely that we need to measure things that are probably not now. A study could help this along, help everyone recognize the problem for what it is.

For at least one month we should carefully track activities, much deeper than we've done before. Ideally it should be for a few months. This allows us to gather more data which can help rule out any peculiar things that happen during the study's run which could skew the conclusions, like one project running off the rails due to external problems that end up distracting the firm excessively. To do this really well ALL of the staff needs to be involved (everyone this person would influence/support). It needs to be easier to identify how the lack of this person IS influencing everyone's productivity.

Anything that is not directly billable to a client's project is assigned to other cost categories. If accounting is pro-active then they've already got a variety of chargeable codes to use on time cards. If not then they need to start there so it is possible to see where the money is really going. We need everyone to be comfortable with keeping close track of their tasks carefully for this to work, no fear of recriminations if they get caught being not billable as much as we expected.
I would not be surprised if the study also flagged other issues that might be every bit as interesting, apart from the purpose of this post. The quote attributed to Peter Drucker is, "If you can't measure it, you can't improve it."
Once we've got data we can see how much time is spent away from billable tasks. Then we need to compare the cost of one person dedicated to doing those things for them, instead of them, everyone. This allows for a comparison with their effort (the three) being entirely billable instead (to the extent that any of us are entirely billable, never truly 100% if they are tracking things realistically).

We're looking to establish that the company can put at least two of the three back in the fully billable category, generating income instead. Maybe the third person (me, it's me, I want the job!) really wants to do this job and can become entirely assigned to overhead, which in turns should help to ensure everyone else stays closer to fully billable status.

The numbers should prove that it won't cost the company more money to do so...if we are are correct. If we are correct we'll probably discover that we'll be in a better position, and not just financially. It is also possible that we discover that things are better than we think, for the moment, and the current situation is doing right by the firm. To be fair we need to be open to that result too...as long as the numbers are examined well.

There are also less tangible (not just $$) things like happiness and confidence, firm status (reputation) with regard to other consultants (and clients) and using Revit/BIM, reduction of redundant activities (like everyone making doors), setting priorities, standards, training, quality control and others. These all contribute to firm's culture, being productive and happy to show up at work in general.

If the study's results don't support creating this role then its possible that the issue is more emotional, maybe a staffing issue or just how the firm's attitude or message is received by everyone. I've seen situations where a project manager is very concerned about problems only to learn that he keeps overhearing his power user complaining about things he wishes could be improved. Those thoughts get interpreted into my project has a real problem and that can escalate quickly.

Then again, maybe someone is not in a role they'd really enjoy more. If that person is the one that believes the firm needs a Revit Manager...me for example...then I've got some soul searching to do. The firm doesn't seem to need that role yet but it's what I want. I can wait it out, maybe the firm is still growing? I could also find a larger firm instead that offers an opportunity to pursue the role I want.

Working through this sort of business problem and doing it well might just be the proof your firm needs to recognize you have greater potential than they might have initially considered.

Wish me Luck! I'll wish you luck!

Wednesday, April 08, 2015

Linked File Revit MEP has Colors

Revit MEP can assign system colors to their pipe and duct systems. It is easier for them than using a lot of Filters like was required in the past. If you are one of the other trades (architect for example) and link an MEP model and you see color it's probably because they are using this feature. This is what it looks like in the MEP model. I focused on the Domestic Cold Water as an example.


Now the file has been linked to an architectural model. The colors assigned to the pipe system are still applied to the elements. You might be tempted to try to alter the settings of pipe and duct systems in the Project Browser, IF you've noticed that your architectural template has them. I'll save you the trouble, it won't do anything to them.


If you don't want to see those colors you CAN override them with Filters.

I've opened Visibility/Graphics and then created a Filter. In the Filters dialog, if you select only the Duct categories, Flex Ducts, Flex Pipes, Mechanical Equipment and all the Pipe categories, then the "Filter by:" will allow you to choose "System Classification", set it to "is greater than" and "" (empty field).

This should catch all the mechanical elements in linked file and look like this afterward.


Remember to take advantage of a View Template to control this more easily and consistently.

Tuesday, April 07, 2015

Survey Point - Post 4 - Acquiring Coordinates and View Orientation

The bias of the last three posts has been on creating a Master Site file and linking building models to site. That's moving buildings on a fixed site versus moving the site under fixed buildings. The earth doesn't go anywhere, we put buildings on it, so to speak. That bias feels right to me, the ways things really work.

These are links to the three preceding posts.


If you choose to take the reverse approach, link the site to a building, you have to adjust the survey information to align with the building; since its harder to move the model elements around than the survey file. In this example, I've started in a Floor Plan view assigned to Project North.


At this point is doesn't look much different than images early on in the other posts. The building is oriented conveniently for putting in on sheets. I need to move and rotate the survey DWG into a better orientation. I'm using the same preferences I had in the previous posts.


Now I just need to shift the survey down since the contours are at their actual elevations and the building model is at an arbitrary ground floor elevation of zero.


I used the same 22 feet for the ideal ground floor elevation I chose in the other post.


Now I'm ready to use Acquire Coordinates. I opened up both the floor plan and site plan views so I can see the change occur. I used Acquire Coordinates in the floor plan: Level 1 (that's significant...in a moment).


Since there are few possible combinations of actions, let's imagine that I used Acquire Coordinates a little differently. In this case I Acquired Coordinates in the floor plan view: Site and I wasn't observant enough to notice that the view is assigned to Project North which ordinarily wouldn't make sense to do, to me at least. It's easy enough to overlook because at this point the building orientation is technically the same as it is in other views assigned to Project North.


After I Acquired Coordinates I noticed the view didn't change so I realize it needs to be assigned to True North. I do that and the model rotates to show the orientation based on the survey's coordinate system, as I expected initially.


Now a little time passes (we're pretending). I find it necessary to use Reload to update the linked survey file, maybe I cleaned up some of the layers to make it a little lighter in our model. When I click Reload this happens. The survey spins out of alignment.



The cause is subtle and simple: it is IMPORTANT to respect the Orientation parameter setting used, in the view that's used, when Acquire Coordinates is used. If you change to the opposite setting and then Reload the link the orientation of the link will change undesirably; regardless of the view you happen to be using during the reload process.

To restate the cause and effect, I used Acquire Coordinates in the Site view while it was assigned to an unnatural orientation setting of Project North. I then changed it to use the more logical True North but AFTER I already used Acquire Coordinates. This means I have to remember to change it back (to Project North) EVERY time before using Reload on the Linked survey file... Or I fix it, which would require resetting the coordinates so I could Acquire Coordinate again with the better settings in place.

I believe this is another good reason to use a separate Master Site project file. The survey is linked and moved into position but it isn't rotated to reflect True North because UP is North already. The quirk I've described only affects the links rotation and there is no need to rotate it in the Master Site strategy.

Monday, April 06, 2015

Survey Point - Post 3 - Five Minutes with Shared Coordinates

I created a video that goes through the process I described in the previous two posts. It is set to a four and half minute song by Michael Lee Firkins called "The Window". If you've never heard his music I believe you owe it to yourself to check him out, very talented and unique sounding guitarist and song writer.

Survey Point
Survey Point - Post 2


Saturday, April 04, 2015

Survey Point - Post 2

Yesterday I ended the post with a list of steps that I'd take to create a relationship between my building project file(s) and the Master Site file. I started another pair of projects that I'm calling Tiny House A and B (inspired by Sean's Tiny House project). I can start a project with or without site context. Revit's bias is making the project easy to document, forget about True North initially. It is trivial to resolve that in the Master Site file once it is ready, regardless if it is created before or after the tiny house models are started.

Here's how far I took the design of Tiny House A before I decided to work out its location on site.


I closed Tiny House A's project file. I opened up my Master Site file and linked Tiny House A using positioning: Auto - Origin to Origin. The choice for positioning at this stage really doesn't matter since I'm going to move the file to another part of the site anyway; have to pick something so I just let the default option reign. In the following image you can see Tiny House A is sitting at/near the Master Site's origin, marked by the Project Base Point icon.


Now it's time to move Tiny House A into position. I moved it and then aligned it with the East boundary. Then I was careful to put it at 8'-0" from that boundary. I then made sure the closest corner (wall) of the house to the North boundary was also at 8'-0". Being fussy about this isn't particularly important, I'm just being fussy.


Now I want to make sure the house is at an appropriate ground floor elevation. I created a section view so I could see the site's contours and the floor of the house. I can see here that the house is buried under a fair bit of the site.


I decided that raising the house to 22'-0" feels good. I used the Move tool, and typed 22 into the temporary listening dimension that appeared.


I think I'm ready to deal with Tiny House B now. It's really just another project file saved with a new name. I was too lazy to make another design. If this was a real project I wouldn't be able to get away with that. I decided that this house has to be no closer than 8'-0" to the North boundary but I've also made the North end of the house parallel to the boundary.

I learned while reading the development's covenant and zoning requirements that these houses can't be closer than 15'-0 to one another. I decided to put Tiny House B 18'-0" from A. I heard that A's owner is a drummer so those extra three feet might help keep B's sanity. I also decided that the ground floor elevation for B should be 20'-0", a little bit lower than A.


Now that I'm satisfied with the positions of Tiny House A and B I'm ready to use Publish Coordinates. This tool will PUSH the site orientation information to each house's project file. Revit will use this information to shift the house's Shared Coordinate system to align with the Shared Coordinate system of Master Site. In yesterday's post, the Master Site was manipulated to be in alignment with a linked DWG file's WCS (the World Coordinate System in AutoCAD to be precise) through the use of the Acquire Coordinates tool.


When you successfully select a linked file to Publish Coordinates the Location Weather and Site dialog appears. This give us an opportunity to provide a meaningful name for the location we're creating for that model. I clicked Rename... and typed Tiny House A Location 1.

It's significant to appreciate that I could now create a copy of Tiny House A in Master Site and place this copy in another location. I could then use Publish Coordinates on this copy which would allow me to use Duplicate... and use another name like Tiny House A Location 2. In the Tiny House A project file I can now choose between these two named locations and make one of them current. Revit will reorient everything to show the building correctly for this location, all without really changing anything  in the model. It's pretty clever and powerful; actually doing it is something I'll save for another post.
I used Publish Coordinates again but on Tiny House B and used the name Tiny House B Location 1 when the dialog appeared. I'm ready to return to work on my Tiny House A design. I clicked Save so I can close the Master Site project. The following dialog appears twice, once for Tiny House A and the second time for B. This is confirming that I want to commit the location and shared coordinate changes I made while using Publish Coordinates. I clicked Save each time (2x), the top option in the list.

It is necessary to make sure others are not working on the Tiny House A or B now. The Save will fail if someone is working on them. Just ask them to close the project for a minute. When worksharing is involved the same is true but it is a bit more forgiving. Either way, if an error message appears you need to ask others to stop working on these files briefly; they need to Save and close them. Once my Save is completed they can get back to work.
When I open Tiny House A I find that the Site plan is oriented to True North. I changed the Orientation parameter to True North earlier (noted in the image at the beginning). All plan views in the stock templates are assigned to Project North, including the Site view. Changing it meant that I'd see the results of using Publish Coordinates immediately, or at least as soon as I bother to open the Site view. The reality of this is that the project is NOT altered materially, no physical change to any geometry, it is just oriented correctly based on my actions in Master Site. This trivializes the task of re-positioning a building on site, if that becomes necessary.


Taking things a little further, each Level type has a Type Parameter called Elevation Base. It can be assigned to either Project Base Point or Survey Point. When I change this to Survey Point I find that the levels are reporting elevation values based on how much I raised Tiny House A in the Master Site file.


Now I've decided I want to be able to see Tiny House B here too, for context, but while working on Tiny House A. I linked Tiny House B into Tiny House A using positioning: Auto - By Shared Coordinates. This is possible because I used Publish Coordinates, from within Master Site, on both Tiny House A and B. Their shared understanding of their position in Master Site makes it possible to link either file into the other using Auto - By Shared Coordinates and they land in the correct spot relative to each other.


I can also link Master Site into either Tiny House A or B and use Auto - By Shared Coordinates too. They all understand their relationship to each other because of Publish Coordinates and the work I did in Master Site to put them into the proper context with each other. Here is Tiny House A, with Tiny House B linked in. I also created a Toposurface and Building Pads for each house in the Master Site file, then I returned to Tiny House A so I could link Master Site in using Auto - By Shared Coordinates as well.


A Few Notes
  • Master Site is in CHARGE of positioning
  • Only move models in Master Site
  • Do not move linked models when viewed in other related project files
  • Acquire Coordinates created the relationship between Survey and Master Site
  • Publish Coordinates created the relationship between Master Site and Tiny House A and B
  • Respect this order and it is easy to maintain
  • It is technically possible to manipulate the relationship in either direction, DON'T.
  • You must Resist the temptation!

Multi-Discipline Comments:
  • Trades link the Tiny House A and B models into their projects using Auto - Origin to Origin, nothing else.
  • Do NOT start work without a preliminary model of the Tiny House. If you do, be prepared to move your work into alignment manually.
  • It is only necessary to use Acquire Coordinates on Tiny House A or B (whichever house you are designing for in your project file)
  • It is only necessary to use Acquire Coordinates IF there IS an expectation that your data must align in 3rd party software like Navisworks
  • The Tiny House projects will link your models using Auto - Origin to Origin too

Friday, April 03, 2015

Survey Point

In my view, it is no accident that the Survey Point (SP) is named using Survey. It's purpose or role in Revit is to permit us to relate our project to survey coordinate data, which is ordinarily provided by linking an external file. This image depicts a linked DWG site file whose origin is roughly 85 miles from the southwest property corner. The iron pipe at this corner has X/Y coordinates of exactly 450,000',450,000'.


It was imported using Positioning: Auto - Center to Center. This is what Autodesk recommends we do with files that are far from origin. Place the survey information close to the Project Base Point (origin) of the project. Then I used the Acquire Coordinates (AC) tool which was created to let us PULL this information in from the external (linked) source.


After using AC the Survey Point (clipped) marks (makes it easy to see) the actual origin of the source survey data's origin. It is why it usually disappears off into the distance, in stark contrast to where the project's origin is.


When the SP is un-clipped and dragged away from the origin, presumably closer to the project's site, it begins showing coordinate values that equal its offset from its origin, the origin is not altered/moved.


This is what the project looks like after I've finished adjusting the position of the unclipped Survey Point. At this point I only regard it as a marker that validates my belief that my Revit project is now aware of the same coordinate values as, and aligned (in sync with), the linked Survey file.


At this stage I save the file as my Master Site file. This file will act as the Control for site relationships with the site for any and all related building files I may use for this project.

Next (in a follow up post):
  • Import a building file
  • Position it (X/Y)
  • Orient it (rotation)
  • Raise it to the appropriate Ground Floor elevation
  • Publish Coordinates
  • Repeat for other buildings

Note:
  • I'm intentionally NOT interested in the Project Base Point in this post
  • I intentionally did NOT move or alter the Project Base Point
  • I WON'T move or alter the Project Base Point in this file EVER.
  • I WILL turn off the visibility of the Project Base Point.
  • Shared Coordinates are NOT a Band-Aid, to fix poor communication/alignment

Wednesday, April 01, 2015

AutoCAD 2015 Tip - Align Tool

When you have two things you'd like to line up with one another you can use the Align tool. It's hiding on the Home ribbon tab > Modify > (Expand the drop down "arrow) > Align button (left side bottom row).


You can let it scale the selected objects too. It's an option you'll find at the command line, Yes or No, before you finish the command.


If memory serves there wasn't always a button on the User Interface for Align. It was a secret command, like a secret handshake. If you know that AutoCAD has an Align tool then you really know AutoCAD. Just like the Cycle feature...(sshh, it's a test...do you know AutoCAD). Have to admit it is a pretty exasperating feature though.



Tuesday, March 31, 2015

Detach from Central versus Save As - Make this a Central Model after Save

Both techniques allow us to create a new central file from an existing file that has enabled worksets already.

Save As - Make this a Central Model after Save - respects the Edited By information the project has stored. This means if other users have borrowed elements then you'll find those users among the Owner/Borrower column in the Worksets dialog after creating your new central file.


This distinction means it may be possible (though unlikley) to allow users to synchronize their work with the new central file. They'd have to use the Browse button in the Synchronize with Central dialog to point Revit to the new location of the central. I used italics on may be possible because there are so many variables that could prevent it from succeeding that I don't want to provide false hope. If people have not continued to alter or create new elements in their own local files, while this new central file is created, then it may be possible, worth attempting perhaps if you are in some sort of recovery mode.

Detach from Central - completely severs the relationship the file had with the file it came from (usually a central file) and any local files that may exist, as well as ALL ownership information (stored in Edited by parameter). It is a fresh start, utterly.

Btw, this post was prompted by a question at RFO this afternoon. It became evident that this subtlety is something I've not written about, I thought I had.

Monday, March 30, 2015

Family Offered as Work Plane Choice

A question popped up at RFO the other day. A member found Revit offering him a family as a possible workplane to chose when using the Set workplane option. It's perfect for the Dept. of Subtle!

When you use a family as a host for a Face-Based family this new host status of that family causes it to be elevated in status, to being eligible as a workplane for selection now too. For example I've placed a desk and then decided to mount an electrical outlet on the inside face so I can plug in my little space heater (I'm making this up as I go...).


You can see the Desk is now offered to me in the Workplane dialog. So don't panic if you start seeing families in this dialog. It just means they are hosting a party.

Sunday, March 29, 2015

Wish - Insert From File - Work with Templates

Insert from File allows us to import views from another project, views like schedules, drafting views or even sheets that contain either. It is biased toward RVT files though.

It would be handy if it we less biased, enough to include RTE (Revit templates) too. Since we probably have standard stuff set up there anyway. Doing so would allow me to acquire a view from a template file instead of having to first save one as a new project or find another project that is already available in a project folder elsewhere.

Saturday, March 28, 2015

Installing Updates and 2015 R2

Revit 2015 has seen 7 updates so far. I wrote about the confusion that began when Update Release 4 became available at the same time as they released the subscription only 2015 R2. R2 is a new version of Revit with more features/tools but using the same file format so no upgrading of our projects is required.

Some people are only just finding out about R2 now, partly because it is only available through the subscription site and you have to have a valid subscription in place to access it. Some of those folks in this position, in the meantime, have installed the Update Release 5 already, or even 6 and 7. Get ready with the sad trombones...

Per Autodesk support:
Given this scenario, you will need to uninstall and reinstall Revit 2015 if you want to install the R2 version of Revit 2015 and its subsequent updates. The reason for this is that the R2 updates, including the R2 versions of UR5, UR6 and UR7, only target Revit 2015 R2 installations. Likewise, non-R2 updates only target non-R2 installations of Revit 2015.

Will these help?


This means if you've already applied release update 5, 6 or 7 to your installation of 2015 without the R2 release in place, you'll have to start over, reinstall 2015 to get things in place correctly to apply R2 at all. This could have gone better for some, wish it were simpler.

At this point I think I'd just wait for the release of Revit 2016 which, if the past years are any indication, ought to become available mid April to early May. If your project must stay in 2015 but you really want the R2 features maybe its time to talk to Gordon at Pragmatic Praxis to see how his deployment tools can help you?

While you're working this out please let me recommend this Irish Whiskey, if you happen to enjoy a dram on occasion...

Friday, March 27, 2015

Remember Reveal Constraints

If you are examining a view, troubleshooting for example, we can take advantage of a recent addition (in Revit 2015 R2) called Reveal Constraints. It's a small button at or near the end of the View Control Shortcut Bar.


If any constraints have been applied, such as a locked padlock for a dimension, a locked alignment (also a padlock) or an equality constraint that's been imposed you'll see something like this; locked dimension on the left and EQ constraint on the right.


This mode isolates these constraints, making it easier to spot them. If you select the highlighted constraint you can delete it. Constraint be gone! Just add this to the list of things to remember you can do.

Thursday, March 26, 2015

Revit mEp - Design Master

I've been hearing good things about this add-on for Revit from Design Master.


If you're doing electrical work then you ought to have a closer look at it.

It has a tab for HVAC but it appears to only support AutoCAD for that, for now?

Wednesday, March 25, 2015

SW Named Linestyles

Have you noticed the appearance of linestyles in your project that look like these?


This means that someone has begun using the Site Designer tools. Even if there are no Site Designer features in use the fact that they are there means at least one person has started a Site Designer command. If there are Site Designer created features then you'll also find related sub-categories under the Mass category.


Tuesday, March 24, 2015

But You've Been Trained

Tom Nichols wrote this paragraph within a blog post about what it is like being a professor. This part resonated with me because often people attend a training session so now they are trained and in some way that is equal with being fully competent now. Three days in training, five days...a month...

Tom Nichols writes:
... "It doesn’t work that way. Education (as opposed to training, a distinction almost no one bothers to make anymore) takes time. It requires reading, writing, discussion, and reflection. It is a cumulative process. You cannot liquefy it and pour it down someone’s throat in a day, no more than you can eat all of your meals for a year in a single week." ...

You've sent your staff to be trained. Does your plan recognize education too? It was/is your money and billable time...

You've been trained, are you focusing on your education too? It's your career...

Wednesday, March 18, 2015

Web Update 7 is Innocent

A quick follow up post. I was wrong. What I thought was caused by the update is actually caused by the Snap setting Snap to Remote Objects being off.

I must admit it is a bit mystifying since I never turn it off or at least I can't remember I time when I wanted to nor do I remember doing so. Regardless when support gurus Trey and Danny challenged me with their questions I found it was off.

Fwiw, I'd prefer that it didn't impact grid and level placement editing behavior regardless.

At least it prompted me to deal with a couple hours of windoze updates I'd been postponing.

Web Update 7 Killed Grid Level and Ref Plane Alignment

I was wrong, the update is innocent, sorry. The culprit is Snap to Remote Objects which was off.

Uh oh, I installed the recent Web Update 7 and now grids, levels and reference planes don't see each other like they used to. Existing grids and levels work normally. It seems to affect new elements when you attempt to place them in alignment with others. For example, try to sketch new parallel grids. Normally we see a green dashed graphic that indicates alignment with an adjacent grid end. I don't see this anymore. I also don't get the locked relationship between grids. Same for new levels.

If you copy them they'll recognize their alignment and behave normally unless you unlock that and alter them individually. Then they'll forget they can see (should see) each other. We can get around it, with grids for example, until they patch it by sketching a reference plane across the grid ends and dragging them so they touch the reference plane. The grids will start to behave normally as long as we don't separate them again.


Well at least a couple replies suggest I'm crazy but here's what's happening to me.


Tuesday, March 17, 2015

Be Careful Creating a Central File in 2015

A thread at Autodesk's Revit User Community Forum caught my attention yesterday. It seemed as though the culprit was something I've written about before, that user's were accessing the project via different shared resource paths. After digging in a bit deeper it turns out the issue, or at least an issue, is that Revit 2015 is more sensitive to how we navigate to the a shared resource.

This is what happens when I browse to a shared folder via My Computer and click on the Drive letter S:


This is what I expected to see (disregard the project name, I was experimenting with being logged in and out of A360 too):


A clue or warning you can watch for is what Revit displays at the top of the Save As dialog.


If you see the drive letter in the description then you'll likely end up with that as your path. I believe you should only see the folder the central file will be in if you are mapped correctly.

It is my habit to always use Synchronize and Modify Settings before closing the Central File, after creating it. As such I can see what the path that Revit captured is. When I notice that it is wrong, like the first image above, I can fix it, get the correct UNC path recognized instead by taking these steps (see the image that follows too):
  • Close the Central File (after noticing the wrong path reference)
  • Create a local file (before any other users start to work)
  • Use Synchronize with Central
  • Click Browse and click Browse again in the next dialog box that opens
  • Select the Central File by browsing to it via the shared resource path instead, type it in directly if necessary.
  • Click Open
  • Click OK (the correct UNC path should appear now)
  • Click OK (The path is fixed)

If you are creating a central file be very careful about how you browse to the project folder. Verify you have the correct path established before letting users begin working on the project.

Monday, March 16, 2015

Web Update Release 7 Available

Luke (What Revit Wants) reports that another update is now available. These are two links he provided, one for the update and the other for the readme information. He must have someone working for him on the inside. :)

Direct Download URL for Update 7

Update Release 7 ReadMe

Friday, March 13, 2015

View Reference Example

Related to a past POST or TWO...or THREE.

Here's a quick example of a poorly crafted Plan View reference that can be used to indicate what sheet a plan view is from a Section or Elevation view.


Want to reverse engineer it? Download the View Reference family.

Thursday, March 12, 2015

Follow Up - Importing DWG Files using By Shared Coordinates

As the title suggests, regarding an earlier post earlier post, recently I was participating in a thread at the Autodesk User Groups and an Autodesk support person wrote that Revit intentionally attempts to create a User Coordinate System. This means what I wrote about in the other post is happening on purpose, not a bug.

This means they (Revit's developers) are assuming the files we are linking don't already share an agreed upon file alignment strategy between the people that created them. If I understand their logic, it means that using Positioning: Auto-By Shared Coordinates when we link a file triggers a response in Revit that it needs to create a UCS (User Coordinate System) to permit AutoCAD users to align these files if they are combined (apart from Revit) in AutoCAD at some point.

Revit can't know if these files have an agreed upon relationship to the WCS origin because in AutoCAD that's a subjective user based agreement, not something captured in code. In other words we agree as users to draw things relative to 0,0,0 in a specific way so our files will line up when we use them as an external reference. In my view, for multiple survey file relationships, that's most likely not necessary and just creates confusion. I can imagine how it might be useful if we are mixing a variety of trade files that might not have discussed how their work relates to the WCS origin. However that seems like a rarer circumstance to me, especially if Revit happens to be the primary platform in use.

Imagine we link a survey file into our Revit project and use Acquire Coordinates. Revit establishes a relationship with this external file and moves our project's shared coordinate system to align with the survey file. It moves the Survey Point (when the icon is clipped) to mark the WCS (World Coordinate System) origin location of the linked file. Now imagine we link a DWG file that, to pick a discipline, is the fire protection design. It isn't very likely that they started designing by importing the survey DWG. That means their file and the survey file don't share in their understanding of how to start drawing relative to the WCS in their AutoCAD files. In my opinion it is much more likely that they started designing based on a plan we exported from Revit and sent to them. If true then we'd be better off importing their file using Positioning: Auto - Origin to Origin.

If they just started designing without a background file from us (not really likely, what context would they have?) then we could link their file using Positioning: Auto - by Shared Coordinates. Revit generates a warning (refer to the other post's images) that this project isn't sharing coordinates with this file so it will import it using the WCS of the file, which is still pretty arbitrary in this scenario. Revit however regards this positioning choice as significant and when we try to save our work it prompts us to save the changes to the linked DWG file too. It wants to create a UCS in that file and save it so that an AutoCAD user can reference it, making it possible to line up this file with the survey data if those files are combined in AutoCAD.

In my view this a feature that is conceptually broken. It is changing a file (creating a UCS) that isn't the primary file, just my copy of it. They sent it to me so I can link it. If all of the disciplines work at my company and in my office then perhaps all the files are stored on the same server and accessible to everyone. That's certain possible but it is still unlikely that this UCS will be necessary or that anyone will even be aware that it exists.

The shorter answer, when confronted with this dialog: Choose Disable Shared Positioning (for the file involved, not the one that was used to Acquire Coordinates originally).

Based on my bias, we should have a way to tell Revit we want to link a file based on the Shared Coordinate system without incurring the belief that a UCS must be created in the file too. Perhaps an option to link via the WCS of the external file and the origin of the Shared Coordinate system without the assumption that we think there is actually a shared relationship between the Revit project file and the DWG file?

Saturday, March 07, 2015

IF Formulas and Notepad

A good tip was shared (by Josephpeel) at RFO the other day. If you use a Tab or Line Break in Notepad to make it easier to understand a lengthy conditional formula they won't affect the formula when you paste it into Revit.


Just make sure you put the closing parenthesis on the last line, as shown in the image. Revit doesn't seem to understand the copy/paste formula properly if you put them on their own line (at least that's my finding).

Friday, March 06, 2015

Synchronization and Disconnected Systems

This is a bit idiosyncratic but if it helps sort out an issue then its worthwhile to echo it (based on a discussion at the Autodesks NG).

Imagine this scenario:
  • An Air Terminal has an 8' elevation. A Duct rises from the Air Terminal to a elevation of 10'-0" and connects to a horizontal run (also at 10'-0" elevation), running parallel to the ceiling.
  • User 1 raises the Air Terminal to an 9'-0" elevation. The vertical piece of duct connected to it changes in length, but no user is recognized as Edited by (owning/borrowing) for that element.
  • User 2 decides to lower the horizontal duct (at 10'-0") to 9'-0". It is necessary for Revit to change the connected vertical Duct between the Air Terminal and the Duct to do so.
There are no warnings or alerts as these users do this. If a user decides to modify the series of elements, then a warning appears. A warning appears during Synchronize with Central only if this additional attempt to modify the element is made.

At the beginning I wrote idiosyncratic because it is easy to avoid if we agree not to work on each others elements. I would not ordinarily expect another user to decide to lower a duct that is connected to elements that I'm already working on. If we don't discuss what areas in the model we are focused on then it can easily happen. It is important to be aware of what others are working on. The Worksharing Display features can help us see what others are currently working on, if you don't really want to talk to your co-workers...but it's still a good idea.

Regarding the workflow above and not getting an error message, an Autodesk support person replied that they find an error message appears earlier to warn of the inconsistency when trying to reproduce the situation in the latest development build that will become Revit 2016. That means it is pretty likely Revit 2016 will prevent a duct element from being altered by two separate users when they interact with different elements that are both connected to it.

Monday, March 02, 2015

Saving Backward

It is a common question and the answer is no, Revit does not save backward, to an older version. 

People often regard saving a file from one format to another as a trivial matter. As software evolves and new features are introduced these new things have no equivalent representation in the older format. Even Microsoft Word or Excel warns us when we save a file to an older version and those are much simpler elements.

For example, when Revit Parts were introduced. If we could save to an older version that did not know what Parts are how should that transition be handled? What should the developers decide to do with them? What can they become and retain some usefulness?

With AutoCAD there are new features that can survive a trip backward, like Tables can be reduced to text and lines so it still looks like a table but is really less elegant than the Tables they came from. If the file is then saved in the most current version there is no "make me back into a table assumption" so fidelity is lost.

It is difficult to allow for forward saving (upgrading) too. Nobody is very pleased if they upgrade a file and something breaks. Saving backward is most assuredly going to break elements the more object oriented our design tools become and evolve.

Revit's founders chose to eliminate the complexity and development distraction of saving backward at the outset. Most software like Revit does too even if they don't acknowledge it outright. They may allow saving backward in concept but there is always some loss of fidelity or utility in the process.

Revit does permit exporting data to other formats to permit it being referenced in some way by other tools but it remains impractical to expect casual backward and forward file translation.

When Revit was introduced in 2000 it was a rental, we paid monthly and internet access was required. Using the latest version was expected, required. That's never changed even when Autodesk purchased Revit Technology Corporation in 2002. They just made it possible to buy a perpetual license like their other software. Conceptually though nothing has changed.

Autodesk has a legacy of customers who transition from AutoCAD where it is normal to ignore a new release for several years before upgrading. That is possible because the rate of change for AutoCAD has generally been much less aggressive than with Revit which is much younger and has different objectives. 

It is easy to have access to the latest version at all times, via subscription. Fwiw Autodesk recently announced that new licenses will soon be all subscription based (rental) going forward so the concept that Revit embraced in 2000 has come full circle.

I'm not always pleased with Autodesk's choices and how they affect me as a customer but no company is perfect. For example, I'm writing this post on an iPad that can't just give me bloody arrow keys (without an external keyboard). Instead I have to use a goofy fussy magnifying glass to reposition the cursor.