Do U Revit?

Wire End Woes

d.baldacchino@sbcglobal.net — Tue, 23 Apr 2013 16:48:00 +0000

NOTE: This is a re-post from the HOK BIM Solutions blog

If you have never seen this issue before and are an electrical discipline user, you are extremely lucky. When adding wiring to electrical or lighting fixtures built in a face-hosted template, sometimes wires jump around in a frenzy every time a fixture is moved. This is obviously unacceptable, but luckily there is a fix. Let’s break it all down.

Symptoms

You place fixtures, add wiring and all is well. Then you make a change and move some fixtures (because that’s what designers want), and the wire ends are sent off flying all over the place. You think about hurting someone, but keep your cool instead.

Analysis

So what causes this? Thanks to a tip from Autodesk Support and further digging, it turns out that there is a potential bug in the face-based Generic Model template, which is probably the one used for your families. When the internal origin of the family is in a different location than the ref. planes that define the family origin, you see the above behavior, where wire connectors jump to the “projected” location of the electrical connector.

Below we can see two instances of the Lighting Fixture above with a wire added between them. The wire end connections match up with those of the fixture, but the wire end graphics are goofy.

When the fixture is moved, the wire connects to this “projected” connector location and thus appears to disconnect and jump around.

The Fix

To fix the problem, make sure the origin defined by the intersection of two ref. planes is at the exact same location as the family’s internal origin. This way the true connector location is used to connect the wire end instead. The positioning of family geometry in relation to the origin is not important for this to work properly. Here is the proof:

Happy circuiting!

Bloated Revit central files

d.baldacchino@sbcglobal.net — Mon, 22 Apr 2013 04:15:00 +0000

NOTE: This is a re-post from the HOK BIM Solutions blog

A couple of weeks ago I was asked to take a look at a project that the team simply couldn’t open up. The file wasn’t giving any errors and the progress bar sat there at 99% and would not finish opening. To put things in context, this was an FF&E hospital project with about 12 floors and contained links to various other files that housed the building core & shell geometry.

Right off the bat I noticed the excessive file size (about 595MB). By closing the worksets that contained other linked Revit models (about 11 of them), the project finally opened. File size is typically one of the first things to look at when faced with projects that won’t open. In some cases the issue can be easily rectified through a purge of unused elements and a compaction during a sync with central, typically resulting in a reduction of 30% to 50%. Sometimes users fail to realize that if bloated files exist across the board in their project and they load these files as links, they can easily suffer serious performance issues as they run low (or out of) RAM. This is one of the most avoidable problems that BIM Coordinators should watch out for on their projects and can be easily prevented through regular file maintenance.

However in this instance, a purge and compaction only resulted in trimming about 90MB off the file (not bad, but not enough). So it was time for a much more in-depth analysis of the file contents.

My first suspicion was that the project might have contained imported CAD files. A quick search with Ideate Explorer did not reveal any so then I started looking at groups of elements with large quantities. A good troubleshooting strategy is to delete these large group of elements, save a new file (as a new Central) and see how much space is recovered. I took out all furniture families (about 16,000 instances) but the file barely lost 40MB. The families in question were very lightweight and contained mostly plan symbolic representations, which was a smart move for this project’s purpose.

Next I noticed there were almost 7,000 rooms, but did not suspect these would be the source of the problem. After all, they just contain some data, right? Well, it turns out rooms were to blame for this bloated file but I couldn’t figure out how to get this excess amount of bits and bytes released.

After filing a Support Request with Autodesk, I did some more testing based on their recommendations and saved a series of files after deleting rooms by floor (about 8) to try and identify if rooms on a certain floor were consuming more file space than others. Averages revealed that rooms on some floors were using a bit less (ex: 20KB/room) when compared to others (65KB - 83KB/room). However this analysis still led to nowhere and I did not receive further suggestions. Usually Autodesk is eager to take a look at the project file itself but this was not the case this time, even though the SR was filed as Urgent. We were running out of time, so it was time for some drastic measures.

After a purge and deletion of all rooms, the file went down to a very reasonable 65MB. That gave me a goal to work towards. Rooms were consuming about 300MB and if placed rooms were copied and pasted into a new project, they resulted in a 100MB file, which is about 17KB/room. Deleting 800 unplaced rooms from a room schedule did save 23MB, but somehow, about 200MB of space was being held hostage by the remaining 6,160 placed rooms.

Here are the steps taken to fix the file:

Opened a detached copy of the original project and deleted all rooms. The file was saved as a new central, no purging (155MB);
Opened a detached copy of the original project and deleted all model elements, links, families, sheets and views, leaving just placed rooms. The file was saved as a new central, no purging (108MB). Note that deleting model elements is easier to accomplish by going through the Family tree in the project browser. Since Revit does not let you delete the last type of a system family, you need to create a duplicate of the family and then delete the original one. This ensures that if any elements exist in the project with that type, that they are deleted. Sheets and views are easily deleted through a sheet schedule and view list respectively, both set to not itemize every instance. This allows you to pick the single displayed row and delete them all at once;
Opened the central file created in step 1, created workset “Rooms” and set as Active;
Linked the file created in step 2, Auto – Origin to Origin;
Selected the link and bound it, turning it into a group (did not select levels and grids to be inserted). When prompted, removed the original link as no instances were now placed;
Selected the resulting group and ungrouped it. All rooms were now placed exactly in their original location, with the exception that their workset was now “Rooms”.
The new central file was saved (255MB) and those 200MB were finally released. By purging, this file should ultimately end up as a 170MB project, which is much more reasonable.

You might not be faced with this exact same problem on any of your projects, but I hope it outlines the systematic approach to troubleshooting and resolving issues with bloated files.

Securing Linked Files

d.baldacchino@sbcglobal.net — Sat, 16 Feb 2013 18:04:00 +0000

These days I start blog posts by researching my own past writings and select others, to see if everything has been covered about the topic at hand. I guess it’s the sign of the times: BIM in our daily work is no longer solely concerned about Revit and there is so much information to manage and deal with. Since we are unable to upgrade our neurological hardware & software, I have to do this, else I risk excessive repetition! This will be a follow-up to Securing Links Through Worksets (see comments as well).

Steve Stafford also wrote about this topic indirectly at the start of the month. Since we use Shared Coordinates from time to time, securing linked files against accidental movement is very important, although deletion tends to be the worst since views/templates are so heavily modified (not using <By Host View> everywhere). Accidental deletion will undoubtedly result in wasted work and frustration, so anything one can do to avoid it is always welcome.

