First published in AUGI Hot News July, 2006 – see Part 1
Last time we looked at four of the seven deadly sins that AutoCAD Users might make. They included not reading the book, not developing standards, going overboard on enforcing the standards at all costs, and using software like we did in older releases. Let’s turn now to the rest of the list.
Sin #5: Creating your own personal pentable, CTB or STB
This is one of my most annoying issues that comes along. Plotting is already a difficult task at best and when someone creates their own settings files, it gets worse. This is one of the main reasons people have difficulty plotting other people drawings.
In a multi user environment standardizing the methods of plotting can reap enormous benefits. Plotting is one of the first and highest levels of user frustrations that occur. So many times I have seen users struggle to get the output to look just right and fail. They cannot match what the last user did. It does not match from project to project or file to file.
It most often relates back to the creation of “special” CTB files or unique STB files. Users need to stop creating “one off” output that no one can reproduce. I have seen it over and over again. One user wants a little more thickness to some lines and so they create a CTB to get it done. They store it on their local machine and create the plots. The next guy who tries to plot can never reproduce the image because they don’t have access to the file.
Set a standard and have every user, every project, every file follow it. I have worked in very large deployments, multiple hundreds of users – all using the same CTB or STB file for all plots. Yes there will be client plotting requirements that demand differing pen settings, but only if demanded.
Set all the systems to point back to a shared location on the server for the pen settings and plot styles. Make the folder read only. Keep it clean.
Sin #6: Exploding
Back in the day there were many valid reasons to explode stuff. Explode was created to “unblock” blocks and reduce things down to the basic structures and entities that comprised the block.
I have so many violations in this area that it is overwhelming. It appears that many users see this as the universal answer to every problem they have with data. They explode hatches and blocks and attributes and dimensions and tags and tables and fields and…
Exploding is not the answer. It actually creates more problems. The root problem is not know what kind of data it is and not knowing how to work with it. I think long and hard before I explode something. The general rule is if I have to explode it to get it to work right, then I created it wrong. If I have to explode it to get it to work right then I don’t know how it was created. I need to learn more about the object types and how to work with them. I need to learn the behaviors of objects and why they are doing what they are doing.
Exploding should be the last ditch effort to get something to work. Actually you are not getting it to work at all. You are working around it. You are negating any kind of intelligence that was built into the object and forcing it to conform to your level of understanding.
Next time stop and think about what the object is. Ask someone if they know why it is not working right. Learn what you have to do to work with the data.
Sin #7: Not saving your work
“Save it or lose it”. I have worked in an environment where that was beat into my head. All new users need to be reminded about saving their work. If you failed to save your work – you lost it. In the old days (circa 1985) system glitches, crashes and hiccups happened all the time. The hardware failed. The power failed. The software failed. We have come a long way.
There still exists a need for saving your work on a regular basis. How many of us have been burned by failing to save our work in a timely fashion and the system locks up. If we have been burned by this, we hopefully learn from it.
You may say that the system does an AutoSave and you don’t have to worry about it. Most users do not know the AutoSave settings on their machine nor do they know how to recover the AutoSave file when needed. It is better to get them in the habit of purposeful saves on a regular basis. My rule is that I save whatever I don’t want to lose. If I like to place my data in jeopardy for 30 minutes without a save, I better not complain about redrawing something when I lose it.
I regularly save my work every 5-10 minutes and after major milestones I don’t want to lose. If Ii have just struggled with some knotty problem and gotten the graphics to behave, I save. I set my AutoSave to 15 minutes and use it as a backup. I hopefully will never have to rely on my AutoSave because I am saving my work.
BONUS – Sin #8: Not using OSNAPs
Oh my Gosh! Does this still happen? Oh yeah – it does… all the time.
I have seen so many users who consistently fail to use OSNAP. This is so basic that it is embarrassing to mention. When users fail to use OSNAP even once, it can cause a ripple into all areas of the drawing. One bad piece of graphic can infect and entire project.
When OSNAPs are ignored while creating blocks it compounds the misery. Getting the primary geometry in place correctly is critical to all your efforts. This is a basic drafting method that must be drilled into new users. Keep on them until it becomes second nature. Don’t let up until they get it right. Don’t forget to warn them about OSNAPing from 2D to 3D.
If you have failed in this area (we all have at some point), rededicate yourself to OSNAPing all objects, all the time.
Conclusion:
Well, as you have guessed, I could go on and maybe never cover your area of “sinfulness”, or something you have seen in others. To name a few areas that would be nice to discuss I would include… Not XRefing correctly, Text sizes that are all over the map, Not drawing to scale, Not Spell checking, Not Use Paper Space or maybe Drawing things twice.
One of the concerns I have about AutoCAD training efforts and curriculum is that they forget to explain the WHY and move to the HOW to quickly.
A lot of time may be spent teaching our users how to do the wrong things faster and better. Even if we improve their speed, they are still doing the wrong thing.
We don’t start out teaching them the wrong things. It just happens because they take the “right” teaching and apply it wrongly. If they do not have a deep understanding of how XREF’s work, then teaching them a quicker way to attach an XREF is used in a “wrong” manner to achieve the same bad result we had before we made the user faster.
Explaining the concept of CAD objects, data structure and methods is so vital to the proper training of a CAD user and I think it needs more focus. We should be deeply explaining XREF’s and Viewports and LTSCALE and more so that all of our users understand what is going on behind the scene. Often this will help the troubleshoot their own problems and get back into production quicker.
I enjoy a good training course that takes the time to explain the concept of CAD and not just what button to push.
Are you a subscriber?
In this months issue…
Calculating Return on Effort – How small updates equal major savings
CAD Manager – your pain, everyone’s gain
Sidetracked Users – When they should give up and move on – some problems may never get fixed
Survey Says – Do you DWF or PDF?
Go to the June – CADD Manager Journal
Well at least the first four.
I posted this article in AUGI Hot News for June 2006.
If you look around you can see repeated patterns of CAD troubles. People get themselves into trouble often by doing the same things. As I observed these patterns of behavior, I came to understand that there is “nothing new under the sun”.
Presented in no particular order…
Sin #1: Not Reading the Book
If you have read my stuff before you realize that this is one of my forgotten habits of CAD users. Not reading the books and info you can get your hands on is like trying to install a garage door opening without reading the installation instructions. Read the articles in the January, February and March issues of Hot News.
Sin #2: Not developing Standards
By “developing” I mean creating, defining, reviewing, updating and enforcing a CAD Standard.
Everyone has one anyway. All users are creating objects in some form of a standard way. They may be using their own “personal” standard, but they are most likely using one. It may be written or just in their head, but they do have habits and processes that they use.
Standards drive the unification of producing CAD files. Standards allow us to share project development better through unified methods, layers, processes, and production shortcuts. We can automate the way something is produced and provide a target for file structure.
They drive the automation of creating data, but they don’t really guarantee that the data will be technically correct or interpreted correctly.
So if you don’t have one – create one and share it.
If you have one – review it and refine it
If yours is good – enforce it.
If it gets in the way – jettison it (but make sure you come back and correct the bad files – see Sin #3)
Sin #3: Going overboard on Standards
Some users are so head strong on Standards that they fail to get the job done. They impact project deliverables by spending too much time getting it right. Now, before you run me out of town on a rail, understand that I think good standards should not over tax your production flow. Automated standards (those imbedded into the software through customization) should work well for speed and accuracy.
But, from time to time you will have to get something out the door in a pinch. My thoughts are to stop worrying about the standard to get the job out and then go back and fix the files. Most people do this anyway, but often fail to go back and fix the files. I think many CAD Standards violations are done with the knowledge that the user is breaking the standard. So why not just admit it and get the job complete and go back an fix the files. Don’t let them be swept under the rug because someone if “too scared” to admit they made some mistakes.
NOTE: Standards can be set aside, but never accuracy. The technical content of a file MUST always be exact.
Sin #4: Using the software like it was still a previous release
We all do this. We all have some old habits that are still working for us. I do not think we should abandon them all, but some of them are trapped in old releases. If you have upgraded, please find out what has changed in the new release and see if you need to start doing something differently.
Autodesk carries a lot of old baggage from prior releases. They tend to not remove commands or tools that are long overdue for retirement. REDRAW still exists in 2007 even though most of us now can easily do a REGEN in the same amount of time. In fact, I would have trouble finding a command that was removed in 2007 that existed in 2006 (except the 3d stuff). Why? Because we all still use the old stuff – forever.
Now you may say “what’s wrong with using old tools that still work?” There may be nothing wrong with the command, but you may be handicapping yourself to discovering new tools. Watch a new user and see how they work. I bet it would be very different from the way you work.
The real concern is when you move up from AutoCAD to another high end tool like ADT, Revit, LDT, Civil 3D, or Inventor. No you may actually be causing problems by using the new tool the same way you used the old one.
Take the latest CAD Manager Survey!
There are many places and ways to get training these days. Which ones are you using?
Even the most developed layer standard will have missing layers because each project may call for something special. When this happens, you should have general guidelines for creating layers as needed.
Include in your CAD Standard a model for creating layers. The NCS has a great one that reflects the AIA layer guideline.
Your standard may need to go beyond an AIA style, to the “concepts” of layer creation.
Here are a few conceptual ideas you may want to consider outlining in your standard…
1. Use the shortest layer name you can get away with. Use A-WALL and not A-WALL-EXT if the shorter one will work.
2. Only breakdown layer names if you have to turn off one layer and keep another on or change linetype, color or pen weight.
3. Only abbreviate words in layer names that make sense. If you are using AIA style layers and want to shorten the layer name to 4 characters, then make sure it can be deciphered. If you are not using AIA, then you may not have to abbreviate at all.
4. Group layers under the same main area. If you are drawing something for the Ceiling the AIA guideline shows
A-CLNG-ACCS
A-CLNG-GRID
A-CLNG-OPEN
A-CLNG-PATT
A-CLNG-SUSP
A-CLNG-TEES
If you need to break out another Ceiling layer start it with A-CLNG-????
I was thinking about Layers again and wanted to share a couple of conceptual ideas about layer standards.
When you’re developing your Layer Standards you can use outside influences to define your layers. Being in the AEC market, I let ADT define any layer names that it creates out of the box through Layer Keys. So any layer that the software makes on it’s own, I want to use that as my standard. This simplifies the layer creation and tweaking that I have to do to the software. If ADT makes it, I use it.
AIA has a layer guideline and so does the National CAD Standard. I default to those layer names as much as possible. If they define a layer, I use it.
Layers that I do not like to ever draw on…
Layer Zero (0)
Layer Defpoints
I did not create them, so I do not own them. I should not be using them. I only draw on layers that I can control. If the software does not allow me total control over a layer then I do not want to use it.
ADT does create layers for me, but I could modify them by adjusting the Layer Keys, so that’s okay.
I have been involved with CAD Standards reviews many times. I usually start with the basics; Plot Styles, Layer Names and Folder structure. Constantly talking about these things is good.
I think that the whole layer list review is a positive thing to go through at the base level. Review each layer name one by one to see if it is needed or not. This may sound horribly boring, but it can be very profitable. Here is why…
It allows you to have conversations related to what data goes on what layer. The layer name is just the opening topic that quickly moves to how you put files together. Each layer that is discussed in depth allows you to talk about what data is in question. This is a good conversation to have.
Once you go through the layer list you will have a good idea about where you have users with differing ideas about what goes where. Many times files are hard to work with because you have data scatter amongst varying layers. Each user is doing something different. Don’t assume that just because the layer is called A-CASE that people will know what kind of data goes on that layer. Don’t expect them to not get creative. When three different users put the same data on three different layers, you have a problem. This is what you need to unify. You will get a lot out of the conversation.
It may seem tedious, but I think it is fruitful. If you hang in there, by the time you get done talking about the Layer Standard, none of you will need to refer to the book because you will have hashed it out so much that it will be burned into your brains. (har har)
Are you a subscriber?
In this months issue…
Seven Ways to Solidify a New CAD Manager Position
Seven points that may help you get ahead in a new CAD Manager position.
Refreshing a long term CAD Manager
If you have been a CAD Manager for a while, then here are some tips for you.
April Survey Says – Are you moving ahead? Moving to AutoCAD 2007? How soon are you moving? See what the survey tells us.
Go to the May 2006 Journal
Loading ...