Archive for December, 2007

Notes on the December 2007 Meeting

9 December 2007

Yes, I know it’s been a while since we posted the meeting notes here, but we did promise to place them on the blog, so here we go. CAD disasters are evidently a fertile source for discussion, and tonight’s meeting was no exception – there were quite a few hours of lively discussion and good humoured banter around the room. As we’ve been doing lately, the meeting format was an informal “round table” style of talking, led by a few pointers from me. Names have, of course, been changed to protect the guilty.

The points below are derived from an architectural context, so please bear that in mind if, say, you’re from a mechanical background. You may find that the opposite of what’s below might work for you – that’s OK. Just remember that these points are intended as a starting point for a lively discussion and they certainly succeeded in doing that!

Great Fubar CAD Disasters of 2007

Peter Godfrey
I’m sitting here at home on a muggy Sunday afternoon and contemplating doing my tax return. Instead, I got to thinking and wondering about some of the problems we come up against in using AutoCAD at Fubar Architects.

These disasters are all contained in just ONE project. Some big ones, some small ones. They are in no particular order. But, the time that’s been wasted through all these sloppy CAD practices when multiplied throughout the whole office doesn’t bear thinking about.
You might not agree with everything here: a spirit of discussion is healthy. However, these are insights I’ve gathered in using AutoCAD for over 20 years now, and I’ve a fair idea about what works and what doesn’t.

I present them in a constructive spirit to hopefully learn from them and move on. I believe that there is no malice or even incompetence in those who made these mistakes. It is rather the result of people having a lack of experience in setting up CAD on the larger projects found here at Fubar. There is no point in pointing fingers at who might have caused them, it’s best to encourage these people to learn and realise that they have many other skills to bring to the process of creating architecture. After all, CAD is but one part of the overall process.

1. Drawing Too Far Away from Origin.

Junior cad monkey is told to create a site plan and floor plan. He takes a survey drawing originally in metres scale and scales it up by 1000 to make it mm. Ends up with a site plan 300km away from the origin. This causes huge problems with osnaps, hatches, accuracy and even corrupted drawing files and loss of drawing data. Basically, when you are that far away from the origin you will lose precision because of the limited amount of digits your machine can hold during an arithmetic operation. There is no cure for this, except to move the project closer to the origin and this can be very difficult to do further down the track when a lot of xrefs are involved.

Make sure that the origin point (cad WCS 0,0,0) is at least on the project site. It should coincide with an identifiable point in the project, for example the “bottom left” grid intersection or at a corner of the site.

2. Unwanted 3D Data

I find that CAD 3D design sketches are generally drawn without much regard for the principles of “good cad” described here. This is not unreasonable, since the designers producing these drawings have other things in mind and “good cad” principles are a low priority.

I have no problem with this, however, these 3D design drawings are sometimes imported into the job. This causes problems with osnaps, distance measurements, bhatches. You can use the FLATTEN command to fix this but it often causes problems with renamed blocks and others.
The best approach is to treat CAD design sketches basically as hard copy and redraw the data properly from scratch.

3. UCS Dramas

The World Coordinate System should be logically positioned with respect to the structure. For example, at a corner of the building and at an angle which relates to the building. It is best to be able to use only the world UCS when drawing and require user UCS’s only temporarily (e.g. when drawing an angled wall.)

When setting up the job, decide on a suitable UCS to use as world and keep all plans with the same origin and in the same orientation relative to world UCS.

If outside parties such as consultants insist on using different ucs’s and even scales, a neat trick is to create a “placeholder” drawing into which the consultants drawing is xrefed (xref attached, not overlay) at the correct scale and orientation. This can then be xrefed into the Fubar project at world UCS and scale 1:1.

4. Plans Not Lining Up

All plans in a project should share a common origin point. Do not rely on user UCS’s to line them up. Everything should line up in the world UCS.

A common time saving technique is to copy data from one drawing file to another. If the drawings are located at the same point in space, this becomes much easier. In fact, if the drawings are at different origin points, scales and rotation angles it is often easier to simply draw the objects from scratch.

5. Sections and Elevations in Wrong Place

All sections and elevations should be drawn at the correct RL. For example, if the floor level is set at RL 2.500m, then draw the floor with a Y coordinate at 2500, in the world UCS. This makes calculations of RL’s and vertical dimensions trivial and error free.

6. Loony Layers

Layers are a crucial part of drawing organisation. They aid the processes of entity selection, object identification and management of data in xrefed drawings. While it may seem a small issue to, say, draw some window glass in layer “A-CONC-H” this will come back to bite you (or someone else) in the future. For example, some one needing a 1:100 plan might take your 1:50 plan and freezes the concrete wall hatching to aid clarity. Tender drawings are printed not showing the window glass. Later on, the client rings you to ask why the builder is claiming a $50,000 variation because he hadn’t allowed for any glass in the windows.

Don’t create layers just because you can. Nobody likes working on a drawing with 1,000 layers. For example, I’m working on a drawing with separate layers for text and its associated leaders. There is no reason to do this: leaders should be drawn in the same layer as the text.