As stated in my original post, worksets are not an option when Monitoring is required. Since we’re using this on pretty much every project, I no longer suggest this technique. Luckily, there’s a simpler, more robust Option (unintended pun). This technique was mentioned in a comment in the above post, but I never got around to write about it until now.

Design Options are the best answer I have been able to find. The checkbox on the status bar shown below is at the heart of it all:

Revit automatically checks this option whenever you click the Modify button (or after completely escaping a command). This is great, because you’re not at the mercy of every user remembering to switch it on. With this enabled, anything displayed in your view that is contained in a Design Option is not selectable. So it’s there but you cannot pick it, hence it cannot be accidentally moved or deleted. The great thing though is that if you want to use copy/monitor, this technique will not interfere and the elements in the linked file (now also on a design option) are still picked by the tool and require no special treatment.

Implementation is easy: Create an Option Set (I like to call it Model Management) and a single option named Revit Links.

Now copy over your links to this Option…

…and since there’s only one Option in the Set, it will always be visible, but not selectable unless you uncheck the Exclude Options checkbox.

So far I have not run into any adverse issues, so if you try this and find negative side effects, please comment!

Spiteful CAD Imports

d.baldacchino@sbcglobal.net — Fri, 11 Jan 2013 02:31:00 +0000

So this week the buildingSMART managers at HOK were discussing ways to get rid of imported (BAD!!) CAD files in Revit projects. Should be something that is easy to do, right? Well, not so easy it turns out.

If you need to do this, you might simply fork out a little cash for a custom plugin. Autodesk Exchange has a good number of such things available and my cohort Brok Howard pointed me to Purge Cads. I have not tried it, but I did confirm with the developer that it does not touch linked CAD files, so for a couple of bucks, this will get the job done fast.

One way or another, you need a plugin. In my case I had Ideate Explorer at my disposal. Unfortunately it lumps CAD Imports & Links together. If you have this plug-in, here’s what you might call “an obscene work-around” to hack your way to the finish line:

Assuming you have worksharing enabled, have another user go to the Manage Links dialog and re-load all loaded CAD Links and load & unload all unloaded CAD Links. All we need is to have another user borrow these linked instances so we can get their name in the following step;
Go to the Manage Links dialog and try to load/unload the links. You will then get a list of CAD links that you don’t have permission to edit (the ones touched by the other user in the above step). Take note of the names;

In Ideate Explorer, select all CAD Imports/Links, then go to the Revit filter and de-select the instances listed above.

Now delete the selection and the links will be retained.

Autodesk (or Ideate), if you’re reading this, don’t you think our lives can be simplified by a smidgen? This type of functionality should just be built into the product. The amount of solutions we have to default to via plug-ins is getting way out of hand!

Color Schemes in Reflected Ceiling Plans

d.baldacchino@sbcglobal.net — Thu, 27 Dec 2012 23:35:00 +0000

NOTE: This is a re-post from the HOK BIM Solutions blog

Color schemes are a great analytical and visualization tool which can be used in floor plan, section and elevation views. Sadly, this functionality has been left out of reflected ceiling plan views. So how do you go about creating a colored ceiling plan?

There are a few of options at your disposal and each has its downfalls.

A) Overlaid Views on a Sheet

Create a floor plan view and turn off everything except rooms, then apply your color scheme. Create a reflected ceiling plan view and set ceilings to 100% transparent. Finally, overlay these views on a sheet.

The main drawback with this solution is that you are unable to work in a composite colored RCP view since the final result only exists on a sheet. Activating the RCP view and editing directly on the sheet results in the other view appearing half-toned, so it’s still not a perfect solution.

B) Plan View with RCP Underlay

Create a floor plan view and set the Underlay to Reflected Ceiling Plan orientation for the same level as your view. Set the Color Scheme as desired…

…and uncheck the halftone option for Underlays.

(Manage>Additional Settings> Halftone / Underlay)

The result is similar to A) above, but now you can work directly in the colored view since there is no required compositing of views on sheets.

The main drawback with this solution is that you are not truly seeing an RCP view, so some features that occur above the cut plane might not show up properly or not at all. For example take a look at the door: the frame should show up at the head in a true RCP view such as in A) above, and is thus incorrectly represented in this “hacked RCP”. Please also note however that Revit represents cut families based on the representation stored in the family itself, so you have to be very careful with object representation even in a regular RCP view (ex: the window has an extended sill, yet that sill shows up incorrectly in RCP views too).

As with all workarounds, there are no perfect solutions, so make sure you understand all the issues before choosing the option that works best for your project. Hopefully the Factory will eventually enable Color Schemes for Reflected Ceiling Plans as well!

Shared Positioning

d.baldacchino@sbcglobal.net — Thu, 20 Dec 2012 02:02:00 +0000

This is a topic that has – historically - caused confusion across all levels of Revit users, myself included. I seem to have to re-learn the ins and outs of shared coordinates and the myriad array of associated tools every time I have to intervene on a project where multiple linked models are employed. This week has been one of those weeks, but this time I am thoroughly documenting this topic in an effort to shorten the learning curve next time this comes up once again!

For starters, HERE is a very good summary blog post by Steve Stafford with links to other of his posts on this very topic.

I will write more in detail on this as time permits, but in the meantime, I will offer the single most important strategy to avoid confusion: if you don’t need Shared Coordinates, don’t use them when linking and positioning models! Sounds simplistic, but it is valuable advice and you should ensure to touch on this in your BIM kick-off meeting. If you have separate discipline models for a particular building, they should link into each other with Auto – Origin to Origin from day one. This way you reserve Shared Coordinates for other purposes. Don’t use this system to fix sloppy and incorrect linking because you lose the flexibility to use it for other desirable purposes, such as reporting true site coordinates. For example if you want views showing Level 1 at 0’-0” in some sections/elevations, but want the ability to report the exact height above sea level or to report site building coordinates in a site plan, you won’t be able to do it simultaneously in the same project if you have consumed Shared Coordinates to fix improperly positioned models at project startup.

The other problem I’m finding with the use of Shared Coordinates is that if a model with shared positioning is moved and this in turn causes Revit to save the location back to this linked model (sometimes even when nothing has actually moved), the Project Standards workset gets checked out and not properly relinquished. This results in a team member of one discipline (ex: Mechanical) owning the Project Standards workset in the Architectural model, which can lead to quite a bit of finger pointing! I’ve witnessed this several times when Architectural wants to edit the project address and they are locked out because Project Standards is owned by someone that has no business being in their file.

So are Shared Coordinates pure evil? I won’t dare go that far as their use might be absolutely necessary when exporting data to other applications, such as when needing IFCs for use in Solibri Model Checker. They are a great tool when used with care and caution, but they are undoubtedly one tough nut to crack.

