Showing posts with label Coordination. Show all posts
Showing posts with label Coordination. Show all posts

Friday, September 6, 2013

Project Base Point Manipulation

I written before that I occasionally experience something that feels like a "Revitary alignment" regarding features in Revit. I'll see a post at AUGI or get an email or two from friends or clients asking about the same thing or theme. I recently ran into a user that manipulated their project by moving the Project Base Point. Then a post at AUGi meandered into a related conversation.

General Statements
  • The Survey Point allows us to show where an imported CAD file's origin is relative to your model (CLIPPED)
  • The Survey Point allows us to identify a benchmark location on the site instead of referencing source file's origin (UNCLIPPED)
  • The Project Base Point does not ever "need" to be moved (CLIPPED) normally (my opinion/belief/preference)
  • The Project Base Point will allow us to move our project on the site to reposition it (CLIPPED) but the file origin isn't changed
  • The Project Base Point (UNCLIPPED) will let us identify an alternate location that Spot Elevations and Spot Coordinates can reference
Applied to a Project

Let's say you design a house, import a survey and it's off to the right and above your building. If you use Acquire Coordinates on the survey file you should find the Survey Point (CLIPPED) moves to mark the origin of the source survey data file (sometimes this is quite far away). The Project Base Point (CLIPPED) can be used to reposition the building over the site. Just drag or move it with specific values. What you see moving is the "Project". The file origin is untouched and you should see that the linked survey file isn't moving either. If you import a small origin "marker" file using Auto - Origin to Origin you'll find that it lands at the Project Base Point. Now if you move the Project Base Point (UNCLIPPED) you see that you can move the icon to another location but it still references the "file origin" (see image).


That approach works for a single building on site but is not very effective for multiple buildings on site. The approach I advocate where we create a site file that is coordinated with survey data and serves as the master coordinator for multiple buildings which are linked into this master site file is much more effective and versatile. Since this subject can be confusing enough I advocate using the same approach for any project so I can learn one technique and use it over and over, since it works for any project.

Tuesday, August 27, 2013

Linked Ceiling Hosted Light Fixtures and MEP

A ceiling hosted light fixture can cut the host ceiling. When an architect uses one of these fixtures the ceiling surface the Revit MEP user has to work with actually has a "hole" in it. This means that they can't put their own light fixture in the same spot because there is no ceiling there.


Technically that's an oversimplification. We CAN put a fixture in the same location but there isn't a face for Revit to detect easily. If you try to use the Downlight - Recessed Can family it's origin is too far from a ceiling's grid pattern to let us put it within a tile. We can put it in randomly and then move it to the correct location. We'll get yelled at though, the light isn't properly hosted now.


If we do the same sort of thing with the troffer family (2x4 fixture) it will be a bit more tolerant as well as not losing its face association.

This sort of discipline collaboration isn't tons of fun.

Wednesday, July 24, 2013

It is a Training Problem

I frequently get involved in conversations that start with someone wishing Revit would help resolve "x" problem. The essence of "x" is that somebody on the team keeps doing something that the team wishes they wouldn't. So we want Revit to fix a user, or make it impossible for a certain user to do something.

Usually it is just growing pains and those WILL subside after enough time is invested and experience is gained. That's the purpose of training, we can shorten the time required with training. Yes, I do work as a trainer but I'm not just saying that because I'm a trainer (the carpenter thinking every problem needs a hammer). The whole point of hiring a training consultant or going to classes (for anything) is to reduce the time it takes to become productive or knowledge.

    We SPEND money to SAVE time and invest in our skills.

Too many firms don't invest in their staff (or if they do, they don't do it effectively). They expect or assume that their staff will just manage to get by on their own. Give them a book, they're smart, they'll figure it out. They probably are smart and they will figure it out...eventually. How long can you wait for that to happen? They might pay for training but then after three days in a class they've been trained and therefore are experts! At least that's the perceived expectation or assumption. After all, that's why architecture is such a easy degree to get and getting licensed is a snap, right?

