If you would like to be included in Pulse
, please submit your news, press releases, or blog URL to firstname.lastname@example.org
Novedge reserves the right to exclude certain items from Pulse.
Novedge Pulse of Dave Baldacchino
The Pulse of the Graphics & Design Community
Wire End Woes
NOTE: This is a re-postfrom theHOK BIM SolutionsblogIf 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.SymptomsYou 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.AnalysisSo 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 FixTo 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 [more...
Bloated Revit central files
NOTE: This is a re-postfrom the HOK BIM SolutionsblogA 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 [more...
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 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 [more...
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 loadedCAD Links and load & unload all unloadedCAD 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 [more...
Color Schemes in Reflected Ceiling Plans
NOTE: This is a re-post from the HOK BIM SolutionsblogColor 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 SheetCreate 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 UnderlayCreate 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 [more...
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 [more...
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 [more...