Foundation Level Issues

I started to notice some strange results from my foundation levels.  I have 750mm deep caps on level 00 (which is -150mm below ground/project zero.)  The bottom elevation should therefore read -900.  My schedule showed one cap with a -150 offset from base level which should have read 0.  I had a look in the model and it was in the correct location but the offset was still wrong.

It turns out that the cap is fine until the offset is adjusted near to the bottom of the column.  Revit wants to attach the foundation to the column:

After this, the offset reads relative to Project zero and not the work plane it is hosted to.  This only happens if the foundation family is work plane based (See end of post about Z coordinates).  Below shows an offset of zero which puts it at project zero and not flush with the slab which is 150mm below:

Another issue I spotted can be tested with the new 2014 switch join tool.  I tried to edit the work plane but it was locked out:

I started to notice that my work plane options were disappearing once it was all joined in.  So I had a little go at testing it and got some odd results:

1.  As it ought to be but work plane options locked.

2. Switch join on slab, work plane options are back but elevation at bottom -150mm?

3. Switch join on Cellcore, work plane options are back but elevation at bottom -425mm?

It seems as though using switch join on more than one element locks out work plane options.  Without switch join, elevation at bottom is wrong and my geometry doesn’t work.  Switch join is great for cutting holes out of geometry without having to sketch them. 

Bottom line, offset and elevation at bottom are unreliable and columns irreversibly make foundations relative to project zero with work plane based families.

The free Excitech toolkit will schedule off the correct Z coordinate but the shared nested piles will only populate with the correct value if the host cap is work plane based; that is until 2014.  It appears that Excitech have tried to address the problem.  I noticed that in 2014 all of my foundations were failing to update.  If I un-ticked work plane based then they started to update.  Now my offsets are correct even when a column is involved.  Hopefully I won’t need coordinates for work plane based families.  Elevation at bottom is still incorrect if the slab cuts the cap but I can live with that.

This update to Excitech’s toolkit makes a big difference and now the foundations will play nice.  It is a shame that there seems to be no documentation that acknowledges these limitations and the fact they have been partly addressed in the 2014 release.

Ultimately I am looking for reliable results and to understand why work plane based families suffer these glitches.  We need to be able to create accurate real world coordinates for elements on site and trust what the software is telling us.

I have logged this with Autodesk and Excitech.  It is important to let developers know about these issues so they can fix them.  So many people complain about the short comings of software but never give feedback for it to be resolved.  If you have never logged a support request with Autodesk... why not!  They are there to help.

Tiny Text Has Vexed Me

Went back to an old project in 2013 and had to edit one of the materials.  I was surprised to see that the text had been washed at too high a temperature!  It was nothing that a restart wouldn’t fix.  Another fun moment with Revit

Autodesk ReCap Update Issues

Recap let me know that an update was available, so I downloaded it.  When I tried to run autodeskrecap_sp1_for43.24_x64.msp I got a warning:

I created a support request with Autodesk (always worth while doing so at the very least they become aware of the issue) and got the following response:

Thank you for your request on your Autodesk Support.

Step 1 - Check the version of "ReCap" installed on your computer by clicking the about box (capture_1).

Step 2 - Check the ReCap version written in your system registry "HKEY_LOCAL_MACHINE\SOFTWARE\Autodesk\Autodesk ReCap\R1.0\ProductSpecific" and update it to match the version found in "Step 1" (capture_2) .

Step 3 - Close the registry and restart your computer. Start ReCap and try to re-install the update.

There was indeed a discrepancy; I had 1.0.43.27 in the product and 1.0.43.24 in the registry which I amended to suit.

I ran the update again but it still didn’t work.  There was a little gotcha.  When I downloaded the original update it had given me the version to match my registry (.24).  If you click on product update again, it downloads .27 to match the updated registry.  All is well and ReCap is up to date.

BTW, internet searches on this product spits update odd results.  It appears that there is an awful lot to recap!

