CADDManager on July 3rd, 2006

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.



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.

Leave a Reply