Autodesk User Group International

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 the most annoying issues that comes along. Plotting is already a difficult task at best and when someone creates his or her own settings files, it gets worse. This is one of the main reasons people have difficulty plotting other people's drawings.

In a multiuser environment, standardizing the methods of plotting can reap enormous benefits. Plotting is often the cause of high levels of user frustration. 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. A user wants a little more thickness to some lines and creates a CTB to get it done. He stores it on his local machine and creates the plots. The next person who tries to plot can never reproduce the image because he doesn'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 with 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 made up the block.

I have seen so many violations in this area 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 on and on.

Exploding is not the answer. It actually creates more problems. The root problem is not knowing 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 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 I 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: 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 an 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. Just a few more I'd like include are:

Not Xrefing correctly
Non-standard text sizes
Not drawing to scale
Not spell checking
Not using paper space
Failing to follow the "draw it only once" advice!

This list could grow for a long time. Join the conversation online by clicking the Discuss This link.

(Discuss this Article! in AUGI's new Discussion Forums.)

Submitted by Mark W. Kiker, a member-at-large on the AUGI Board of Directors. Mark is a National CAD Standards Project Team Member and president of the Core Technology Group, a consulting firm. He is the General Editor of BLAUGI and also publishes caddmanager.com, the CADD Managers Journal, and the caddmanager.com blog. He is currently Director of Technology for HMC Architects in Ontario, California.