Getting training is a piece of the puzzle. Putting that training to work is how experience is gained. The training makes it possible to shorten the learning curve toward experience. No matter which way you approach the learning don't underestimate the importance of the experience of doing the job, the project. You'll just enjoy the job or project more if you get some good training and spend less time getting frustrated.

If a firm really keeps track of how much time is lost to inefficient task completion and inexperience leading to rework. They'd find out eventually that hiring that consultant or training facility would have been a bargain. If we don't treat "time lost" as "money spent" we don't realize how much it really cost. So many firms behave this way, they don't pay attention to the money going out the door the slow and "invisible" way. It goes out so slowly they convince themselves it isn't happening. If you are serious about seeing a return on investment (ROI) you need to know what it costs to do everything now (the established or "old way") and then later after becoming proficient with Revit. As they say, you can't manage what you don't measure. Keep in mind that lots of data doesn't necessarily mean it is useful.

A senior architect mentoring an intern architect is the same thing, your experience helps the future senior architect become one. You can be a mentor in your office for Revit and bring people up to speed sooner too! So it's not just about hiring a great trainer, it's also about striving for better continuously.

    We sprung for training and people are still making mistakes and they've been warned repeatedly!

Mistakes are one thing, we all make them. If people know better but keep doing the same thing over and over again you now know what they really think of you and the firm. They don't care! They don't care enough to "play along", be a "team player" (OMG, holy catch phrase Batman). Sorry but AEC is a team sport.

    Messing up other people's work IS a training issue, until it ISN'T anymore.

If people are trained and continue to be RUDE and refuse to work well with others it is no longer a training issue. It's a HR (Human Resources) problem, yeah I mean "possibly cost them their job". A firm (and it's staff) shouldn't have to tolerate people refusing to work together well. That's easy to write, not as easy to work through, I know that. Someone once said to me, "Yeah we have a few people who should work for our competition". So I say, "why aren't they?" (big grin)

Ignoring the problem, yeah how's that working?

Plaaaaay BALL!

Sunday, May 26, 2013

Our Model is Clash Free

Offering a "clash free model" is a bit like the car ads on television that offer a 100k car for $299/month. When we read the tiny print we realize that the monthly cost is more like $1600/month and mere mortals won't qualify for the financing terms. Like the car ads, we have to carefully declare/define what a clash is. What sort of clashes are acceptable (and therefore not considered a clash) and those that are not (and therefore are a clash).



One simple example, pipes pass through walls. If they don't cut a hole in every wall at every location where a pipe intersects with a wall then technically we've got a clash. If it is a poured concrete wall that requires a sleeve it is a bigger deal (even bigger deal if precast) than a wood/metal framed wall with gypsum wall board. By the time we are done defining clashes our client and/or team will feel like they are getting "nickel and dimed" to death. ...and that's just for our work...

We can't offer a clash free model if everyone else working on the project isn't working toward that goal themselves. Our model might be "perfect" (according to our fine print) but if they aren't coordinating their work with ours...and vice versa...we'll still have clashes. It's not a one way street.

It is also a moving target as a project moves through design phases. Are we promising "clash free" when people start swinging hammers or is it clash free within two weeks after receiving an architect's model, at the end of each design phase?

"Clash Free" - It's a worthy goal and one every client and project team would love to achieve. It's not possible without considerable commitment by everyone and can't be achieved in a vacuum by one part of the team. In my view someone casually offering "clash free" suggests to me that they may not have enough experience yet. Anyone who has been part of weekly clash review sessions can attest to it not being a trivial matter.

It seems to me that's just the sort of promise that keeps lawyers busy...

Saturday, April 6, 2013

Modelling Serendipity - Revisiting an Old Post

In July 2009 I wrote about "Modelling Serendipity" when I encountered something that made me ponder my past work. Some recent conversations made me think of it again so I thought I'd put a link here to point at it again.

I recently told somebody, "I don't know what I don't know and I find that I bump into what I don't know in 3D faster than 2D"...that's modelling serendipity.

A RELATED POST (Sept. 2009), related to the notion of 3D shop drawings.