7. Not Using Xrefs

Xrefs are a great way to streamline the management of CAD data in a project. Unfortunately, it seems that some people don’t appreciate their power. Objects may be drawn once and, if they appear on another drawing, they are xrefed into that drawing. Then, if revisions are made, those revisions update the second drawing as well.

8. Not using Osnaps

Draw things to scale and accurately.

It may sound simple, but many CAD users are not in the habit of drawing items actual size. They think that if it is close, it is good enough. Well, it’s not good enough. It contaminates the CAD you have and produces incorrect files. You know that CAD files have a way of being reused in other projects and if they are wrong at the beginning, they are wrong forever.
People rightly assume that you are going to draw accurately. If you do not, and someone does not catch the error, then troubles creep in. Someone may use your file as a background, then offset from your linework, thus making theirs incorrect.

Bad drawing is like a virus: once incorrect dimensions are introduced into a drawing, they have a nasty habit of spreading as people (reasonably) use commands like offset and copy to work on the drawing.

Be careful when using running osnaps, especially if NEA or PER is on.

9. Non-zero Fillet Radius

This may seem like a trivial problem, but the default radius used by the FILLET command may be set to a small non-zero value, for example 1mm. This results in a small, potentially invisible, arc at corners created by the fillet command. The effect of this is to upset the commonly used osnap END option, giving wrong distances and resulting, e.g. in non-parallel wall lines or horizontal lines which aren’t horizontal.

10. Draw Lines on Top of One Another, for No Reason

Multiple lines are drawn, e.g. face of plaster and face of blockwork coincide. There is then no visual clue that there are stray lines under the one you can see and you are at the mercy of draworder (which even on the latest AutoCAD’s) is notoriously unreliable, especially in xrefs and plotting. Likewise, if there is to be one line visible on the printed drawing, only draw one line, not several joined end on end.

A corollary to this is the practice of drawing multiple lines almost together. An example: on a 1:100 drawing, four lines are drawn 0.0239563mm apart. There is no sensible reason to do this: only one line should exist at that location.

11. Exploded Dimensions, Hatches, Mtext

Exploding these objects into their constituent parts should almost never be necessary. If they need to be edited, use the appropriate AutoCAD editing tools (ddim, ddedit, hatchedit etc.) This is particularly important with dimensions, which lose their associativity when exploded, potentially resulting in wrong dimensions being shown on the drawing.

12. Referencing Files Not in the Project Directory

It may seem obvious that all xrefs should be located within the current project folder tree, but it is surprising how often this is not the case. Drawings can be started by opening a dwg from one job and doing a SAVEAS into another job. This can result in title block logos etc. being carried across.

13. Inline Text Formatting

Text can be formatted in the mtext editor for colour, font etc. Don’t do this – it makes it almost impossible to globally change text formatting later. Instead, draw all text (and mtext) with colour bylayer and font governed by the text style.

Similarly, avoid using hard returns in a block of text. This causes problems when the text is edited later by affecting the text flow. Instead, control mtext width by stretching the grips.

14. Duplicating Critical Information

More a general drafting problem than CAD, but critical information should be shown in only one place in the documentation set. Then, if it is changed (as often happens) there will not be a problem with conflicting information.

For example, a critical setout dimension is shown on three drawings and is changed. The changes are picked up on only two of the three places and the builder builds from the dimension that is wrong. Liability rests with the architect.

15. Fudged Dimensions

AutoCAD has the ability to automatically calculate dimension values based on the geometry – use it! There should rarely be any reason to draw something which is not the actual dimension. Then, if the geometry changes, the dimensions will update accordingly. If you need to change the formatting (e.g. decimal places or text height,) then change the dimstyle.

16. Nonsensical Notes

When annotating a drawing, make sure that the notes you draw are useful, consistent, actually make sense and are clear and concise. For example, the drawing on my screen at the moment contains notes such as “150 UC WITH RHS AND ANGLE HEAD RESTRAINT TO BOLT ON” and “STAINLESS STEEL 125X100 MILD STEEL ANGLE HEAD RESTRAINT TO ENGINEERS SPECIFICATION.”

If you are not perfect at spelling, make sure you use spell check on your drawings before issue. Be careful when abbreviating words: for example BULKHEAD may be abbreviated to B’HEAD or BULKH’D but never BULK’HD. Poor spelling and grammar creates an unprofessional impression to our clients.

Sometimes notes seem to be added to drawings just to make them appear complete. Do not include comments like “as specified,” “as shown” or “to engineers drawings” since that is implied anyway. I kid you not, I have seen a note (on a plan drawing) which read “REFER DRAWINGS” without saying which drawings!

Avoid noting sizes of structural members since they may change and the responsibility of sizing structural members rests with the engineer.

Correct spelling is vital to a professional presentation. Few things say “amateur” as much as poor spelling. If you are not one of those blessed with an innate sense of correct spelling, use the inbuilt AutoCAD spell check.