Room bounding in Linked Files

d.baldacchino@sbcglobal.net — Tue, 30 Oct 2012 04:24:00 +0000

Yeah I know, what a terribly exciting subject after a writing drought! So to get the wheels turning once again, here’s some useful information that might be old news to some but was new(s) to me.

When linking Revit files, we can control pretty much everything: visibility/graphics of model elements, annotation, worksets, design options…you name it. All seems to work in perfect harmony, until you check this little option in the Type Properties of the linked file…

…drop in rooms that are bound by the linked file (wait for it)…

…then change the Design Option to something other than the primary, and you get *sad trombone*…

I think this explains it all. If you have design options that will alter how your rooms are bound, you cannot use the Room Bounding type property of the link. Instead, disable it and use room separation lines in the host model to show the desired options. Yes, this needs fixed (add it to the ever bloating pile, Joe!).

Employment #2

d.baldacchino@sbcglobal.net — Mon, 03 Sep 2012 05:30:00 +0000

This post is nothing like the one from 27 months ago. This time I am making a voluntary move in two weeks, purely because it is a great opportunity and not because I don’t like where I am!

The last two years have been fantastic. I have learned a lot about the business side of Architecture and can say unequivocally that I am a much better professional & still-unlicensed-Architect (working on it…almost half-way through finally) thanks to the collective experiences had here. I have learned quite a bit about healthcare projects in Texas and how to manage and mentor teams to get things done. It was rocky at times, especially the first few months, but I have to say that working at PhiloWilke was the best thing that happened to me. Amongst many responsibilities (mainly that of Project Manager and also Project Architect), I continued pushing for better BIM processes, thanks especially to the fact that the upper ranks of the firm had already embraced it, so there was never a battle to be had in that regard.

If you’re reading this and are looking for an opportunity to work for a 35 person firm that does 100% Revit projects and are not afraid to wear various hats, including that of a BIM Manager, then I highly recommend this firm. If you have the skill-set and talent to fill this role, please get in touch with me and I’ll be more than happy to pass your information along. Alternatively, go through here and email Ali directly.

So where am I headed, you ask? Not very far…to the Houston offices of HOK as Texas Region BIM Manager, so some occasional travel to the Dallas office is also in the near future.

This blog will also continue, hopefully with a little bit more frequency as family time and work allows. I am seriously bummed about not finishing up my 3 projects currently under construction or the ones that are soon to be, but I know they are going to be in good hands!

Tangential arcs

d.baldacchino@sbcglobal.net — Sat, 18 Aug 2012 19:40:00 +0000

The question on how to create parametric tangential arcs in families (ex: structural section profiles, extrusion sketches, etc.) seems to come up quite often. And it can be done in Revit: it’s just not as straight-forward.

An AUGI thread resurrected this discussion last month and in my opinion, it was approaching the question from the wrong end. Sure, you can do complicated trigonometric formulas to solve this (I know, I am the Count (Formula) after all!), but it is best to avoid them if at all possible. Intuition says that if you keep things simple and parameterize through simple labels (no calculated parameters), everything should run faster, leaner and more efficient.

So you be the judge. Should you go with this (source: BIM and Beam):

or this?

You be the judge! The key is to use the "Tangent End Arc" type and then constrain along both sides to set where the center of the arc is, (no need to parameterize the arc’s radius). More details can be found in the AUGI post.

EDIT: And even more detail can be found here on Steve’s blog!

2013 Views: Templates and Types

d.baldacchino@sbcglobal.net — Sat, 28 Jul 2012 22:02:00 +0000

My top-rated new addition to Revit 2013 is the ability to create different view types, assign a view template and be able to make them dependent on it.

The great thing is that you get better control of your office standards and their usage. And who doesn’t like having drawing sets comply with well-established standards without having to waste time policing them? I know I do!

Recently I discovered a little issue. When design options are created in a project, these are checked (controlled) by all the view templates, so the users are not able to go to the Design Options tab in Visibility/Graphics and make changes to their views as necessary. And without design options actually existing in the template, you cannot uncheck them from the View Template settings as they are not available. Of course users can go and make changes to the View Templates themselves, but that’s something I’d rather not broadcast too much.

Turns out the fix is simple: add an option set and the Design Options become available in the View Templates dialog. Uncheck them so they’re not controlled by the View Templates and delete the option set when done. Now if users add design options to their project, this setting is remembered and there won’t be any issues with setting their visibility on a view by view basis.

Deployments, content and hacks

d.baldacchino@sbcglobal.net — Mon, 23 Jul 2012 06:46:00 +0000

One of the most tedious and thankless jobs is creating software deployments. “Why is it taking so long?!” I remember asking towards the end of May back in the days. I couldn’t appreciate why, because…well, I didn’t know what it involved. Now that I know I can appreciate it a bit more, although I don’t think it should take weeks on end to get Revit onto users machines.

The first challenge is to get the content downloaded and placed on your network, and install your network licenses (I won’t be discussing the latter on this post). Autodesk have, IMO, made it more cumbersome since the 2012 releases to get content prior to creating deployments, which used to be available for download from their site. My solution is to install a version on a virtual machine (such us VirtualBox from Oracle) and then mine the content to be placed on the network library.

At my previous employer, content was placed on a DFS share which replicated to all offices and then its contents were copied to each machine’s local drive in read-only folders at log-on. This was mainly done due to laptop users and in theory, should cut down on network chattiness when accessing content. At my current employer, we keep everything in a library on the network, which is replicated nightly to another office on the same share as the main office (mapped on desktops with the same drive letter). This is a very important thing to consider in order to simplify your content mapping.

Upgrading of content is a must-do step for some. In my case, I have kept the content as is because we have multiple versions of Revit running so it doesn’t make sense to upgrade and duplicate the custom content in versioned folders. The most used families are pre-loaded in the template so only a limited number need to upgrade when loaded into a project. Of course Autodesk content is placed in its own versioned folder and mapped through the xml files that debuted last year and caused quite a headache. When we don’t need an older version anymore, we can easily nuke the old content folder.

If all your offices have content in exactly in the same location, you’re on your way to simplifying and accelerating deployments. However lots end up having to manually create unique deployments in each office because of two other things that tend to be unique resources at each location: Revit Server and the license server. However, with a little collaboration with your IT department and some basic understanding of DNS, you can actually create a single deployment that works at all your other offices! Sounds too good to be true, but it’s actually quite simple.

