Monday, 22 April 2013

Wire End Woes

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.


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.



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 Circuit

Happy circuiting!

Sunday, 21 April 2013

Bloated Revit central files

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.