17. Unlocked Xrefs

Xrefs should be placed in layer A-Xref or similar. This layer should then be locked to prevent accidental movement of the base xref. Don’t place xrefs on layer 0 (or worse, something like layer A-Wall1!)

An actual example: Grids are in a separate drawing which is then xrefed into each plan (good idea so far.) They are all inserted at 0,0 on each plan level (so far so good.) But, on the roof plan, the grid xref is inserted on layer A-Stair1 which is not locked. Someone accidentally (I hope) moved the xref 41.76mm horizontally and 125.03mm vertically. Result: every roof penetration setout is incorrectly dimensioned.

18. Rubbish Out in Space

Avoid leaving stray entities miles out of the drawing area. When you zoom extents, the drawing disappears and two tiny dots are left on the screen. Not only that, but I have seen drawings so badly affected that the spatial index overflows and drawing data is actually lost (i.e. linework and text disappears without warning.) This can happen in parent xrefs (a drawing into which the problem drawing is xrefed.) For example, a base plan is xrefed into a stair plan detail. Text disappears from the stair detail.

19. Dopey Defpoints

For about the last eight hundred years, AutoCAD has had a special defpoints layer which was intended for dimension definition points. This had the special property of being visible on the screen but did not plot. So, some bright sparks thought that this property could be put to good use when drawing other stuff that they didn’t want to see on the plotted sheet – for example viewport boundaries.

All very well, but defpoints was introduced as a kludge in 1986 and contains strange bugs such as a curious interdependency with layer 0. Confusion reigns when viewports are drawn on defpoints and the defpoints layer is frozen (but layer 0 is thawed.)

Around the end of the last millennium, Autodesk introduced a layer property that could make any layer have a non-print property. Use this to advantage: place viewport boundaries in the non-print layer A-Viewports. Don’t draw anything other than dimension definition points in layer defpoints.

20. Funny Fonts

General notes on our contract drawings should be drawn in style ROMANS-80 which uses the ROMANS font at a width of 0.8. If you draw your notes in the STANDARD text style you are at the mercy of the definition of that style. For example, if STANDARD is defined with a different font in the plot sheet your text will look wrong. Even width and therefore text wrapping will change. If you keep to the ROMANS-80 text style your drawings will be consistent.

The Romans-80 style gives notes which are compact and easy to read. You may use Arial font for headings and titles if the Project Leader agrees. However, this must be done on a consistent basis throughout the project.

21. Pointless Polylines

Some people have a habit of unnecessarily drawing objects using polylines. I’m struggling to think of a good reason, but maybe they think it makes hatching easier (It doesn’t – PLJOIN can fail if you are a long way from the origin.) If you want to hatch something, then draw the boundaries as lines which actually meet.

Having some lines as polylines results in accidental or confusing results when erasing, offsetting etc., particularly when the whole object is not visible on the screen. It wouldn’t be so bad if everything was drawn with polylines, but typically, some are lines while others are polylines. At least be consistent!

22. Always Draw Full Size in Model Space

Always draw full size in model space. Always draw full size in model space. Always draw full size in model space. I’ve said it three times because, yes, it’s that important. It doesn’t matter whether you’re drawing a small detail or a huge site plan, always draw it full size. Then use viewport scaling to set the plot scale. That way there is never any confusion about the size of the objects you are drawing (especially when someone else works on your drawing or uses data from it.)

23. Always Plot at 1:1

Plots should be made by inserting the standard office title block at 1:1 in paper space. Choose the title block which suits the paper size and the presentation style (contract dwg, sketch etc.) Then set up viewport(s) to the scale you need.

24 Bylayer

Draw everything bylayer. The reasons for this should be obvious, but do bear repeating. If the drawing is to have any use at all downstream (for example, to be used as a background by a services consultant, or even within Fubar Architects when a floor plan is to be used as part of a ceiling plan) then it is vital that the second user is able to manipulate the appearance of that drawing. This is practical only if that user can set the appearance of objects (for example by changing all architectural layers to a fine pen.) A corollary of this is to make blocks using components all drawn bylayer.

25 Snappy text

When you have a series of notes, use snap to line them up exactly. Don’t make a mess of notes haphazardly scattered around the drawing. A drawing with neatly lined up notes gives a more professional appearance. Even if you can’t BE professional, at least make the effort to APPEAR professional!

26. Magic Mtext

Always use Mtext in preference to old-fashioned Text. That way you can edit the note after and have it magically flow around a predetermined width.

Also, avoid placing hard returns in your text which break up the flow. Likewise, avoid formatting the text in the text editor: if you need a special font, do it with the style command.

27. Dimension Structurally

Dimensions on setout plans (e.g. 1:100 floor plan) should always represent the structural dimension, not to the finished face. If, for some reason, it is necessary to dimension to a finished face (e.g. a required exit width) then this should be noted as such. An acceptable alternative can be to dimension internal walls to the centreline, as long as this is made a consistent standard in the job.

Peter Godfrey
02 Dec 2007