Depending on your office network infrastructure, you might be running DNS on your Windows server or some other box. In our current setup, it’s actually running on the router software. So to edit DNS entries, we log into the router and make changes there (called DNS forwarders in our case but your router might have this functionality under DHCP settings, such as with Tomato router firmware). But why should we be bothered with DNS when we’re talking about deployments? Well, whenever you try to connect to a machine with the hostname, a query is sent to the local DNS server first to see if it can trace it to an IP address on the local subnet (if connected together via VPN, each network is defined by it’s own subnet. So for example 192.168.1.XXX is a different subnet/network than 192.168.2.XXX, assuming you have less than 255 IP devices plugged in to each one). This is also what happens within your home network and high-speed internet router. If the hostname is not found, the query is passed on upstream through the gateway and onto your ISP’s DNS server.

You’re probably familiar with naming a Windows machine with a hostname so its easier to locate on a network. The DNS server keeps track of the hostnames and associated IP addresses, which typically change from time to time, so when you try accessing a resource with the hostname, it forwards you to the correct device with the IP address stored in its database. This fundamental fact is extremely important to understand.

However hostnames can be entered on the DNS server (or DHCP settings) manually, so you can think of them as “nicknames” or placeholders to point you to a specific resource. In fact multiple hostnames can be used to point to the same resource. To illustrate, let’s say you have 2 offices A & B. When creating a deployment:

Office A is mapped to RevitServer-A
Office B is mapped to RevitServer-B

So now you’re probably saying…”well Dave, that means you need 2 unique deployments or at least, make a copy of A in office B and modify the deployment”. That is one way of doing it for sure, but not the smartest way. Think back to the DNS discussion above: You can create a new hostname to point you to a unique resource in each subnet. So I can enter a DNS entry as follows at each office:

Office A: revitserver mapped to RevitServer-A’s IP
Office B: revitserver mapped to RevitServer-B’s IP

Now my deployment can be used in both offices and when the local DNS is queried for revitserver, it returns the correct IP address for that location and no deployment tweaks are necessary.

Similarly, if you have a license server at each location, you can easily set up the deployment to use distributed license servers as this minimizes the possibility of running completely out. So let’s say I have the following setup:

Office A: license server called Apples
Office B: license server called Bananas.

Typically you’d enter them as follows in each deployment:

Office A: Apples, Bananas
Office B: Bananas, Apples

In essence, you prioritize them so that each local license server is accessed first and if no more licenses are available, it will find the other one through the Wide Area Network (WAN), assuming your offices are connected together via VPN or ethernet. Once again these seem to require unique deployment packages, but with the above described magic of DNS, we can circumvent this issue. So my deployment can now say fruit1, fruit2 and work at both locations without further tweaks once again. Have you guessed how the DNS entries would be set up?

Office A: fruit1 –> Apples’ IP, fruit2 –> Bananas’ IP
Office B: fruit1 –> Bananas’ IP, fruit2 –> Apples’ IP

So once again, the same deployment can be used and the DNS will resolve accordingly. The beauty of this is that you set it once and be done with it. With the advent of Design Suites and the myriad of deployments that come with it, this methodology will save you tons of time and then multiply that by the number of offices you have to support!

I hope this is of help to someone out there. As always, comments are very welcome.

Wall Quirks

d.baldacchino@sbcglobal.net — Thu, 14 Jun 2012 18:36:00 +0000

Got very busy around here, hence my extended silence. To make matters worse, there’s Euro 2012 now so…while Zach Kron continues to chirp away at funky forms, nodes, divided surfaces and adaptive component families, I think I’m going to continue pointing out the Quirks of Revit Walls^TM ^.

When you unlock the bottom of a wall layer, you can extend it past its bottom constraint (and vice versa for the top). This functionality has been in Revit for as long as I remember. Nowadays we get a lot more control through Parts functionality if we want to fine-tune for panel joints, thickness, extents, etc. Layer unlocking is very handy when trying to rest the base of masonry veneer on a brick ledge or when you want the gypsum board layer to stop below the top of the stud layer for example.

However there is a peculiar condition that we’re presented with when we edit the profile of a wall to create an opening. I totally understand the programming logic of why, but from an architect/builder perspective, this does not make any sense at all. When the profile is edited, the bottom-most horizontal line is still recognized as the base of the wall, so if you edit the Base Extension Distance, you end up with that same extension happening at the “opening head”. And as you might have guessed, the programmer and I just don’t see eye to eye on this one as I don’t believe it should behave this way. Anyone else agree?

So in an effort to outsmart Revit, I inserted an opening instead. As you can see in the middle example above, it seems to solve the issue. However this only works if there is a positive offset value for the opening and as you can see on the right example with the opening having a negative or no base offset, the opening head is messed up once again…#fail3.

By now you’re ready to stop using the unlocked layer functionality; but wait a minute, there is a way (as always!): start an in-place wall family and create an opening in there (Revit will ask you to pick a host).

I know, it shouldn’t be this hard. We see eye to eye on that one.

When working on my first Revit project, I dealt with this same issue only to have it resurface years later while helping another team. It was actually the same exact design scenario: an exterior wall with varying “panel” finishes and continuous stud backup. The team edited the profile of one wall and nested the other in. However when the layers were subsequently unlocked and the masonry lowered to rest on the brick ledge, all head conditions messed up and started overlapping the layers of the nested wall. In such a case, your best option is to not even mess with openings and just embed one wall within another using the Cut tool in plan view, since it’s easier there.

Now when you need to adjust the size and location of the embedded walls, you won’t have to chase around the project correcting the openings as well. And the unlocked layers won’t give you any heartburn either.

Fine-tuning of material surface patterns

d.baldacchino@sbcglobal.net — Fri, 20 Apr 2012 05:35:00 +0000

When materials with surface patterns are used, there is a good chance that you need to tweak its position, and perhaps even rotate it to some degree.

With system and in-place families, this is very easy to achieve, the latter being a little more tricky. So let’s take a wall with a surface pattern for example. You can tab and pick one of the lines and nudge/move/rotate as desired. Even the align tool works like a charm in cases like this. In fact, we use it all the time for tile-work in interior elevations (filled regions are a bad idea for this purpose as you cannot control the fill position/orientation, so painting the wall with a material and fine-tuning the joint locations represented by the surface pattern, is a much better solution). You might be mostly familiar with doing this on ACT ceilings, where you control the position and orientation of the grid by fine-tuning the surface pattern positioning.

When it comes to in-place families, Revit doesn’t allow you to directly control surface pattern positioning. To achieve this, you have to be in in-place edit mode. This is a very subtle, but important fact as you’ll see shortly.

