Wire End Woes

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!

Wire End Woes

Bloated Revit central files

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:

1. Opened a detached copy of the original project and deleted all rooms. The file was saved as a new central, no purging (155MB);
2. 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;
3. Opened the central file created in step 1, created workset “Rooms” and set as Active;
4. Linked the file created in step 2, Auto – Origin to Origin;
5. 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;
6. 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”.
7. 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.

Bloated Revit central files

Securing Linked Files

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!

Securing Linked Files

Spiteful CAD Imports

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!

Spiteful CAD Imports

Color Schemes in Reflected Ceiling Plans

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!

Color Schemes in Reflected Ceiling Plans

Shared Positioning

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.

Shared Positioning

Room bounding in Linked Files

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!).

Room bounding in Linked Files

Employment #2

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!

Employment #2

Tangential arcs

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!

Tangential arcs

2013 Views: Templates and Types

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.

2013 Views: Templates and Types