Thursday 28 July 2016

Numerical Data Out of Range - A Couple of Culprits

Occasionally when linking CAD files into Revit, the following message is thrown up:

While not the end of the world, it can be mildly irritating. After a bit of digging there are a couple of things that seem to cause this: namely Hatches and MText. I thought I would share this here.

Hatches, by default, derive their origin from the UCS origin of the file. In order to fix this, the hatches origins must be altered to get them near the hatch itself. This is done by the following:

  • Use 'Quick Select', pick all hatches in the file
  • Under 'Properties', check the origins: these will read 0,0

  • On the ribbon: Go to the 'Hatch Editor' Tab. Under the 'Origin' panel, select 'Set Origin' and pick the 'Center' option

  • The properties should now all be 'localised' to the hatch position
I'm not entirely sure why this causes a problem, but MText with the three properties 'Defined Width', 'Defined Height' and 'Column' set to anything other than '0', '0', and 'none' respectively will cause the message to appear. Use 'Quick-Select' to pick all mtext and adjust accordingly

I'm sure these two aren't the only causes of this message. I will update this post in the future if any more come to light.

Thursday 19 March 2015

Lookup Tables and a Little Chat - Getting the Type Name into a Text Parameter

I've very recently been looking at using Revit lookup tables for structural families. These are traditionally used in the MEP side of things, but I have been looking for a structural application for a while. In the course of this, one of the things I have been able to achieve is to pass the lookup table's first column 'Type Name' to a text parameter in the family. As my knowledge of lookup tables is relatively new, I assumed this was something widely used and known. At the last London Revit User Group meeting, I was chatting to Jose Fandos of Andekan and we got onto the subject of this. He assures me that it most certainly isn't and people would be interested in this little tip. So here goes:

I created a sample lookup table as follows:

In Revit, the parameters in the test family:

A text parameter is created in the family called 'Type Name'.  The formula is broken down as follows:
  • size_lookup                   
Tells Revit it's a lookup command
  • (Lookup Table,              
Refers to the lookup table name in the 'Lookup Table' parameter
  • "",                                 
Usually there is a value between the quotation marks. This refers to which column to reference in the lookup table, but in this case  we create a 'null' value. This is what allows this method to work
The text value that is used if there is no matching value in the lookup parameter
  • Size)
the lookup parameter value for the lookup formula to reference.
I'm not sure why this actually works, but I suspect that even though the syntax for the formula is correct for a lookup, the omission of a search column reference means it returns the first value it comes across, which is the 'Type Name' in the first column.
Hope this is useful.

Wednesday 5 February 2014

View Range and Phase Filters

A recent problem arose where phase filters are used to show demolished columns. In 3D and section views, everything appeared fine, but in plan, these columns weren't changing appearance as per the phase filter override. The suspected cause was in the view range for the plan and after a bit of head scratching, it was determined that the columns whose tops terminated within the 'View Depth' band of the view range would ignore the phase filter overrides. This has been recreated in the images below:

Projection - No Phase Filter

Projection - Phase Filter Applied

Cut - No Phase Filter

Cut - Phase Filter Applied

View Depth - No Phase Filter

View Depth- Phase Filter Applied

I'm not going to go into a full explanation of how view ranges work, but there are a couple of very good ones by others here and here that helped me get to the bottom of this.