Uniformat - Assembly Codes and e-SPECS

[Brockway]

A couple of us here at our office have been using e-SPECS for some time and have been itching to really utilize the connection between it and Revit. We tend to hit several walls when trying to link models to the specs. The main issue I see is with the UniformatClassification.txt file.

A) The file as supplied by Revit or e-SPECS does not seem to include a proper depth of assemblies. In other words, it doesn't seem to drill down far enough for many common elements that we model. It will have Exterior CMU wall but not a Brick Veneer wall with CMU backup. It will have an EPDM roof membrane but not EPDM membrane on tapered insulation on metal deck. In my opinion, it seems to have more individual building elements as opposed to building assemblies which is what I would think is what it should have.
So, I'm wondering if there is a source for a more complete and in depth break down of these codes. It just seems to be missing a lot of key components. (EX: Where would I find a Column Cover? Aluminum or GRFC or GRFG?)

Now, I know I could go in and edit the text file and add assemblies as I find the need for them. However:
B) The file resides on the local machines where Revit seems to find it. This creates a management nightmare. If I would decide to rely on the file as a descriptive link and trust any other Revit modeler, I would need a consistent file to refer to. It would be a million times easier to do this if I could maintain one file in a single network location like we do with the sharedparameters file.
Is there any way to point Revit to a different location for the uniformatclassifications?

[Scott Womack]

The main issue I see is with the UniformatClassification.txt file.
A) The file as supplied by Revit or e-SPECS does not seem to include a proper depth of assemblies. In other words, it doesn't seem to drill down far enough for many common elements that we model. It will have Exterior CMU wall but not a Brick Veneer wall with CMU backup. It will have an EPDM roof membrane but not EPDM membrane on tapered insulation on metal deck. In my opinion, it seems to have more individual building elements as opposed to building assemblies which is what I would think is what it should have.

You have to begin creating your own Assembly Codes. e-Specs for Revit has an excellent workflow for this. We create the codes in a central location, then the logins for each person, copies this file to the local drive location each time the person logs into their computer.

Now, I know I could go in and edit the text file and add assemblies as I find the need for them. However:
B) The file resides on the local machines where Revit seems to find it. This creates a management nightmare. If I would decide to rely on the file as a descriptive link and trust any other Revit modeler, I would need a consistent file to refer to. It would be a million times easier to do this if I could maintain one file in a single network location like we do with the sharedparameters file.
Is there any way to point Revit to a different location for the uniformatclassifications?

No way to point to a central location for this file. In addition, Revit only reads this file when you start a Revit session. According to the Factory, this is an extremely LOW priority, since it only benefits those who purchase third party programs, not the OTB Revit users.

[Gilles L Letourneau]

Also, Keep in mind that assembly codes are describing systems i.e. EPDM roofing would actually be describing a roofing system which would include: EPDM Membrane, Membrane flashing, Joint sealants, Insulation, protection boards sometimes even stone ballast. You would not want to have an assembly code for everyone of these items would you?

Hope this helps.

[Brockway]

Ah, I see your point. Still, some of the descriptive text that is OTB which qualifies the numbering system could use some modification for better clarification. Maybe if I was really familiar with the assembly code system, I wouldn't need that. But, I'm not and I don't expect to be anytime soon.

I guess I just wish that I could maintain a comprehensive keynote file (which we intend to do, anyway, based on the MF04 numbers) and have e-Specs look at those for a link. But, I'm sure that's a topic for another board.

[Scott Womack]

I guess I just wish that I could maintain a comprehensive keynote file (which we intend to do, anyway, based on the MF04 numbers) and have e-Specs look at those for a link. But, I'm sure that's a topic for another board.

Actually, that is one of the interesting features of e-Specs for Revit. It will generate a project specific list of keynotes, based upon what the Revit model is reporting to e-Specs. That would mean you could not keynote something that is not in the specifications (in theory). We are not currently using the keynote system with/or without the especs keynote system.

[Brockway]

I noticed that in the new version. However, that's actually problematic for us.

For their system to work, one must build the model and assigning assemblies codes, create the e-Specs project, export the model, possibly adjust the bindings on rare occasions, then have e-Specs process and create the keynotes, then point the model to the keynote file and assign keynotes. IMO: that's unnecessary redundancy.

Also, it is very common that we're over-drafting items that are not modeled and/or the architectural discipline is not specifying. So in the e-Specs system I'd have to go in and modify the keynote file anyway to get items I want to call out but aren't in my discipline.

It's just much more simple to maintain a single office wide keynote file that all projects can point to and is all inclusive. It's even more simple to maintain it as I can point Revit to a networked location in this instance.

[Scott Womack]

We have been building in the assembly codes to our library of "stuff", including the detail components. Yes, you"export" to a spec project, but the keynotes are generated within Revit, not from the e-Specs Product. You can also "edit them" by the chcklist, etc. Not sure why it is seem as so many more steps. Personnally, I've been bitten by keynotes that wewre placed on the drawings, but not picked up, or were conflicting with the specifications, in the public-bid market.

[Brockway]

That's interesting that you say they are created within Revit. I'm going to have to look closer into this. It appeared to me that e-Specs generated the keynote list via the plugin (appears in Revit but actually generated by e-Specs).

[clog boy]

This is also relevant to us, a Dutch contracting/project developing firm in the Netherlands.
We're attempting to make our own file based on NL-sfb codes. That coutains three levels, with the lowest sublevel containing five digits.

We have found out that it is very important to keep the tab separated structure.
We have also found out how to deal with the category codes. Here's the table:

Casework 2001000
Ceilings 2000038
Columns 2000100
Curtain Panels 2000170
Curtain Wall Mullions 2000171
Doors 2000023
Electrical Equipment 2001040
Electrical Fixtures 2001060
Floors 2000032
Furniture 2000080
Lighting Fixtures 2001120
Mechanical Equipment 2001140
Parking 2001180
Planting 2001360
Plumbing Fixtures 2001160
Railings 2000026
Ramps 2000180
Roads 2001220
Roofs 2000035
Site 2001260
Speciality Equipment 2001350
Stairs 2000120
Structural Columns 2001330
Structural Foundations 2001300
Structural Framing 2001320
Topography 2001340
Walls 2000011
Windows 2000014

courtesy Augi forums

One of the management solutions could be a script that copies and replaces the textfile from a central location, with one person updating and testing the file.

Moving on. Our cost estimation program seems to work based on embedded Excel worksheets. Ideal scenario would be an import function for Excel files, acting as an underlay for our cost estimation program. Alternately, it would be a part of the IFC file, with software suitable for extracting quantities and assembly codes.


We have yet to create a workflow for this.

[ThinkRevit]

http://forums.augi.com/showthread.ph...56#post1148556