Unfortunately with component families, there seems to be no way to adjust material positioning in the project environment. But recall my point above about the subtle fact…you can adjust the surface pattern in the in-place family editing environment, so why not add some parameters to expose this functionality in the project environment while editing a component family?

As it turns out, you can only adjust the pattern rotation, which is better than nothing. It is really finicky to get it to work and you have to do it a certain way or it won’t work properly. I could not find a way to modify the position of the the fill in the x-y directions, no matter what I tried: ref. planes, ref. lines, constraining to the geometry etc. None seem to work. However rotation works well and I was very surprised to find that even when you change material or the surface pattern (from orthogonal to slanted etc.) in the project environment, the functionality kept working and did not cause the notorious “can’t create type” error.

It is very peculiar to note that you cannot actually flex the rotation parameter in the family editor more than once, or the family will break. Here are the main rules you have to follow:

The angular parameter has to go from a reference plane to one of the pattern’s lines. I found it easier to use an orthogonal crosshatch while building my test;
Make sure to set the angle to zero before applying the label to the angular dimension or it’ll somehow try to rotate the pattern (this is definitely a bug) and cause a “constraints not satisfied” error;
When loading the family into the project environment, the angular parameter has to be zero, otherwise the surface pattern comes in skewed. I noticed that if you load a family with a pattern rotation of say, 10 degrees, the pattern in the project will actually be rotated at twice that amount (20 degrees in this example) and the family doesn’t react when changing the angle between 0 and double the original angle (20 degrees in this example). So make sure the angle is zero when you load it! Just don’t try flexing it in the family editor either or it’ll break.

This technique works for all material application methods on geometry in the family editor:

Painting a material directly on the geometry face
Painting a material parameter on the geometry face
Assigning a material directly to the geometry
Assigning a material parameter to the geometry

I’m not sure how useful this workaround will be to anyone, but there you have it! Hopefully the Factory will resolve this issue and we’ll be able to fine-tune surface pattern positioning directly like we can on system families.

KiwiCodes acquired by Autodesk

d.baldacchino@sbcglobal.net — Sun, 01 Apr 2012 16:32:00 +0000

KiwiCodes, brilliant creator of Family Browser and the new Project Browser, has been acquired by Autodesk for an undisclosed sum, rumored to be in the 7 figures range. KiwiCodes founder Phillip Miller was last spotted completely intoxicated and singing “Money, Money, Money”.

In a press conference, Autodesk said they decided to buy this little innovative company out of sheer embarrassment that such a small company could produce something they themselves couldn’t deliver for years after being asked by their passionate users through wish lists, feedback sites and bomb threats.

It is not clear at this time whether Autodesk will include this for their subscription customers or just kill the living daylight out of this product. They also have the option of closing down the API functionality that makes Project Browser possible and then take 10 more years to come up with something bigger, heavier, less elegant and that doesn’t work. I guess we shall find out.

In the meantime, Phillip promised that all bloggers that mentioned KiwiCode’s products will get something in return, which could be as much as being be-friended on Facebook.

Revit2013 in Perspective

d.baldacchino@sbcglobal.net — Sun, 01 Apr 2012 16:15:00 +0000

Finally! We can now work in Revit in perspective view. I’m so sick and tired of hearing about how the other software can do this and have to sit there and endure the justifiable criticism. But no more!

As you can see below, just click on the View tab and select the new Perspective button. It’s that easy. Arguably my #1 feature of this new release. Way to go Factory!

DWF in the Cloud: #Fail

d.baldacchino@sbcglobal.net — Fri, 23 Mar 2012 17:11:00 +0000

This is a follow-up post to the previous one on DWFx markups in Revit.

I don’t know about you, but this trend of releasing software with major gaps in workflow is starting to really get on my nerves. Do you think that for example if you use ADR on a tablet, you’d want to be able to open that markup on your PC so you can link it into a Revit project? Would you even consider not including this in your core, basic functionality of a software?

Just in case you didn’t know (of course these things go unadvertised by the marketing departments), if you mark up a DWF on your mobile device or in the cloud, you cannot download those markups to your PC. Now if that’s not a major gap in workflow, I don’t know what is. Are they going to fix it in the next release? I have no idea, but this is really irritating as a trend. Do you think your client will find it acceptable to release a construction document set for their building that omits the foundation design, because you didn’t get to it yet?

DWFx markups in Revit

d.baldacchino@sbcglobal.net — Fri, 02 Mar 2012 05:26:00 +0000

Lately I have been looking at Autodesk Design Review (ADR), especially while testing out the Android mobile version. I really think this has great potential to streamline the very chaotic nature of drawing markups in an AE practice. However I was very disappointed to find that the integration with Revit is extremely primitive and poorly implemented.

A seemingly common problem users run into is an error when synchronizing a central file that contains a linked markup:

This got me digging a bit deeper into the issue and at face value, it seems like there’s a simple solution: make sure the markup file is closed in ADR. However I ran into several occasions where the file was closed, yet Revit and ADR thought it was open for editing. I’m not sure if this is due to a network glitch, but I found it peculiar that when opening the file in ADR, it would say “read-only”, even though just seconds before opening, I was able to rename the file in Windows Explorer just fine. This issue was probably the reason why I found a decent amount of posts lamenting about similar cases, including some on the AUGI forums.

Typically when the markup is not being edited or is clear from the above mentioned issues, you can save without any problems and the status of each markup, including the history and notes added within the Revit project, are successfully saved to the DWFx file during a sync with central. In those instances where the markup was thought of as being edited, I worked around the issue by making a copy, deleting the original and then relinking the newly created file. I have not verified whether a simple rename of the file would have worked but it’s worth a try.

In Revit, the markups reside on the view workset of each view/sheet, which means only one person can edit that view/sheet and change the status of markups and add notes. Other views/sheets can be edited simultaneously. If you want multiple users to work on the same sheet, you’ll have to print a DWFx of the individual views and mark up those instead of working at the sheet level. If the reviewer wants to check progress by opening the markup, the file has to be copied and then opened separately to avoid the above mentioned error during a sync with central. I honestly do not understand why an option to open the markup in read-only mode doesn’t already exist within ADR!

The reviewer CAN open and work in the DWFx while users are in Revit picking up items identified in the markups and changing their status, however they won’t be able to save the markup edits until the reviewer exits. Note that a local file save does not save the DWFx. In my testing, if I canceled the markup saving when I got the infamous error, the Revit file sync also terminated. However a second synchronization went through and Revit did not attempt to save the DWFx file changes unless I made other changes to it. Once the markup was not being edited, I had to change something else in the markup settings in order for Revit to try saving it again during the next synch with central.

Rants