Solving Room Bounding Issues–Divide & Conquer!

I have answered a few forum posts in the past regarding Room Bounding issues.  I decided to write a post sharing a few tips for solving your problems.

When you place a room object you sometimes get this warning:

In a complex model it is not always obvious why this is happening.  The best thing to do is break the problem down logically to eliminate possible causes.  There are some obvious things to check such as:

Make sure that all of the elements are room bounding

Less well known perhaps is to check the instance properties of a level datum to see the Computation Height

Also note that sketched profile openings and Wall Openings are not room bounding.  Use a Room Separation line to plug the gap or use empty door families to create openings.  They all yield different results so make sure you understand their workflows.  I will perhaps write a post on that if there is interest.

Problem Finding

Start with changing your Visibility/ Graphic Overrides to make it easier to see what is happening:

The Reference cross and Interior Fill boundary may give you a clue as to where the problem is:

This should show up when using the Room Placement tool.  In this example it is of course an obvious and contrived error.  The base of the wall has a 1mm offset and a Level Computation Height of 0mm to create the problem.  However, a similar scenario occurs when there is a strange wall join or joined geometry below.  There is always a good, logical reason why it is happening but it can seem quite irrational prior to finding a solution.  This often leads people to think this is just another one of Revit’s quirks.

This is more like what people come across:

Using the Room Separator can really help you focus in on the problem:

I call this ‘Divide & Conquer!’  Draw a Room Separator line to divide the room.  It doesn’t need to be equal.  Then place a room in each half:

You can see that one half is not bounding.  Divide that side and repeat:

It starts to become obvious where the leak is.  You don’t want to get too fiddly so clean up what you have done and isolate the area you have identified with Room Separation lines, perhaps from the over side to clarify the point of interest (once you get a feel for it you only need two separating lines and you can nudge them):

Be aware that Revit has a tolerance for Rooms and will allow small gaps,  which in simple situations can be as much as 449.8mm unless there is another bounding element to leak through to:

Now you know where to focus your attention.  Don’t forget the problem will be at the Computation Height, so that gives you an idea of elevation – then you have XYZ coordinates for the problem.  Create a 3D section around the area and start to digest the condition.

Revit 2014 installation issues

Hopefully most users won’t have any issues installing Autodesk products but issues can occur.  I am using Windows 8 64bit.  If you get a similar issue to me then this may help you fix it.
I downloaded the installation file which unpacked itself to C:\Autodesk.  Once it finished unpacking it immediately launched setup.exe which threw up this error: (lucky me)

You can locate LiteHtml.dll in the following folders:

• C:\Autodesk\Autodesk_Revit_2014_English_Win_32-64bit_dlm\Setup
• C:\Autodesk\Autodesk_Revit_2014_English_Win_32-64bit_dlm\x64\en-US\RVT2014\Program Files\Autodesk\Root\Setup\en-US\MRF\Setup\Setup
• C:\Autodesk\Autodesk_Revit_2014_English_Win_32-64bit_dlm\x86\en-US\RVT2014\Program Files\Autodesk\Root\Setup\en-US\MRF\Setup\Setup

The setup is unable to see dll’s in any of its subfolders.  I copied the dll from the first location (since it is probably for the 32bit setup) into the same folder as the setup.exe and it was able to find LiteHtml.dll  since it went on to look for another dll.  So I copied the full set of dll’s and the setup.exe succeeded bringing up an install screen but then I got the LiteHtml.dll error again.  This time it was probably looking for the 64bit version but still using the one I copied into the root.  Perhaps
Long story short…

Solution

This is what worked for me.  Paste all of the dll’s from:
C:\Autodesk\Autodesk_Revit_2014_English_Win_32-64bit_dlm\Setup
into
C:\Windows\SysWOW64

The setup then worked as originally anticipated and I was able to look forward to the new official release of Revit.