I was quite amazed that so many holes still exist in the DWFx workflow after all these years. So here are my personal rants for your enjoyment. Feel free to add your own in the comments:

Selecting a markup and typing "VH" to hide just that one markup results in all markups being turned off. Since each markup element gets placed in its own subcategory, why not modify only that subcategory’s visibility when this shortcut is used?
Every markup element gets its own duplicated subcategory in the Imported Categories tab of the V/G dialog. More sloppy coding??
Hiding an element in view when something is complete is one way to de-clutter your view and help you focus on those items that still need attention. The other method is to uncheck the visibility of one of the two subcategories for each markup, but these become too cryptic to identify when there are lots of them. However once the DWFx file is edited in ADR, re-saved and then re-loaded in Revit, visibility is re-set and all hidden elements re-appear! I mean, really?! Visibility of markup items should be remembered between re-loads and items should only become visible if their status has changed or notes have been added.
There are no controls within Revit like in ADR to use markup status highlighting (which has no degree of control either in ADR 2012). This is a significant problem. I looked at filters for a potential overlooked solution but there’s no way to access markup (imported categories) properties. We need controls to hide/color markups based on status so users can properly focus on what remains to be accomplished.
We really need the ability to open the DWFx as read-only so that markup updates are not hindered when the Revit project is synchronized with central.
If the error mentioned above pops up during a sync with central and the user dismisses saving the DWFx changes, they are not prompted to save them again unless further markup edits are done. Revit should attempt to re-save these changes back to the markup at the next sync with central even if no further edits are performed.

EDIT: Also refer to this related post by Steve Stafford.

Multi-Disciplinary View Coordination

d.baldacchino@sbcglobal.net — Mon, 30 Jan 2012 18:47:00 +0000

Back in 2008 I posted a response to an AUGI thread which contains tips that are still relevant to this day and might be unknown to some users. So I thought of echoing it out here.

The main question was about what the best process is to ensure that view extents (ex: plans) are coordinated between different sheets and different disciplines. The discussion then centered on Scope Boxes:

“When you create a scope box, it's just like drawing a rectangle in plan. You can specify a height too (that's why it's a scope box and not rectangle!). Make sure you give it a good descriptive name (Ex: Area 'A'). You can then go to a plan view's properties and under Extents, assign the Scope Box that defines the area you want to see. The crop region will automatically coincide with the scope box. In fact to change the crop region, you now have to modify the scope box by moving the drag handles and the crop region will follow.
So for a large project, the workflow would be as follows:

In an overall plan view, place scope boxes to "chop" your plan in meaningful pieces so it fits on your drawing sheets. Name them accordingly and place any matchlines and view references here;
Create dependent views (let's say you have 5 plan areas....create 5 dependent views and we'll assign them to the 5 scope boxes created in step (1));
Go to each dependent view, name it something meaningful (ex: Area 'A') and assign the appropriate scope box to it. You can turn off scope box visibility to remove clutter as you typically overlap scope boxes so you can show some context (you have to do this to properly use matchlines);
If you want to make changes to the crop region, always go to the parent view, turn on scope boxes or use the Reveal Hidden Elements button (if scope boxes were hidden, they'll become visible in magenta)....you can now modify them and when you're done, click on the Reveal Hidden Elements button once again and they'll go away or hide the category. Your crop regions would have automatically followed the changes in your scope boxes;
The above is done typically by Architectural. Now consultants just link in as usual, they set a plan view that shows the scope boxes, match lines and view references (perhaps set to "By Linked View" to facilitate this) and copy all these elements into their project file. You do that by tabbing until the object in the link is highligted, then copy and paste in the same location*. Now you just need to carry on from step (2) once you have the same scope boxes residing in your project.”

* As Steve Stafford noted in the thread, scope boxes tend to paste exactly in the same spot automatically, regardless of the paste option picked.

Resolving locking issues with Revit Server

d.baldacchino@sbcglobal.net — Wed, 04 Jan 2012 19:26:00 +0000

Hi everyone, hope this New Year brings you all lots of health, happiness and prosperity!

If you’re using Revit Server (why not?), then you’re probably familiar with this particular WIKI article on Model-Level Locks. If you have not noticed, when users report that they cannot access a particular project or synchronize, you also cannot lock the project in the Revit Server Administrator. Without the ability to lock a project, users cannot do anything so it is of utmost importance to get locking-unlocking to work first. Unfortunately we’ve had a couple of occasions where models were in limbo, even though we followed the instructions in the WIKI article.

There are various reasons that could cause a project to break and I won’t try to analyze that. But it seems there is a way to restore balance to the universe once the permissions get sorted out.

First, clear the .lock files as described here. As a precaution, it seems sane to stop the Local Servers in the IIS Manager first, and then stop the Revit Server Autosync service on each Local Server. Alternatively, you could shut them down completely, but as long as you stop the communication between all servers, you should be good to perform some minor “surgery” on the main patient: the Central Server, which has to be up and running. However you also need to stop the Revit Server Autosync service on the Central Server. It seems that in this state, project files that were previously unlockable, can be locked once again, so cycle through them…wax-on, wax-off. If this doesn’t work and you previously deleted the two .lock files for each problem project, go ahead and re-create them manually (notepad is your friend…remember to remove the .txt extension) and try again. I cannot say with certainty whether this is a necessary step since we did perform this task and I honestly don’t know whether to attribute success partially to this fact or not.

When you’re satisfied that locking/unlocking is working, re-start the Revit Server Autosync service on the Central Server. Go back and cycle locking back and forth once again (preferably at the Central Server master node) to ensure everything is working properly. Finally, bring the Local servers back online and don’t forget to restart the Autosync service.

I hope this helps someone in the future. If you have had similar experiences or found alternative solutions (don’t tell me “re-create the central file”: been there, done that!), I would love to hear about them.

#AU2011

d.baldacchino@sbcglobal.net — Sun, 27 Nov 2011 23:04:00 +0000

The boarding pass is ready, packing is not yet started, and departure is in 20 hours. I’m finally going back to AU after a two year hiatus. Fingers crossed for an exciting event and the usual great networking! Follow along using twitter #AU2011 which is embedded in this post.

Plugs

d.baldacchino@sbcglobal.net — Sat, 29 Oct 2011 21:18:00 +0000

No, this is not about Revit MEP. I just have a bunch of announcements/news items that are probably of interest to the Revit community and want to condense them into one post. I’ve been a bit busy and frankly don’t want to fill your inbox with a ton of infomercials. I receive a lot of “press releases” but don’t want to turn this blog into more spam so, since this is my blog, I get to decide what to post and when! And probably most of you have already heard those from other sources, so here we go…

Apps/Plug-ins/API

Kiwicode’s Family Browser has received some really great upgrades recently (thanks Phillip!). The browser window can now be re-sized without having to enable borders and we can now link families from various folders. I cannot wait to set aside time at work to assemble some custom palettes (favorites of sorts). There is also a Favorites tab where you can add/link families so they are literally at your fingertips. Say you are detailing for the rest of the day: you would use this tab to place the most needed components so you can be fast and productive. It’s a brilliant idea! The search function is also quite snappy now. The first time you click into the box, it indexes the families (takes a few seconds) and then, subsequent searches are almost instant.

As you can tell I’m really excited about these improvements, but in my opinion the best one yet is the revamped insert behavior. Now when you click on a family in the palette, it automatically previews with no need to click in the canvas. A single click places an instance, just like native Revit behavior. And if you click on another family while actively placing other instances, it automatically switches to the new clicked family and you can continue placing the new instances. This is also native Revit behavior and makes this plugin feel like it’s part of the software. These were real sticking points for users in the previous version (from personal experience) and now it feels completely seamless.

Kiwicodes really listens to user feedback. Check out my previous post on this topic and note the list of wishes; they’re almost all implemented and then some!

Steve Faust of Revolution Design has some really great apps too. I just want to mention Keynote Manager and the recent Selection Master. Steve has graciously given me a license for the latter and I plan on writing in more depth about his tools, but wanted to plug them now so you can check them out.

Have you ever had to delete unwanted levels in your project and couldn’t because it would have taken a lifetime to find all the families hosted on them? Thanks to the re-host feature, now you can with Selection Master. This tool is a must-have in every BIM Manager’s arsenal. More on these tools in future posts.

Digipara’s Elevator Architect is another tool I’ve been aware of for a while. Unfortunately I tried using it in a recent project but it has failed me. Due to time constraints I have not had time to troubleshoot in depth, although the authors have been very responsive in trying to collect data. Hopefully in the future we can get to the bottom of the problem and use it successfully. As always I might write more in depth in the future.

Learning Revit (and Vasari)

Renowned author Paul Aubin has a new Revit family building course on Lynda.com. You can read all about it here. If you want to sharpen your family building skills (and you know how important this is), you cannot go wrong using this great resource!

What!?! You don’t know what Vasari is? They are up to version 2.1 on Labs and I really wish I had an extra 10 hours a day to play with the cool features that are not in Revit. If like me you’re finding it hard to keep up with everything and don’t have time to test yet another application, you can go to the newly launched Vasari Talk (yep, another link for your bookmarks!). You can participate in live webinars after signing up, or you can watch past recorded sessions.

Navigating Revit

By now you all know that 3Dconnexion’s devices work with Revit. I have not had a chance to try one yet but it looks like it would be a great tool. In the meantime, they are having a drawing for a trip to Autodesk University in Las Vegas on Nov. 29 – Dec. 1, as well as airfare, accommodations and a SpacePilot PRO 3D mouse. You can click here to enter. And speaking of AU, I was lucky enough to make plans for attending this year (thanks AUGI and PhiloWilke!) and am looking forward to meeting up with some old buddies. See you at the AUGI booth!

Evangelizing Revit (and digital simulation)

Abstract submissions for SimAUD 2012 (the Symposium on Simulation for Architecture and Urban Design) are fast approaching. The upcoming symposium will be in Orlando, Florida and you can find more about it here. You can also go to this link for the proceedings from the past two years.

Face Painting in the Family Editor - FIXED!

d.baldacchino@sbcglobal.net — Thu, 13 Oct 2011 21:59:00 +0000

Following up on my previous post on the topic, the Factory provided a hotfix for this today. You can read all about it courtesy of Kathryn at Revit Clinic. 13 is such a lucky number, isn’t it?!

To use this functionality, create the parameter first in the Family Types dialog. When you then launch the Paint tool, the parameter will be available as a material in the dialog.

Installation of the hotfix is a snap…just copy and paste the dll.

Immaterial? I don't think so

d.baldacchino@sbcglobal.net — Sun, 09 Oct 2011 05:12:00 +0000

This is a follow-up post to Immaterial? from almost a year ago. I promised to write about a new method we’re employing in one of my comments but got too busy. Finally I’m getting around to it. Be warned: it’s long.

I originally held off posting to see whether 2012 would bring any solutions on this front but that didn’t happen. At least now the bottom of the Custom Parameters section adjusts with the Materials dialog…hurray!

The least-worst solution I prefer is ugly workaround #1 as mentioned in the previous post. I hit a serious snag while experimenting but finally got through it. I like to refer to this methodology as the Materials sample board concept. Think about your office for a minute: you probably have a vast library of samples. This is analogous to the Materials dialog in your Revit project file. You don’t use all materials in your library in every project, nor do you schedule all materials used in your finish schedule (Ex: insulation, gypsum board, etc.). The same applies to Revit projects. Even assuming every material was actually used in some form or fashion, you’d want to only schedule a select few as finishes, which requires some filtering mechanism.

When crafting office-wide workflows, you have to be careful to keep things simple. This is a hard thing to do when the tools don’t do exactly what you want. So compromise is absolutely necessary in order to arrive to the best-possible solution. It won’t be perfect or satisfy every requirement, but will result in an improvement over how things are done today.

We all understand materials sample boards: designers pick paints, flooring materials, ceilings, glass, cladding, masonry & brick finishes etc. and present them on a board to get client approval. Those materials then find their place in the project, usually within room finish schedules, tagged elevations, etc. So my goal was to extend that concept into Revit. Presentation of those materials was not at all considered as you just cannot achieve that through print.

As discussed before, Revit will only schedule a material if it is used on a placed object. So the starting idea was to place “material swatches” in the project template and make them very difficult/impossible to delete by mistake, without resorting to obtuse ways of concealment such as through worksets, phasing or design options. This was a very important requirement so everything could be pre-set in the template, including the finish schedules. It was also very important to have the same materials used in the material finish schedule as materials in the objects themselves and utilize built-in & custom material parameters to store information that we want to see scheduled such as Manufacturer, Color, Pattern, etc. This would open up possibilities of building material libraries per client and/or project type to be re-used in the future.

Another important requirement was grouping of finishes by surface/object, such as Floor, Walls, etc. Since various materials (such as paints) could be used on different surfaces, it was also essential to have the ability to add unique schedule notes to each material in each application, which meant that this information could not be stored within the material itself. This issue, coupled with concealment methods, turned out to be a head-scratcher.

Material Swatches

The starting point was a simple generic model family that was to be placed multiple times in the template. After several iterations and reasons, it became clear that shared and nested families were required. Each shared “swatch” was nested multiple times into a base family that would represent the application/surface of those materials.

Multiple types were then placed in the template and editing these family types becomes the UI when building the finishes information. Type Comments is used for the schedule sub-headers and Schedule Order is for defining which application order is displayed in the material schedule.

In this example, I have 5 placeholder materials for each application but of course you could add more to suit your needs. Since we have 8 applications, 8 instances were placed in the template. The solid geometry of the swatch family was then set to not be visible and finally reloaded, making them completely invisible and unselectable.

Concealment

Here are some interesting family facts that made all this possible:

If family geometry is made to not be visible, material take-off schedules still pick up the materials used and properly report quantities (volumes/areas of materials on non-visible solids are excluded). Hence the use of this technique will not skew your take-offs.
Families are selectable in-canvas even with no visible geometry unless all reference planes are set to “Not a Reference”.

These are the key elements needed to let us place “swatches” to host finish materials and prevent accidental deletion. Note that one can still pick the family in the browser and delete it, but you also get a warning that you’re about to delete “x families”, so it would be a deliberate mistake or done purposefully and not accidentally.

Material Facts

As mentioned in the other post, only the material name can be used in room schedules. Revit does not permit duplicate names so this can be used very effectively as a “Type Mark” since duplication cannot occur. The only hitch is that you cannot rename a material in the schedule: you have to rename it in the Materials dialog.

By using the Material Class, you can isolate the materials that represent finishes to make navigation easier.

In the above picture I’m also highlighting a big shortfall in Revit: the inexistence of multi-value parameters. For example walls in certain rooms often receive multiple finishes: a paint and ceramic tile or FRP panels. My workaround is to create materials whose name represents a group of multiple finishes. This is solely used in room schedules. For the record, this is not something I’m happy about! However there’s no other way to achieve this and when using text parameters, we’re essentially doing the same thing.

The Finishes Schedule

To build a material take-off schedule (for Generic Models) to filter only the materials in the “material sample board”, I simply filtered for shared parameter “Schedule Order” as “parameter exists”, which is also used for sorting the application order (Floors, Base, etc.).

Conclusions

So why all this pain you ask? Well, keep in mind that once this is set in your project template, all it takes is for users to pick the materials and edit as necessary or create new ones. It also opens up the possibility to save material libraries rich with information that can be re-used. Not to mention that with material tags that read the material name, you’ll have flawless coordination with the “type marks” used in your finish material schedule. Room finishes can also utilize these materials in lieu of text parameters, although for multiple finishes you have to resort to the workaround mentioned above. Finally, we also have to make another check: that each finish that shows up in the finish material schedule is actually used in the project since these are manually added. For this purpose we also set up a “checking sheet” that contains a series of filtered schedules to make sure no finishes have been missed or added. Obviously it would be great if things were all automatic, but at this point this is as good as it’s going to get.

Securing links through worksets

d.baldacchino@sbcglobal.net — Tue, 06 Sep 2011 17:08:00 +0000

In my projects, I typically create a workset for my consultant linked models and check that workset out permanently to prevent accidental deletion/movement of links (ex: to user "RevitCOP"). The username just needs to be a unique one to prevent anyone from accidentally making an undesired edit.

I have never been a fan of Copy/Monitor functionality but recently I started using it and am running into a problem. When I try to stop monitoring elements or go through coordination monitor to make changes, I'm told that “RevitCOP” has the workset for the links checked out and has to relinquish it before I can make changes. Why is this necessary? All I want to do is move my grids & rename them to match the link (through coordination review). Because of this, I have to open my file under the RevitCOP in order to do copy/monitor & review operations, which seems totally unnecessary. Or I have to quit "securing" my linked files altogether, which I’m really not ready to concede.

During a copy/monitor and when going through warnings, all you're doing is to change the elements in the host file (unless you reject changes, in which case nothing is physically changed), but nothing is being done to the linked project. So why is Revit being so inflexible about a permission that is (intuitively) not required?

I sincerely think that the current logic of having to own the element/workset in order to perform copy/monitor and coordination review is something that really needs to be looked at closely by the Factory. Probably Revit is writing some kind of tracking information to it, but since the only mechanism of securing links is through forcibly checking out worksets, this is causing undesirable consequences and related frustrations (and we don’t want that, right?)

While we’re on the subject of Coordination Review, it would be really nice if we didn’t have to use the steering wheel in order to pan, and simply use the middle scroll button as we do in regular view navigation!

Revit Server is Desktop no more

d.baldacchino@sbcglobal.net — Thu, 01 Sep 2011 02:41:00 +0000

Well, we finally gave up. Reluctantly.

Our Windows 7 setup seemed to be working just fine. However we were plagued by Revit crashes following a successful synchronization with central at the location connected to the Local server. At first we thought bandwidth was to blame so we upgraded our connections by installing business cable at the location with the least bandwidth, fully dedicated to Revit Server to Server traffic (2Mbps up, 12Mbps down). We left the previous connection in place to other uses such as VoIP, VPN, etc. In the main office we left the bonded T3 (3Mbps up, 3Mbps down) alone but removed traffic shaping to make sure Revit Server received maximum capacity.We also configured the Revit Servers with their own public IP address so traffic was outside of VPN and thus not slowed down by encryption. The servers are protected and not accessible from outside the network through various router rules and protection safeguards.

Unfortunately this did not eliminate crashing at the user’s desktop. Our next experiment was to switch the Central and Local servers around to see what effect this would have (not the physical machines). We ended up with the Local server in our main office with around 6 people working on server-based projects and 2 at the remote location saving directly to the Central server. Through our upgraded connection, we could now create central files through the Local server, which was not possible in the past. So we know that at least bandwidth cured that issue. The crashing unfortunately followed the Local server and users in the main office started experiencing this crashing following a successful SWC, 90% of the time. Go figure.

Our next step was to install Windows Server 2008 SP2. We did this on the Local server first. Lo and behold, the crashing ceased even with the central server still running Windows 7! At this point we don’t know exactly why this is happening and gave up on our endeavor. We still think Windows 7 should do the job but somehow, there’s some setting somewhere that is causing Revit to blow up. Or maybe WS2008 is more efficient at handling limited resources such as RAM? But why would Revit crash, with no debugging info. available?The machines we’re using as servers are low on RAM so who knows? The journals do not point at the culprit and Revit mysteriously crashes after successful saves (servers keep running fine, projects do not corrupt and the Revit Server administrator reports the saves are successful), so at this point we bow our heads and wave the white flag. Bummer.